Released docs. You are viewing the documentation published with v0.46.0. Development docs are available at Latest.
A ReviewTask waits in a queue until someone eligible picks it up. Which people that is lives in
the directory, not in the policy. You continue in
tutorial-work/casework, with the development session you restarted in
Author a Casework policy still running.
What the directory holds
Section titled “What the directory holds”The policy declares the queues and, for each team it names, the profiles its members and supervisors must hold. The directory is runtime state: each team’s staff and supervisors, as an issuer and a subject, and the queues the team serves, under one directory revision. A person reaches a queue’s tasks only as a member of a team that serves it, while holding a profile that may decide the stage. Changing who is in a team needs no new package.
Only an access profile with the administrator role may read or change the directory.
Seed it for the development session
Section titled “Seed it for the development session”The session seeded its directory from dev-clients.yaml, as its administrator client, on its
first start:
directory: - team: decisions-team queue: decisions staff: [staff] supervisors: [supervisor]Each entry names one team and the one declared queue it serves, with at most eight teams. Its
staff must be clients bound to a staff profile and its supervisors clients bound to a supervisor
profile. caseworkctl check refuses a file that leaves a declared queue with no team
(casework.dev-clients.unserved-queue) or that has no administrator client to seed it.
A deployment names people by issuer and subject. Show the subject the session’s staff client signs in as:
caseworkctl dev identity staff{"clientId": "staff", "subject": "17e79057-d468-701e-845e-a94875c37bd4"}Read the directory
Section titled “Read the directory”Read it as the administrator to confirm every queue has a team:
rstack casework api /v1/directory --client administrator | jq .{"revision": 1}{"id": "decisions-team", "servedQueues": ["decisions"]}Bootstrap a deployment’s directory
Section titled “Bootstrap a deployment’s directory”A deployment has no dev-clients.yaml. Its first administrator creates the first team with one
call, naming directory revision 0 and an idempotency key so a retry cannot create it twice:
{ "teamId": "decisions-team", "queueId": "decisions", "staff": [ {"issuer": "https://identity.example.test/realms/registry", "subject": "<staff subject>"} ], "supervisors": [ {"issuer": "https://identity.example.test/realms/registry", "subject": "<supervisor subject>"} ]}rstack casework api /v1/directory/bootstrap \ --url "$casework_url" \ --header @administrator.header \ --header 'Registry-Casework-Profile: administrator' \ --if-match '"0"' \ --idempotency-key directory-bootstrap-1 \ --input directory-bootstrap.jsonCasework refuses a queue the active package does not declare. Later changes go through
PUT /v1/directory/teams/{teamId} with the team’s staff, supervisors and servedQueues, each
under the directory revision you last read, so two administrators cannot overwrite each other.
The Casework API reference lists every directory
operation.
Cookies on Registry Stack
We use optional cookies to understand how you use the main Registry Stack website and this documentation. If you contact us, we may link this activity to your enquiry. You can change your choice at any time. Read the privacy policy.
Your browser asks sites not to track you, so optional tracking stays off.
We could not use or save that choice. Optional tracking remains off.