Content
View differences
Updated by Marc Alcobé 11 days ago
**As a** mobile user who participates in meetings
**I want to** create and manage a meeting agenda (sections + agenda items) and link agenda items to work packages, and (when the meeting is running) capture outcomes per topic
**so that** the meeting can be prepared, executed, and documented in a structured way from the mobile app.
### Acceptance Criteria
* **Agenda tab availability**
* The meeting detail screen includes an **Agenda** tab that lists agenda content.
* The Agenda tab is always available for all meetings statuses **Open**, **In progress**, and **Closed**.
* **Agenda structure**
* The agenda is composed of:
* **Sections** (grouping containers)
* **Agenda items** (text based topics) within a section
* **Linked work packages** per agenda item
* Agenda content renders in a single scrollable list with clear visual hierarchy:
* Section header (title)
* Agenda item rows beneath the section header
* Optional metadata badges (e.g., linked work package, type/status badges if applicable)
* **Create section**
* When meeting status is **Open** or **In progress**, the user can create a new section via an explicit action (e.g., “+ Add” → “Add section”).
* “Add section” prompts for:
* **Title** (required, non-empty after trimming whitespace)
* On successful create, the new section is displayed in the agenda list.
* **Create agenda item**
* When meeting status is **Open** or **In progress**, the user can create a new agenda item via an explicit action (e.g., “+ Add” → “Add agenda item”).
* “Add agenda item” prompts for:
* **Title** (required)
* **Duration** (optional; if provided must be a positive integer in minutes)
* **Presenter** (optional; selected from meeting participants if available)
* **Notes/Description** (optional text with rich text capabilities same as comment in work packages)
text)
* Very long notes will have the "Show more" expand capacbility as in the work packages descriptions
* **Section** assignment (required if at least one section exists; otherwise the system assigns it to an implicit default section or blocks creation until a section exists — see assumptions)
* On successful create, the agenda item is displayed under the chosen section.
* When editing an agenda item change the modal header to "Edit agenda item"
* **Link work package to agenda item**
* When meeting status is **Open** or **In progress**, the user can link a work package to an agenda item using an explicit action (e.g., “Add work package”).
* Linking flow allows the user to search/select an existing work package.
* After linking, the agenda item displays the linked work package reference.
* A linked work package can be removed/changed while the meeting is **Open** or **In progress**.
* **Reorder and move agenda elements**
* When meeting status is **Open** or **In progress**, the user can reorder:
* Sections within the agenda
* Agenda items within a section
* When meeting status is **Open** or **In progress**, the user can move agenda items:
* Between sections
* To top/bottom positions (as supported by UI actions)
* Reordering results persist after leaving and returning to the meeting screen.
* **Rename and delete agenda elements**
* When meeting status is **Open** or **In progress**, the user can:
* Rename a section
* Delete a section (only if empty, or deletion requires confirmation and also deletes contained agenda items — see assumptions)
* Edit an agenda item’s fields (title, duration, presenter, notes, section assignment)
* Delete an agenda item
* Delete actions require confirmation.
* **Outcomes availability (In progress only)**
* When meeting status is **In progress**, agenda topics remain visible.
* When meeting status is **In progress**, the user can add **Outcomes** linked to an agenda item (topic).
* Outcomes are not available to add/edit while meeting status is **Open** or **Closed**.
* **Add outcome (In progress only)**
* “Add outcome” is available from the context of a specific agenda item.
* Creating an outcome gives you three options:
* Write an outcome text (with rich text capabilities same as comment in work packages)
* Link an existing work package
* Create a new work package as outcome (when the work package creation form is completed the user needs to be back in the meeting agenda)
* On success, the outcome appears associated with that agenda item in the UI.
* **Edit/delete outcome (In progress only)**
* When meeting status is **In progress**, outcomes can be edited and deleted.
* Editing an outcome updates the displayed text immediately after save.
* Delete outcome requires confirmation.
* **Closed meeting behavior**
* When meeting status is **Closed**:
* Agenda content is read-only (no add/edit/delete/reorder for sections or agenda items)
* Outcomes are read-only (no add/edit/delete)
* Any UI actions that would modify agenda/outcomes are hidden or disabled with a clear read-only state.
* **Status transitions enforce rules**
* You can transition between all states, there is no required status workflow
* The UI reflects the new permissions immediately after the status change.
* **Failure handling**
* If a create/edit/delete operation fails (network/server error), the user sees an error message and no partial duplicate items are created.
### Technical Notes
* **Assumptions (data model)**
* A meeting has a single status field with values: `open`, `in_progress`, `closed`.
* Agenda sections and items are entities linked to a meeting.
* Outcomes are entities linked to an agenda item (and therefore indirectly to a meeting).
* **Status-based write constraints (server-side)**
* Enforce invariants in backend/API:
* If `meeting.status != open`: reject create/update/delete/reorder of sections and agenda items.
* If `meeting.status != in_progress`: reject create/update/delete of outcomes.
* If `meeting.status == closed`: reject all agenda/outcome writes.
* Return stable, explicit error codes (e.g., `MEETING_READ_ONLY`, `OUTCOMES_NOT_ALLOWED`) so mobile can show correct messaging.
* **API considerations (OpenProject API v3)**
* If agenda items link to work packages, use immutable work package identifiers (e.g., work package `id`) rather than titles.
* Linking should be implemented as a relation/reference, not as duplicated text, to avoid drift if work package title changes.
* Searching/selecting work packages on mobile should use paginated search endpoints and support debounced queries.
* **Frontend responsibilities**
* Derive UI enabled/disabled states from meeting status.
* Hide actions that are not permitted for the current status (preferred) or disable with explanatory text.
* Ensure optimistic updates are consistent with backend constraints:
* If optimistic create is used and server rejects due to status, revert local state and show error.
* **Ordering**
* Persist ordering via `position` fields (fractional ranking or integer reindexing).
* “Move up/down/top/bottom” operations should translate into deterministic position updates.
* **Performance**
* Agenda screen should load sections + items in one request (or one aggregated response) to avoid N+1 fetch patterns.
* Work package search should be throttled/debounced and cache recent results per meeting context.
* **Risks / edge cases**
* Meeting status changes while user is on the screen: mobile must refresh permissions and prevent submitting now-invalid edits.
* Concurrent edits: if multiple users reorder or edit simultaneously, define last-write-wins semantics or use versioning (ETag/`lockVersion`) to prevent silent overwrites.
### Permissions and Visibility Considerations
* **Assumptions (roles)**
* There is a concept of meeting-level permissions such as “can edit meeting agenda” and “can capture outcomes” (may map to project permissions).
* **Rules**
* Even when status allows actions:
* Only users with appropriate meeting/project permissions can add/edit/delete.
* Users without permission see the agenda/outcomes read-only.
* **Visibility**
* Work package search results should respect user visibility permissions:
* Only return work packages the user can view.
* **Read-only precedence**
* If meeting is `closed`, it is read-only regardless of user role.
* If meeting is `in_progress`, outcomes may be editable only if the user has edit permission; agenda remains read-only.
### Translation Considerations
* Localize UI labels and status names:
* “Agenda”, “Backlog”, “Details”, “Participants”, “Add”, “Add section”, “Add agenda item”, “Add outcome”, “Move up/down”, “Delete”, “Edit”, “Share”, “Rename section”
* Status display strings: “Open”, “In progress”, “Closed”
* Do **not** translate:
* Work package IDs (numeric identifiers)
* Work package type keys/status keys if shown as internal tokens
* Any API error codes (only translate user-facing error messages derived from them)
### Out of Scope
* Generating agenda content automatically from templates or AI suggestions.
* Minutes export formats (PDF/email) and external sharing beyond what is already supported.
* Advanced outcome types (decisions vs actions vs notes) unless explicitly required.
* Recurring meeting series management beyond selecting the current occurrence as it will be implemented in <mention class="mention" data-id="75224" data-type="work_package" data-text="###75224">###75224</mention>.
**I want to** create and manage a meeting agenda (sections + agenda items) and link agenda items to work packages, and (when the meeting is running) capture outcomes per topic
**so that** the meeting can be prepared, executed, and documented in a structured way from the mobile app.
### Acceptance Criteria
* **Agenda tab availability**
* The meeting detail screen includes an **Agenda** tab that lists agenda content.
* The Agenda tab is always available for all meetings statuses **Open**, **In progress**, and **Closed**.
* **Agenda structure**
* The agenda is composed of:
* **Sections** (grouping containers)
* **Agenda items** (text based topics) within a section
* **Linked work packages** per agenda item
* Agenda content renders in a single scrollable list with clear visual hierarchy:
* Section header (title)
* Agenda item rows beneath the section header
* Optional metadata badges (e.g., linked work package, type/status badges if applicable)
* **Create section**
* When meeting status is **Open** or **In progress**, the user can create a new section via an explicit action (e.g., “+ Add” → “Add section”).
* “Add section” prompts for:
* **Title** (required, non-empty after trimming whitespace)
* On successful create, the new section is displayed in the agenda list.
* **Create agenda item**
* When meeting status is **Open** or **In progress**, the user can create a new agenda item via an explicit action (e.g., “+ Add” → “Add agenda item”).
* “Add agenda item” prompts for:
* **Title** (required)
* **Duration** (optional; if provided must be a positive integer in minutes)
* **Presenter** (optional; selected from meeting participants if available)
* **Notes/Description** (optional text with rich text capabilities same as comment in work packages)
* **Section** assignment (required if at least one section exists; otherwise the system assigns it to an implicit default section or blocks creation until a section exists — see assumptions)
* On successful create, the agenda item is displayed under the chosen section.
* When editing an agenda item change the modal header to "Edit agenda item"
* **Link work package to agenda item**
* When meeting status is **Open** or **In progress**, the user can link a work package to an agenda item using an explicit action (e.g., “Add work package”).
* Linking flow allows the user to search/select an existing work package.
* After linking, the agenda item displays the linked work package reference.
* A linked work package can be removed/changed while the meeting is **Open** or **In progress**.
* **Reorder and move agenda elements**
* When meeting status is **Open** or **In progress**, the user can reorder:
* Sections within the agenda
* Agenda items within a section
* When meeting status is **Open** or **In progress**, the user can move agenda items:
* Between sections
* To top/bottom positions (as supported by UI actions)
* Reordering results persist after leaving and returning to the meeting screen.
* **Rename and delete agenda elements**
* When meeting status is **Open** or **In progress**, the user can:
* Rename a section
* Delete a section (only if empty, or deletion requires confirmation and also deletes contained agenda items — see assumptions)
* Edit an agenda item’s fields (title, duration, presenter, notes, section assignment)
* Delete an agenda item
* Delete actions require confirmation.
* **Outcomes availability (In progress only)**
* When meeting status is **In progress**, agenda topics remain visible.
* When meeting status is **In progress**, the user can add **Outcomes** linked to an agenda item (topic).
* Outcomes are not available to add/edit while meeting status is **Open** or **Closed**.
* **Add outcome (In progress only)**
* “Add outcome” is available from the context of a specific agenda item.
* Creating an outcome gives you three options:
* Write an outcome text (with rich text capabilities same as comment in work packages)
* Link an existing work package
* Create a new work package as outcome (when the work package creation form is completed the user needs to be back in the meeting agenda)
* On success, the outcome appears associated with that agenda item in the UI.
* **Edit/delete outcome (In progress only)**
* When meeting status is **In progress**, outcomes can be edited and deleted.
* Editing an outcome updates the displayed text immediately after save.
* Delete outcome requires confirmation.
* **Closed meeting behavior**
* When meeting status is **Closed**:
* Agenda content is read-only (no add/edit/delete/reorder for sections or agenda items)
* Outcomes are read-only (no add/edit/delete)
* Any UI actions that would modify agenda/outcomes are hidden or disabled with a clear read-only state.
* **Status transitions enforce rules**
* You can transition between all states, there is no required status workflow
* The UI reflects the new permissions immediately after the status change.
* **Failure handling**
* If a create/edit/delete operation fails (network/server error), the user sees an error message and no partial duplicate items are created.
### Technical Notes
* **Assumptions (data model)**
* A meeting has a single status field with values: `open`, `in_progress`, `closed`.
* Agenda sections and items are entities linked to a meeting.
* Outcomes are entities linked to an agenda item (and therefore indirectly to a meeting).
* **Status-based write constraints (server-side)**
* Enforce invariants in backend/API:
* If `meeting.status != open`: reject create/update/delete/reorder of sections and agenda items.
* If `meeting.status != in_progress`: reject create/update/delete of outcomes.
* If `meeting.status == closed`: reject all agenda/outcome writes.
* Return stable, explicit error codes (e.g., `MEETING_READ_ONLY`, `OUTCOMES_NOT_ALLOWED`) so mobile can show correct messaging.
* **API considerations (OpenProject API v3)**
* If agenda items link to work packages, use immutable work package identifiers (e.g., work package `id`) rather than titles.
* Linking should be implemented as a relation/reference, not as duplicated text, to avoid drift if work package title changes.
* Searching/selecting work packages on mobile should use paginated search endpoints and support debounced queries.
* **Frontend responsibilities**
* Derive UI enabled/disabled states from meeting status.
* Hide actions that are not permitted for the current status (preferred) or disable with explanatory text.
* Ensure optimistic updates are consistent with backend constraints:
* If optimistic create is used and server rejects due to status, revert local state and show error.
* **Ordering**
* Persist ordering via `position` fields (fractional ranking or integer reindexing).
* “Move up/down/top/bottom” operations should translate into deterministic position updates.
* **Performance**
* Agenda screen should load sections + items in one request (or one aggregated response) to avoid N+1 fetch patterns.
* Work package search should be throttled/debounced and cache recent results per meeting context.
* **Risks / edge cases**
* Meeting status changes while user is on the screen: mobile must refresh permissions and prevent submitting now-invalid edits.
* Concurrent edits: if multiple users reorder or edit simultaneously, define last-write-wins semantics or use versioning (ETag/`lockVersion`) to prevent silent overwrites.
### Permissions and Visibility Considerations
* **Assumptions (roles)**
* There is a concept of meeting-level permissions such as “can edit meeting agenda” and “can capture outcomes” (may map to project permissions).
* **Rules**
* Even when status allows actions:
* Only users with appropriate meeting/project permissions can add/edit/delete.
* Users without permission see the agenda/outcomes read-only.
* **Visibility**
* Work package search results should respect user visibility permissions:
* Only return work packages the user can view.
* **Read-only precedence**
* If meeting is `closed`, it is read-only regardless of user role.
* If meeting is `in_progress`, outcomes may be editable only if the user has edit permission; agenda remains read-only.
### Translation Considerations
* Localize UI labels and status names:
* “Agenda”, “Backlog”, “Details”, “Participants”, “Add”, “Add section”, “Add agenda item”, “Add outcome”, “Move up/down”, “Delete”, “Edit”, “Share”, “Rename section”
* Status display strings: “Open”, “In progress”, “Closed”
* Do **not** translate:
* Work package IDs (numeric identifiers)
* Work package type keys/status keys if shown as internal tokens
* Any API error codes (only translate user-facing error messages derived from them)
### Out of Scope
* Generating agenda content automatically from templates or AI suggestions.
* Minutes export formats (PDF/email) and external sharing beyond what is already supported.
* Advanced outcome types (decisions vs actions vs notes) unless explicitly required.
* Recurring meeting series management beyond selecting the current occurrence as it will be implemented in <mention class="mention" data-id="75224" data-type="work_package" data-text="###75224">###75224</mention>.