- Implement test script for new SAG module endpoints BE-003 (Tag State Management) and BE-004 (Bulk Operations). - Create test cases for creating, updating, and bulk operations on cases and tags. - Add a test for module deactivation to ensure data integrity is maintained. - Include setup and teardown for tests to clear database state before and after each test.
4.2 KiB
4.2 KiB
Sag Module Documentation
Overview
The Sag Module is a universal case management system where tickets, tasks, and orders are all represented as cases with different tags and relations. The core idea is that there is only one entity: a case. All other attributes are metadata, tags, and relations.
Database Schema
sag_sager (Main Table for Cases)
- Columns:
id: Primary keytitel:VARCHAR- Title of the casebeskrivelse:TEXT- Detailed descriptiontemplate_key:VARCHAR, NULL- Used only during creation, no business logicstatus:VARCHAR- Allowed values:'åben','lukket'customer_id: Foreign key, nullableansvarlig_bruger_id: Foreign key, nullablecreated_by_user_id: Foreign key, not nullabledeadline:TIMESTAMP, nullablecreated_at:TIMESTAMPupdated_at:TIMESTAMPdeleted_at:TIMESTAMP(soft-delete)
sag_relationer (Relations Between Cases)
- Columns:
id: Primary keykilde_sag_id: Foreign key (source case)målsag_id: Foreign key (target case)relationstype:VARCHAR- Examples:'derived','blocks','executes'created_at:TIMESTAMPdeleted_at:TIMESTAMP
sag_tags (Process and Categorization)
- Columns:
id: Primary keysag_id: Foreign key (case reference)tag_navn:VARCHAR- Name of the tagstate:VARCHAR DEFAULT 'open'-'open'(not completed),'closed'(completed)closed_at:TIMESTAMP, nullablecreated_at:TIMESTAMPdeleted_at:TIMESTAMP
API Endpoints
Cases
GET /api/v1/cases- List all cases with optional filters.POST /api/v1/cases- Create a new case.GET /api/v1/cases/{id}- Retrieve a specific case by ID.PATCH /api/v1/cases/{id}- Update a specific case.DELETE /api/v1/cases/{id}- Soft-delete a specific case.
Relations
GET /api/v1/cases/{id}/relations- List all relations for a specific case.POST /api/v1/cases/{id}/relations- Create a new relation for a case.DELETE /api/v1/cases/{id}/relations/{relation_id}- Soft-delete a specific relation.
Tags
GET /api/v1/cases/{id}/tags- List all tags for a specific case.POST /api/v1/cases/{id}/tags- Add a tag to a case.DELETE /api/v1/cases/{id}/tags/{tag_id}- Soft-delete a specific tag.
Frontend Views
Case List
- Route:
/cases - Description: Displays a list of all cases with filters for status and tags.
- Template:
index.html
Case Details
- Route:
/cases/{case_id} - Description: Displays detailed information about a specific case, including its tags and relations.
- Template:
detail.html
Features
- Soft-Delete: Cases, relations, and tags are not permanently deleted. Instead, they are marked with a
deleted_attimestamp. - Tag-Based Workflow: Tags represent tasks or categories and can be marked as
openorclosed. - Relations: Cases can be related to each other with directional and transitive relations.
Development Notes
- All database queries use
execute_query()fromapp.core.database. - Queries are parameterized with
%splaceholders to prevent SQL injection. RealDictCursoris used for dict-like row access.- Triggers automatically update the
updated_atcolumn. - Relations are first-class citizens and are not just links.
Example Workflows
Example 1: Support Ticket
- A customer calls to request a new monitor.
- A case is created with the tag
supportand marked asurgent. - The case is assigned to a support agent.
Example 2: Order Processing
- A case is created for purchasing a monitor with the tag
indkøb. - The case is related to the support ticket as
derived. - The purchasing manager is assigned to the case.
Example 3: Shipping
- A case is created for packaging and shipping the monitor with the tag
ompakning. - The case is related to the order case as
executes. - The shipping department is assigned to the case.
Module Deactivation
- When the module is deactivated, all data is preserved.
- Soft-deleted data remains in the database for potential rollback.
- Ensure no active cases are left in an inconsistent state before deactivation.