One-time project

# Requirements: Dynamic Forms Inside Project Tasks (Odoo 18) ## Overview Add the ability to select and fill a "form template" (e.g., inspection/report forms) directly from within a Project Task (`project.task`). The user picks a form type, fills it in, adds a signature, saves it linked to that task, and prints it as PDF. ## User Flow 1. Open a task. 2. Click "Add Form." 3. Choose a form type from a predefined list. 4. Form opens with some fields auto-filled from the task. 5. User fills remaining fields (text, selections, images). 6. User signs electronically. 7. Save → record is stored linked to the task, visible in a "Forms" tab/list. 8. User can reopen or print the saved form as PDF. ## Auto-Filled Fields (from Task) | Form Field | Source | |---|---| | Task title/number | `task.name` | | Project name | `task.project_id.name` | | Location/title | task location field (or custom field) | | Date | today (default) | | Responsible/engineer | `task.user_ids` or current user | | Customer | `task.partner_id` | Use `related` fields where the value should stay live, or `default` where it should freeze at creation time. ## Suggested Technical Structure - **Template model** (`task.form.template`): defines available form types. - **Filled-entry model** (`task.form.entry`): fields include `task_id` (M2O → project.task), `form_type`/`template_id`, form-specific data, `signature` (binary), and `state` (draft/signed/final). - **Task integration**: add `form_entry_ids` (One2many) on `project.task`, plus a new "Forms" tab on the Task form view. - **Selector**: button/dropdown in the Forms tab to pick a type and open the entry form. - **Signature**: use Odoo's built-in signature widget, or a custom OWL widget if more control is needed. - **Printing**: a QWeb report per form type, matching the original form's layout (RTL/Arabic support if required, consistent with existing SEC forms). ### Important Architecture Note Due to Odoo 18 view-validation issues, create any new views and access rights for these forms via `post_init_hook` rather than manifest `data` files, to avoid XML validation errors on install — same approach used successfully in the araptech module. ## Functional Requirements 1. "Forms" tab on the Task form view. 2. Button/dropdown to select a form type from predefined templates. 3. Auto-fill task-related fields per the table above. 4. Manual entry for remaining fields, per form type. 5. Mandatory e-signature before final save (or per workflow state). 6. Save as a record linked to the task (visible in a list within the tab). 7. Reopen/edit saved forms while not yet finalized. 8. PDF print button matching the original form's layout. 9. (Optional) Allow multiple forms (same or different types) per task. 10. (Optional) Role-based permissions for create/edit/sign (e.g., engineer vs. admin). ## Open Questions Before Development - Are the only forms needed the existing SEC forms, or will new types be added later? (Determines whether we need a generic dynamic-template system or fixed models per form.) - Can a form be edited after signing, or does it become read-only? - Is more than one entry of the same form type allowed per task? - Does printing need RTL/Arabic support (as with prior SEC forms)? ## Acceptance Criteria - [ ] "Forms" tab appears on the task with a type-selection control. - [ ] Selecting a form type auto-fills task name/project/location correctly, with no manual error risk. - [ ] Form cannot be saved without a signature (per decision above). - [ ] Saved forms are only accessible from within their parent task. - [ ] Print button generates a PDF matching the original layout, including signature. - [ ] No XML validation errors on module install/update (via post_init_hook approach).