Rhythm 2.0 Specifications

Appearance

CAP-PFM-NOT-011Review workspace notification activity

Markdown

CAP-PFM-NOT-011

Review workspace notification activity

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

Planning

Feature
FEAT-PFM-NOT-04
Key concepts
CON-PFM-NOT-003
Actors
ACT-PFM-028
Journeys
JNY-PFM-NOT-002, JNY-PFM-NOT-003
Depends on
CAP-PFM-NOT-002, CAP-PFM-NOT-003
Related
CAP-PFM-NOT-010, CAP-PFM-NOT-012
Proved by
ATS-PFM-NOT-011
Executed by
TST-PFM-NOT-002, TST-PFM-NOT-003, TST-PFM-NOT-013, TST-PFM-NOT-014, TST-PFM-NOT-021, TST-PFM-NOT-069, TST-PFM-NOT-073, TST-PFM-NOT-094, TST-PFM-NOT-109

KindCapabilityProduct areaPlatformModuleStaff Notifications and Association CommunicationsRevision1

Read atservices-platform ad3f6a65react-console baf6dae3

Review workspace notification activity ​

Purpose ​

Administrators can inspect whom the workspace notified and why requests succeeded or produced no notices.

How It Works ​

An administrator opens workspace notification History with management permission. The list combines recipients, requests and channel summaries. Filters locate relevant activity, and paging can continue across monthly partitions. A separate request view includes invalid or empty-audience submissions. Opening a row follows the chain between requests, notices, deliveries and events. Returned data retains scope information while link values are redacted. All reads remain inside the selected workspace. The intended skipped-channel milestone wording still has a recorded console defect.

The rule rows define this outcome; the acceptance set identifies existing proof and proposed checks. Implementation evidence alone does not approve the observed details.

Relationships ​

Committed publication supplies the requests processed by this outcome.

Recipient selection supplies the eligible people and their audience explanations.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Administrators inspect notification activity within authorized workspace scope.History distinguishes requests, recipient instances and channel deliveries.
Surfaces
consoleapi
Intent sources
services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#2. Scopeservices-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#3. How it works for the userservices-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#PLAT-M23-S04services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#PLAT-M23-S12

Controls

22 controls apply, from the corpus control catalogue.

TC-AVL-005 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-LOG-002 TC-LOG-003 TC-LOG-005 TC-PI-001 TC-PI-003 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

KeyChecked atScope
platform.notifications.manageapitenant
platform.notifications.manageconsoletenant

Business Rules

8 rules, 6 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
Workspace History, request lists and diagnostic chains require notification-management permission, included in Administrator; Personal inbox permission alone is insufficient.
origin: services-platform:docs/milestones/PLAT-M23-notifications-core-and-in-app.md#D2
no proof recorded yet
permissionapi, consoletest
services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js#refuses History and the chain to a caller with only platform.notifications.use
02must prove
Proposed
History lists newest-first notices with recipient, request and per-channel delivery summaries; Filters cover recipient, definition, category, channel, status and since; paging can cross monthly partitions; invalid categories and statuses are rejected.
no proof recorded yet
validationapi, servicetest
services-platform:modules/notifications/tests/integration/services/centre/notification-centre.integration.spec.js#lists every person’s notifications newest first with the person and the request
03must prove
Proposed
Request history includes requests with and without resulting notices, their notice counts and outcomes including isolation, invalidity and cancellation; Outcome, definition and since filters apply in newest-first order.
no proof recorded yet
policyapi, servicetest
services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js#lists a request that dropped a named person, one that was refused as invalid and one that was heard, and no other tenant’s
04must prove
Proposed
Diagnostic detail connects requests to notices and their explanations and deliveries, notices to explanations and deliveries, and deliveries to events, notices and requests; a problem-free request returns an empty problems list.
no proof recorded yet
policyapi, servicetest
services-platform:modules/notifications/tests/integration/services/centre/notification-centre.integration.spec.js#carries the why and the deliveries of each notification on the request, as the notification’s own chain does
05
Proposed
History supplies the latest contributing request's retained data, with declared links redacted, so the console can identify responsibility scope.
policyservicetest
services-platform:modules/notifications/tests/integration/services/centre/notification-centre.integration.spec.js#answers the data of the newest request a notification folded, one read for the page
06must prove
Proposed
History and diagnostic lookups remain workspace-local; unknown identifiers and another workspace's records are not found.
origin: services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#PLAT-M23-S04
no proof recorded yet
invariantservice, databasetest
services-platform:modules/notifications/tests/integration/services/centre/notification-centre.integration.spec.js#shows nothing of another tenant
07
Proposed
The History screen resolves recipient names, provides a recipient filter and request view, and opens a diagnostic chain from a row; it offers no settings editing in this release.
policyconsoletest
react-console:components/notifications/__tests__/notifications.test.tsx#lists the organization's notifications with status and reason, naming the person from the lookup
08must prove
Proposed
The intended delivery table explains unused channels with the same reasons and milestone names shown in the personal explanation sheet.
origin: services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#PLAT-M23-S12
no proof recorded yet
policyconsoledocumented
services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#9. Acceptance scenarios

Scenarios

IdGivenWhenThenProvenance
01Jane's assignment and ending have notices, and an outsider-only request produced none.An administrator inspects History and Requests.The administrator finds Jane's item states and the empty request outcome and can inspect their diagnostic links.test
react-console:acceptance/notifications/playwright/journeys/history/NT-ACC-0101.spec.ts#NT-ACC-0101

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software