Data Structure Change for Multi-Month Support

[Julian466]

Discussed in #251

^{Originally posted by Julian466 January 16, 2026}

Data Structure Change for Multi-Month Support

Background

The current StaffScheduling backend uses a flat data structure where each case contains a single set of configuration files. This design limits the application to managing only one scheduling period per case at a time.

Current Structure

cases/
  {caseId}/
    employees.json
    global_wishes_and_blocked.json
    wishes_and_blocked.json
    web/

Proposed New Structure

data/
  cases/
    {caseId}/
      {month}_{year}/          (e.g., 11_2024, 12_2024)
        employees.json
        global_wishes_and_blocked.json
        monthly_wishes_and_blocked.json
        wishes_and_blocked.json
        employee_types.json
        free_shifts_and_vacation_days.json
        general_settings.json
        minimal_number_of_staff.json
        shift_information.json
        target_working_minutes.json
        worked_sundays.json
        weights.json
      templates/
        global_wishes/
          global_wishes_and_blocked_{timestamp}.json
        weights/
          weights_{timestamp}.json
        minimal_number_of_staff/
          minimal_number_of_staff_{timestamp}.json

Motivation

1. Multi-Month Management

Currently, users can only work with one scheduling period per case. If they need to schedule for January and February, they must either:

• Overwrite January's data when working on February
• Create duplicate cases (Case 77 January, Case 77 February)

This is inefficient and makes it difficult to:

• Compare schedules across months
• Maintain historical data
• Plan ahead for multiple months

2. Template System Requirements

We're introducing a template system that allows users to:

• Save and reuse configurations (minimum staff requirements, solver weights, global wishes)
• Share common settings across different months
• Quickly set up new scheduling periods based on previous configurations

The template system requires a dedicated storage location that is:

• Case-specific (templates can vary by case)
• Persistent across months (templates should be available for any month within a case)

3. Growing Configuration Complexity

The application is expanding to manage more configuration files:

• weights.json - New feature to allow customization of solver optimization weights

Organizing these by month makes the structure more maintainable and scalable as we add more features.

4. Better Data Isolation

With month-based folders, each scheduling period is completely isolated:

• No risk of accidentally overwriting data from another month
• Clear audit trail of what was configured for each period
• Easier backup and restore of specific months