Neuro Feature Atlas

Intranet communications (threads, confirmations, authorisations)

Intranet · Intranet communications (threads, confirmations, authorisations)

Internal messaging between centre management and stores: typed communications (issues, access authorisations, general notices) with threads and responses, per-recipient read/confirm tracking, state changes, urgency flags, a signed confirmation PDF and a CSV export of recipients.

AreaIntranet
Routesintranet.communications · intranet.communications.index · intranet.communications.new · intranet.communications.show
Centre modulesintranet
Staff levelsroot · admin · manager · scmanager · storeManager · commerce · services
Modelscommerce · intranet-communication · intranet-staff · intranet-subtype · staff-member
UI labeltitle.header.communication / menu.navbar.intranet.communication.index
Coverage6 use cases · 3 happy · 10 failure

Known issues (1)

Missing translations

These keys are used on this screen but do not exist in translations.json, so users see the raw key:

  • error.communication.store.required
  • intranet.communications.terms-and-conditions

How it works

Permission logic here is the most explicit in the codebase and uses dedicated error classes rather than booleans: changeState throws NotAllowedError when the user is not management, when their staff level equals the communication’s from_role, or when the type is not issue/access; confirm throws IllegalStateError if already confirmed and NotAllowedError if the user’s level may not confirm; respondTo throws when the responder’s role does not match. A business rule is encoded in a validation message: an access authorisation must be dated at least 48 hours after creation unless the Urgent flag is set (error.communication.date.invalid). Confirmation is tracked per recipient (total_confirmed, confirmed, viewed, received) and a per-recipient PDF is downloadable from /v3/intranet_communications/:id/confirm_receipt, saved as <email>_confirmation.pdf. The index can filter by source and type (changeSource, changeType, changeFiltersWithSource) and uses a v3 meta shape (metaV3).

Use cases

Why someone opens this (6)

  • Management broadcasting an operational notice to all stores and seeing who has read and confirmed it.
  • A store raising an issue (e.g. a maintenance fault) and following the thread to resolution.
  • Requesting access authorisation for contractors, with companion details and a 48-hour notice rule.
  • Downloading a signed confirmation PDF as proof a store acknowledged a notice.
  • Exporting the recipient list with read/confirm status for compliance.
  • Duplicating a recurring notice.

Path map

flowchart LR
    F(["Intranet communications threads, confirmations,…"]):::feat
    F --> H1["Notice sent and confirmed"]:::ok
    F --> H2["Access authorisation with companions"]:::ok
    F --> H3["Recipients exported"]:::ok
    F -.-> X1["Access date too soon"]:::bad
    F -.-> X2["No recipient store"]:::bad
    F -.-> X3["Companion data incomplete"]:::bad
    F -.-> X4["State change not allowed"]:::bad
    F -.-> X5["Double confirmation"]:::bad
    F -.-> X6["Response from the wrong role"]:::bad
    F -.-> X7["Staff update fails"]:::bad
    F -.-> X8["Confirmation PDF unavailable"]:::bad
    F -.-> X9["Detail not permitted"]:::bad
    F -.-> X10["Raw translation key on screen"]:::bad
    classDef feat fill:#26688f,stroke:#26688f,color:#ffffff,font-weight:bold
    classDef ok fill:#e3f1ea,stroke:#0d6b42,color:#0d4a2e
    classDef bad fill:#f7e6e2,stroke:#9a2d1c,color:#6e1f13

Happy paths

Notice sent and confirmed

  1. Management creates a communication, picks a subtype and selects the recipient stores.
  2. Stores receive it; each recipient’s received/viewed state updates as they open it.
  3. A store user clicks confirm; confirm checks it is not already confirmed and that their level may confirm, then sets confirmed.
  4. total_confirmed increases on the index and management downloads the confirmation PDF.

Access authorisation with companions

  1. A store creates an access communication at least 48 hours ahead, listing companions.
  2. Validation passes and the authorisation is sent.
  3. Management changes its state as it is processed.

Recipients exported

  1. Management opens the show view and triggers the CSV export of recipients.
  2. informative-message.export-crm-csv.success.message confirms the emailed file.

Failure paths

QA checklist

Tick these off while regression-testing this feature. The boxes are plain Markdown, so progress is visible in git diffs.

  • ✅ Notice sent and confirmed
  • ✅ Access authorisation with companions
  • ✅ Recipients exported
  • ⛔ Access date too soon
  • ⛔ No recipient store
  • ⛔ Companion data incomplete
  • ⛔ State change not allowed
  • ⛔ Double confirmation
  • ⛔ Response from the wrong role
  • ⛔ Staff update fails
  • ⛔ Confirmation PDF unavailable
  • ⛔ Detail not permitted
  • ⛔ Raw translation key on screen

Implementation

Generated from doc/feature-inventory.json · id intranet-communications · commit 276788ca6

Graph View

Backlinks