Skip to content

CAP-SUB-SUB-020Give staff and participants the authority their work requires

Markdown

CAP-SUB-SUB-020

Give staff and participants the authority their work requires

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

KindCapabilityProduct areaSubmissionsModuleSubmissions, Intake, Review and OutcomesRevision1

Read atservices-submissions 64236c19react-console baf6dae3

The Formal Contract

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

Outcomes
Built-in policies distinguish operational authorityReviewers reach assigned work through participationWorkspace and process boundaries constrain access
Surfaces
consoleapi
Intent sources
services-submissions:docs/milestones/plans/SUBM-M1-plan.md#D8services-submissions:docs/milestones/plans/SUBM-M1-plan.md#D9services-submissions:docs/milestones/plans/SUBM-M1-plan.md#S08services-submissions:docs/milestones/plans/SUBM-M1-plan.md#S13services-submissions:docs/milestones/SUBM-M1-staff-review-in-the-console.md#E1services-submissions:docs/milestones/SUBM-M1-staff-review-in-the-console.md#E2

Controls

25 controls apply, from the corpus control catalogue.

TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-CRY-001 TC-CRY-004 TC-IAM-001 TC-IAM-002 TC-IAM-003 TC-IAM-004 TC-IAM-005 TC-LOG-001 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-SEC-001 TC-SEC-002 TC-SEC-003 TC-SEC-004 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004

Permissions

KeyChecked atScope
submissions.application.accessapitenant
submissions.definitions.readapitenant
submissions.submissions.readapitenant
submissions.submission-layouts.readapitenant
submissions.submission-layouts.createapitenant
submissions.submission-layouts.updateapitenant
submissions.submission-layouts.deleteapitenant
submissions.submissions.deleteapitenant
submissions.assignments.readapitenant

Business Rules

13 rules, 9 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
The built-in administrator, coordinator, reviewer and reader policies separate comprehensive control, operational writes, assignment-only work and read access, with overrides and confidential access reserved to the administrator tier.
no proof recorded yet
permissionapiobserved
02must prove
Proposed
Reviewers lack general application-reading permission and need additional reader authority for wider oversight.
no proof recorded yet
permissionapitest
03must prove
Proposed
Protected requests enforce application access, licensing and the applicable record authority and reject absent security context.
no proof recorded yet
permissionapitest
services-submissions:modules/definitions/tests/e2e/subject-kinds.e2e.spec.js#answers 403 app_not_permitted to a caller denied submissions.application.access
04must prove
Proposed
Users without Submissions authority do not receive its navigation entry and cannot use protected operations.
no proof recorded yet
permissionapi, consoleobserved
05must prove
Proposed
Service access filters honor process-scoped grants and hide other processes, while deployed gateway scope enforcement remains a separately reported uncertainty.
no proof recorded yet
permissionapi, serviceobserved
06must prove
Proposed
Applicants, representatives, contributors and reviewers reach records through their participation, request access or assignment; outsiders receive an absent-record response.
no proof recorded yet
permissionservicetest
services-submissions:tests/unit/route-authorization.spec.ts#serve the reviewer’s own work as participation under submissions.application.access alone, and staff work under its own key
07must prove
Proposed
Service reads and database policies isolate workspace records and reject attempts to reach another workspace.
no proof recorded yet
permissionapi, databaseobserved
08must prove
Proposed
External requirement completion is reserved to a staff-only permission omitted from built-in customer policies and unavailable for customer-role grants.
origin: DEF-SUB-0636 (SUBM-M1 run subm1api)
no proof recorded yet
permissionapitest
services-submissions:tests/unit/built-in-policies-staff-only.spec.ts#refuses a planted policy that carries submissions.stages.complete
09
Proposed
Staff reviewing uses workspace user identities, while staff application entry requires CRM applicant-lookup rights.
policyservice, consoledocumented
10
Proposed
Console abilities translate engine permissions into administrator controls, coordinator creation and editing without configuration deletion and reader-only viewing.
permissionconsoletest
react-console:lib/submissions/config/abilities.test.ts#${noun}: the coordinator can create and edit but is offered no Delete
11
Proposed
The inventory describes sixty-second warm-route caching plus another thirty seconds of signed-context validity, without independently establishing the current deployed revocation window.
permissionapidocumented
12must prove
Proposed
Assignment-read, review-export, application-delete and four layout permissions remain published despite having no route enforcement.
origin: services-submissions:docs/milestones/README.md#Questions carried to later plans (each to be written out in full for Andrew, R2-DEV-001 section 8.1)
no proof recorded yet
permissionapiobserved
13
Proposed
Submissions records do not support custom fields, while owning applications retain their own field-bearing domain records.
origin: services-submissions:docs/milestones/plans/SUBM-M1-plan.md#7a. Entity capabilities (R2-ARCH-001)
policyservicedocumented

Scenarios

IdGivenWhenThenProvenance
01The caller has reader authority over the award and an entry.They inspect configuration and attempt changes.The screens permit inspection while changes are denied.test

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.