374 lines
10 KiB
Markdown
374 lines
10 KiB
Markdown
# Dynamic Application System Architecture
|
|
|
|
## Overview
|
|
|
|
This document describes the new fully dynamic application system that replaces the previous fixed QSM/VSM structure. The system now allows administrators to define any type of application with custom fields, statuses, and workflows.
|
|
|
|
## Core Concepts
|
|
|
|
### 1. Application Types
|
|
|
|
Application types are fully configurable templates that define:
|
|
- **Fields**: Dynamic field definitions with types, validation, and display rules
|
|
- **Statuses**: Custom status workflow with transitions
|
|
- **PDF Templates**: Optional PDF template with field mapping
|
|
- **Access Control**: Role-based access restrictions
|
|
- **Limits**: Maximum cost positions and comparison offers
|
|
|
|
### 2. Fields
|
|
|
|
Fields are the building blocks of applications with the following types:
|
|
- `text_short`: Short text input (max 255 chars)
|
|
- `text_long`: Long text/textarea
|
|
- `options`: Single selection from predefined options
|
|
- `yesno`: Boolean yes/no field
|
|
- `mail`: Email address with validation
|
|
- `date`: Date picker
|
|
- `datetime`: Date and time picker
|
|
- `amount`: Numeric amount field
|
|
- `currency_eur`: EUR currency field with formatting
|
|
- `number`: General numeric field
|
|
- `file`: File upload
|
|
- `signature`: Digital signature field
|
|
- `phone`: Phone number with validation
|
|
- `url`: URL with validation
|
|
- `checkbox`: Single checkbox
|
|
- `radio`: Radio button group
|
|
- `select`: Dropdown selection
|
|
- `multiselect`: Multiple selection
|
|
|
|
Each field supports:
|
|
- **Validation Rules**: min/max values, patterns, required status
|
|
- **Display Conditions**: Show/hide based on other field values
|
|
- **Default Values**: Pre-filled values
|
|
- **Placeholders & Help Text**: User guidance
|
|
|
|
### 3. Status System
|
|
|
|
Statuses define the workflow states:
|
|
- **Editability**: Whether the application can be edited
|
|
- **Visual Style**: Color and icon for UI
|
|
- **Notifications**: Email templates for status changes
|
|
- **Transitions**: Rules for moving between statuses
|
|
|
|
### 4. Transitions
|
|
|
|
Transitions define how applications move between statuses:
|
|
|
|
**Trigger Types:**
|
|
- `user_approval`: Requires N users with specific role to approve
|
|
- `applicant_action`: Button/action by the applicant
|
|
- `deadline_expired`: Automatic when a deadline passes
|
|
- `time_elapsed`: After a specific time period
|
|
- `condition_met`: When field conditions are satisfied
|
|
- `automatic`: Immediate automatic transition
|
|
|
|
## Database Schema
|
|
|
|
### Core Tables
|
|
|
|
1. **application_types**
|
|
- Defines application type templates
|
|
- Stores PDF template as BLOB
|
|
- Contains field mapping configuration
|
|
|
|
2. **application_fields**
|
|
- Field definitions for each type
|
|
- Validation rules as JSON
|
|
- Display conditions as JSON
|
|
|
|
3. **application_type_statuses**
|
|
- Status definitions per type
|
|
- Visual configuration (color, icon)
|
|
- Notification templates
|
|
|
|
4. **status_transitions**
|
|
- Transition rules between statuses
|
|
- Trigger configuration
|
|
- Conditions and actions
|
|
|
|
5. **dynamic_applications**
|
|
- Actual application instances
|
|
- Common fields (email, title, names)
|
|
- Dynamic field_data as JSON
|
|
- Cost positions and comparison offers as JSON
|
|
|
|
6. **application_history_v2**
|
|
- Complete audit trail
|
|
- Field-level change tracking
|
|
- User and IP tracking
|
|
|
|
7. **application_approvals**
|
|
- Approval decisions by role
|
|
- Comments and timestamps
|
|
|
|
## API Endpoints
|
|
|
|
### Application Types Management
|
|
|
|
```
|
|
GET /api/application-types - List all types
|
|
GET /api/application-types/{id} - Get specific type
|
|
POST /api/application-types - Create new type (admin)
|
|
PUT /api/application-types/{id} - Update type (admin)
|
|
DELETE /api/application-types/{id} - Delete type (admin)
|
|
POST /api/application-types/{id}/pdf-template - Upload PDF template
|
|
```
|
|
|
|
### Dynamic Applications
|
|
|
|
```
|
|
GET /api/applications - List applications
|
|
GET /api/applications/{id} - Get application details
|
|
POST /api/applications - Create new application
|
|
PUT /api/applications/{id} - Update application
|
|
POST /api/applications/{id}/submit - Submit for review
|
|
POST /api/applications/{id}/transition - Change status (admin)
|
|
POST /api/applications/{id}/approve - Approve/reject
|
|
GET /api/applications/{id}/history - Get history
|
|
POST /api/applications/{id}/generate-pdf - Generate PDF
|
|
```
|
|
|
|
## Common Fields
|
|
|
|
The following fields are always present (not dynamic):
|
|
|
|
1. **Email**: Applicant's email address
|
|
2. **Status**: Current workflow status
|
|
3. **Type**: Application type reference
|
|
4. **Title**: Application title/subject
|
|
5. **First Name**: Applicant's first name
|
|
6. **Last Name**: Applicant's last name
|
|
7. **Timestamps**: Created, submitted, status changed, completed
|
|
8. **Cost Positions**: Up to 100 items with description, amount, category
|
|
9. **Comparison Offers**: Up to 100 vendor offers
|
|
|
|
## Frontend Components
|
|
|
|
### Dynamic Field Renderer
|
|
|
|
The frontend includes a dynamic field rendering system that:
|
|
- Renders fields based on type
|
|
- Applies validation rules
|
|
- Handles display conditions
|
|
- Manages field dependencies
|
|
|
|
### Status Workflow UI
|
|
|
|
Visual workflow display showing:
|
|
- Current status with color/icon
|
|
- Available actions
|
|
- Transition history
|
|
- Approval tracking
|
|
|
|
### Admin Interface
|
|
|
|
Application type builder with:
|
|
- Drag-and-drop field designer
|
|
- Visual workflow editor
|
|
- PDF template mapper
|
|
- Role management
|
|
|
|
## Migration from Old System
|
|
|
|
### Data Migration Steps
|
|
|
|
1. **Create new tables** - Run migration script
|
|
2. **Define standard types** - Create QSM/VSM as dynamic types
|
|
3. **Map existing data** - Convert old applications to new format
|
|
4. **Update references** - Point to new tables
|
|
5. **Remove old tables** - Clean up after verification
|
|
|
|
### Field Mapping
|
|
|
|
Old QSM/VSM fields map to dynamic fields:
|
|
|
|
```json
|
|
{
|
|
"project.name": "project_name",
|
|
"applicant.name.first": "first_name",
|
|
"applicant.name.last": "last_name",
|
|
"applicant.contact.email": "email",
|
|
"project.costs": "cost_positions",
|
|
"project.totals.requestedAmountEur": "total_amount"
|
|
}
|
|
```
|
|
|
|
## Security & Access Control
|
|
|
|
### Role-Based Access
|
|
|
|
- **Admin**: Full access to type management and all applications
|
|
- **Budget Reviewer**: Review and approve budget-related applications
|
|
- **Finance Reviewer**: Financial review and approval
|
|
- **AStA Member**: Voting rights on applications
|
|
- **Applicant**: Create and edit own applications
|
|
|
|
### Public Access
|
|
|
|
Applications can be accessed via:
|
|
- **Authenticated**: Full access based on role
|
|
- **Access Key**: Limited access with unique key
|
|
- **Public Link**: Read-only access if configured
|
|
|
|
## Configuration
|
|
|
|
### Environment Variables
|
|
|
|
```env
|
|
# Database
|
|
DATABASE_URL=mysql://user:pass@localhost/stupa_db
|
|
|
|
# Email
|
|
SMTP_HOST=smtp.example.com
|
|
SMTP_PORT=587
|
|
SMTP_USER=noreply@example.com
|
|
SMTP_PASSWORD=secret
|
|
FROM_EMAIL=noreply@example.com
|
|
FROM_NAME=Application System
|
|
|
|
# Security
|
|
JWT_SECRET_KEY=your-secret-key
|
|
ACCESS_TOKEN_EXPIRE_MINUTES=30
|
|
|
|
# Storage
|
|
PDF_OUTPUT_DIR=./uploads/pdfs
|
|
ATTACHMENT_DIR=./uploads/attachments
|
|
MAX_UPLOAD_SIZE=10485760
|
|
|
|
# Frontend
|
|
BASE_URL=https://applications.example.com
|
|
```
|
|
|
|
### Application Type Example
|
|
|
|
```json
|
|
{
|
|
"type_id": "travel_grant",
|
|
"name": "Travel Grant Application",
|
|
"description": "Apply for travel funding",
|
|
"fields": [
|
|
{
|
|
"field_id": "destination",
|
|
"field_type": "text_short",
|
|
"name": "Destination",
|
|
"is_required": true,
|
|
"validation_rules": {
|
|
"max_length": 100
|
|
}
|
|
},
|
|
{
|
|
"field_id": "purpose",
|
|
"field_type": "text_long",
|
|
"name": "Purpose of Travel",
|
|
"is_required": true,
|
|
"validation_rules": {
|
|
"min_length": 50,
|
|
"max_length": 500
|
|
}
|
|
},
|
|
{
|
|
"field_id": "travel_date",
|
|
"field_type": "date",
|
|
"name": "Travel Date",
|
|
"is_required": true,
|
|
"validation_rules": {
|
|
"min_date": "2024-01-01"
|
|
}
|
|
},
|
|
{
|
|
"field_id": "amount_requested",
|
|
"field_type": "currency_eur",
|
|
"name": "Amount Requested",
|
|
"is_required": true,
|
|
"validation_rules": {
|
|
"min": 0,
|
|
"max": 5000
|
|
}
|
|
}
|
|
],
|
|
"statuses": [
|
|
{
|
|
"status_id": "draft",
|
|
"name": "Draft",
|
|
"is_editable": true,
|
|
"color": "#6B7280",
|
|
"is_initial": true
|
|
},
|
|
{
|
|
"status_id": "submitted",
|
|
"name": "Submitted",
|
|
"is_editable": false,
|
|
"color": "#3B82F6",
|
|
"send_notification": true
|
|
},
|
|
{
|
|
"status_id": "approved",
|
|
"name": "Approved",
|
|
"is_editable": false,
|
|
"color": "#10B981",
|
|
"is_final": true
|
|
},
|
|
{
|
|
"status_id": "rejected",
|
|
"name": "Rejected",
|
|
"is_editable": false,
|
|
"color": "#EF4444",
|
|
"is_final": true
|
|
}
|
|
],
|
|
"transitions": [
|
|
{
|
|
"from_status_id": "draft",
|
|
"to_status_id": "submitted",
|
|
"name": "Submit Application",
|
|
"trigger_type": "applicant_action"
|
|
},
|
|
{
|
|
"from_status_id": "submitted",
|
|
"to_status_id": "approved",
|
|
"name": "Approve",
|
|
"trigger_type": "user_approval",
|
|
"trigger_config": {
|
|
"role": "admin",
|
|
"required_approvals": 1
|
|
}
|
|
},
|
|
{
|
|
"from_status_id": "submitted",
|
|
"to_status_id": "rejected",
|
|
"name": "Reject",
|
|
"trigger_type": "user_approval",
|
|
"trigger_config": {
|
|
"role": "admin",
|
|
"required_approvals": 1
|
|
}
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
## Advantages of Dynamic System
|
|
|
|
1. **Flexibility**: Create any type of application without code changes
|
|
2. **Maintainability**: All configuration in database, no hardcoded logic
|
|
3. **Scalability**: Same infrastructure handles all application types
|
|
4. **User Experience**: Consistent interface across all applications
|
|
5. **Compliance**: Built-in audit trail and approval workflows
|
|
6. **Integration**: PDF generation works with any template
|
|
7. **Future-Proof**: Easy to add new field types and features
|
|
|
|
## Performance Considerations
|
|
|
|
- **JSON Fields**: Indexed for fast searching
|
|
- **Caching**: Application types cached in memory
|
|
- **Lazy Loading**: Field data loaded on demand
|
|
- **Batch Operations**: Support for bulk status changes
|
|
- **Async Processing**: PDF generation in background
|
|
|
|
## Backup and Recovery
|
|
|
|
- **Daily Backups**: Automated database backups
|
|
- **Version History**: All changes tracked in history tables
|
|
- **Soft Deletes**: Applications marked as deleted, not removed
|
|
- **Export/Import**: JSON format for data portability |