⚡ [Feature]: Implement CRUD management for absence codes

[PPeitsch]

Problem Description

The current system for recording time entries other than a "Work Day" uses a static, hardcoded list of absence codes (e.g., "LAR", "FRANCO COMPENSATORIO", "LICENCIA MÉDICA"). These codes were created for initial testing and are not configurable by the user.

This is a major limitation because different companies, regions, or even individual users have their own unique sets of codes for tracking absences (e.g., vacation, personal day, training, etc.). The application is therefore not adaptable to real-world scenarios, forcing users to work with irrelevant or incomplete options.

Proposed Solution

To solve this, we will implement a full CRUD (Create, Read, Update, Delete) management system for absence codes, accessible from the application's user interface.

1. Create a Settings/Admin Interface:

   • A new page will be created (e.g., /settings/absences) where a user can manage the codes.
   • This page will display a table of all current absence codes from the database.
   • It will include forms and buttons to add a new code, edit the description of an existing one, and delete codes that are no longer needed.

2. Develop Backend API Endpoints:

   • New routes will be created in the Flask backend to handle the CRUD operations initiated from the settings interface.

3. Dynamically Populate the Entry Form:

   • The dropdown menu in the "Manual Entry" form (manual_entry.html) will be modified. Instead of containing static <option> tags, it will be populated dynamically with the absence codes fetched from the AbsenceCode table in the database. This ensures that the entry form always reflects the user's customized list of codes.

Alternatives Considered

• Editing a configuration file (e.g., config.json): We could allow users to define codes in a file. However, this is not user-friendly, requires server access, and is prone to formatting errors. A web interface is a much more robust and accessible solution.
• Keeping the current system: This is not a viable long-term option as it severely limits the application's core utility and target audience.

Additional Context

This feature is a crucial step towards making TimeTrack a flexible, production-ready tool. It primarily involves creating a new set of routes and templates for management, and modifying the existing manual_entry route and template to consume the dynamic data.

Implementation

• I would be willing to implement this feature myself