Background: The worklist needs a persistence layer that reads, writes, and deletes rows in ce_worklists, ce_worklist_articles, and ce_worklist_events. This task is only that data-access layer — no REST handlers and no UI.

Type of story

• Backend

Acceptance criteria

• A DB-backed layer exists for ce_worklists, ce_worklist_articles, ce_worklist_events that can create worklists, add articles to worklist and set worklist and event relations.
• The same layer can list an event’s worklist with pagination and return the total row count for that event.
• The same layer can tell whether a given article is already on an event’s worklist (matching how rows are identified in the table).
• The same layer can remove a worklist row, applying the product’s permission rules (organizer vs participant, where applicable).
• Unauthorized removal does not delete the row and fails in a controlled way.
• Behaviour is covered by automated tests appropriate to this scope.

Depends on

• task-1 (the ce_worklist_articles table must exist)

Testing required?

• Yes
• Minimum testing to pass QA: automated tests covering read, write, delete, and the permission behaviour owned by this layer.
• Tested end-to-end in: task-TBD (Worklist tab — add article form), task-TBD (article list table), task-TBD (delete action column)

Technical details

• Implement using the extension’s existing patterns for stores and service wiring

Split patches suggestion

• Single branch: DB layer scope end-to-end (contracts/types if needed, DB implementation, service registration, and tests).

Gherkin scenarios

Feature: Worklist article persistence (DB layer)

• Scenario: Add an article to an event worklist
  • Given event 42 exists
  • When the persistence layer records a worklist article for event 42
  • Then a row exists in ce_worklist_articles with cewa_event_id 42 and page fields consistent with the record

• Scenario: List worklist articles with pagination
  • Given event 42 has 5 worklist articles
  • When the first page is requested with page size 3
  • Then 3 articles are returned
  • When the next page is requested with page size 3
  • Then 2 articles are returned

• Scenario: Count worklist articles for an event
  • Given event 42 has 5 worklist articles
  • When the total count for event 42 is requested
  • Then the returned total is 5

• Scenario: Check whether an article is already on the worklist
  • Given event 42 already has a worklist article defined by the test fixture
  • When it is checked whether that article is on event 42's worklist
  • Then the result is true
  • When it is checked whether a different article is on event 42's worklist
  • Then the result is false

• Scenario: Organizer can remove any worklist row
  • Given event 42 has worklist row cewa_id 99
  • And the current user is an organizer of event 42
  • When removal of row 99 is requested as an organizer
  • Then no row with cewa_id 99 remains

• Scenario: Participant can remove a row they are allowed to remove
  • Given event 42 has worklist row cewa_id 99 for the current participant under the product rules
  • When removal of row 99 is requested as a participant
  • Then no row with cewa_id 99 remains

• Scenario: Participant cannot remove another user’s row when rules forbid it
  • Given event 42 has worklist row cewa_id 99 owned by another user under the product rules
  • And the current user is a participant (not organizer) of event 42
  • When removal of row 99 is requested as a participant
  • Then the operation fails in a controlled way with an outcome suitable for callers to map to HTTP 403
  • And a row with cewa_id 99 still exists