US-20 — Control access to notification functionality, part 2

## User Story

As a Central Production, I want users to have permissions appropriate to their responsibilities so that only authorised users can create, change or dispatch notifications.

A suitable permission model would distinguish between:

## Acceptance scenarios

```gherkin

Feature: Control access to Dispatcher functionality

Scenario: A user with Read permission views notifications
Given the user has "Read" permission
When the user opens the notification list
Then the user should be able to view notifications
And the user should be able to open notification details
But the user should not be able to create or edit a notification
And the user should not be able to dispatch or schedule a notification

Scenario: A user with Draft permission creates a notification
Given the user has "Read" and "Draft" permissions
When the user creates a notification
Then the user should be able to enter notification content
And the user should be able to save the notification as a draft

Scenario: A user with Draft permission edits a draft
Given the user has "Read" and "Draft" permissions
And a notification has status "draft"
When the user opens the notification
Then the user should be able to edit and save the draft

Scenario: A user with Draft permission cannot dispatch
Given the user has "Read" and "Draft" permissions
And the user does not have "Dispatch" permission
When the user opens a draft notification
Then the immediate dispatch action should not be available
And the scheduling action should not be available

Scenario: A user with Dispatch permission sends a notification
Given the user has "Read" and "Dispatch" permissions
And a valid notification is ready for delivery
When the user confirms the dispatch
Then the notification should be submitted to the selected communication channels
And the user should be recorded as the dispatcher

Scenario: A user with Dispatch permission schedules a notification
Given the user has "Read" and "Dispatch" permissions
And a valid notification is ready for delivery
When the user selects a valid future delivery time
And confirms the schedule
Then the notification should be scheduled
And the user should be recorded as the scheduling user

Scenario: A user without Dispatch permission attempts direct dispatch
Given the user does not have "Dispatch" permission
When the user attempts to call the dispatch operation directly
Then the request should be rejected
And the notification should not be dispatched
And the unauthorised attempt should be recorded

Scenario: A user without Draft permission attempts to update a draft
Given the user does not have "Draft" permission
When the user attempts to update a draft directly
Then the request should be rejected
And the draft should remain unchanged

Scenario: A user with Admin permission manages access
Given the user has "Admin" permission
When the user changes another user's Dispatcher permissions
Then the updated permissions should be stored
And the change should be recorded in the audit history

Scenario: Display only permitted actions
Given the user is authenticated
When a Dispatcher page is displayed
Then only actions permitted for that user should be visible or enabled

Scenario: Record who dispatched a notification
Given one user created the draft
And another user has Dispatch permission
When the second user dispatches the notification
Then the draft author should remain recorded
And the dispatching user should be recorded separately
And the dispatch date and time should be recorded

```

No files, tests, or entry points are named. Start by tracing the Dispatcher functionality described in the acceptance scenarios and map authentication, permission checks, permitted UI actions, dispatch operations, and audit history. Done means the Read, Draft, Dispatch, and Admin behaviors and rejection cases are covered.

Written by the indexing model from the issue text.