Permissions¶

The plugin defines standard Django permissions for each model: add, change, delete, and view. Permissions are namespaced under notices.<perm>_<model>.

Permission reference¶

The SentNotification proxy model has no permissions of its own: NetBox resolves proxy permissions to the concrete model, so viewing the sent list needs view_preparednotification. Granting notices.view_sentnotification or notices.delete_sentnotification has no effect.

Generating, approving and resetting notifications¶

Generation needs all three notification rights because a run can create, re-render and delete drafts. Object-level constraints are enforced per notification: the run checks each notification it creates, updates or deletes against the user's add, change or delete permissions, and one violation rolls the whole run back (403 from the API, an error message in the UI). Missing add, change or delete on prepared notifications is refused with 403; an event the user cannot view is not found (404). A dry run or preview writes nothing. Automatic generation (auto_generate_notifications) runs as the system and applies no user checks.

Which lists offer bulk actions¶

Bulk edit is offered where every editable field is a plain value. Prepared notifications are excluded -- their only field worth bulk-editing is status, which belongs to a state machine (see below); the other two notification lists have nothing bulk-editable at all.

Bulk delete is offered everywhere except the two archives:

• Sent notifications are a proxy over PreparedNotification, and deleting through it would bypass any PROTECTION_RULES registered against the concrete model. Delete those rows from the Prepared Notifications list, which keeps the action for that reason. The proxy is read-only throughout: no per-object delete route either, only a Changelog action.
• Received notifications carry the raw MIME message in a binary field, which the bulk delete confirmation page would load in full for every selected row. Still deletable one row at a time.

Status is not editable through the web UI¶

Change a prepared notification's status with the REST API:

PATCH /api/plugins/notices/prepared-notifications/<id>/
{"status": "ready"}

This requires notices.change_preparednotification, which otherwise covers a notification's content only. Status is absent from the edit form and the bulk edit view is unmounted, because a transition carries side effects -- snapshotting recipients, stamping approved_at / sent_at / delivered_at, and refusing to approve a notification with no recipients -- that only the state machine applies. A form writing the column directly would skip all of them.

The same rule covers creates: a POST has to leave status unset or set it to draft. There is no prior state to transition from, so the side effects never run, and ready has no transition back to draft to repair the record afterwards. Create the notification, then PATCH it.

Recommended role bindings¶

Object-level permissions¶

The plugin uses NetBox's standard RestrictedQuerySet patterns, so NetBox's object-level permission constraints (filter by JSON expression) work for every model. For example, restrict a parser token to a specific Provider:

{ "provider": 7 }

attached to a notices.add_maintenance permission with users set to the parser user limits that token to creating Maintenance events for provider 7 only.

API tokens for the iCal feed¶

The iCal feed (/api/plugins/notices/ical/) accepts three authentication modes (in order):

1. ?token=<plaintext> URL parameter (works with both v1 and v2 NetBox tokens; v2 tokens have the nbt_<key>.<plaintext> form).
2. Authorization: Token <plaintext> HTTP header.
3. Browser session cookie (when subscribing from a logged-in browser).

If LOGIN_REQUIRED = False is set in NetBox configuration, anonymous access is also accepted.

The feed checks notices.view_maintenance on the resolved user. Token-based access is the recommended way to subscribe a calendar app -- generate a per-user token in NetBox under Profile -> API Tokens and append it to the subscribe URL.

See the Calendar and iCal Feed page for the URL format and query parameters.