Doc on Responsibilities

[john-d03]

/document Access & Governance/Responsibilities

[github-actions]

✅ Ezhuthachan completed successfully!

[github-actions]

Ezhuthachan

Documented Responsibilities across all three layers and opened a pull request.

In Care, a "Responsibility" is the user-facing name for an organization of type role — a flat, named group such as Doctors or Nurses, with Admin / Manager / Member designations and governance links between groups.

Documents written

Added to both version-3.0 and version-3.1 (identical content):

• Concept — concepts/access-governance/responsibility.mdx
• Reference — references/access-governance/responsibility.mdx
• Flow — flows/access-governance/create-a-responsibility.mdx
• Flow — flows/access-governance/assign-a-user-to-a-responsibility.mdx
• Flow — flows/access-governance/link-responsibilities-for-governance.mdx

<doc-types> was omitted, so the slug was read as a resource and all three layers were produced. The three flows are ordered the way a user meets them: create the group, put people in it, then connect it to other groups. A new Access & Governance flow category was added to both versioned sidebar files, since flows are a manual list.

Build is green for both the en and ml locales.

Bugs and inconsistencies

1. A hint string labels the wrong panel. In care_fe/public/locale/en.json, managing_organizations_hint reads "Responsibilities this one can govern." — word for word the same as managed_role_organizations_hint. It labels the Managing Organizations panel in src/pages/Organization/components/RoleOrganizationConnections.tsx, which lists the responsibilities that govern this one, so the meaning is inverted. The neighbouring managing_organizations_add_hint ("Choose a responsibility that should govern this one.") shows the intended sense. High confidence — this looks like a copy-paste error.

2. A toast says "Organization" on a Responsibility screen. src/pages/Admin/organizations/components/AdminOrganizationFormSheet.tsx shows t("organization_created_successfully") = "Organization created successfully" after a create, including on the Responsibilities page where every other string uses the word "Responsibility". Low severity, high confidence.

3. The create and edit buttons are shown to users who cannot use them. authorize_create, authorize_update, and authorize_destroy in care/emr/api/viewsets/organization.py reject govt and role organizations for anyone who is not a superuser. AdminOrganizationList.tsx renders AdminOrganizationFormSheet with no superuser check, and I found no is_superuser guard in either file. A non-superuser administrator would therefore see Create Responsibility, fill the form, and receive a permission error on submit. Medium-to-high confidence — I read both files and grepped them for a superuser check, but I did not trace every wrapper that renders the list page.

Open questions

None that block the documents. One judgement call worth flagging for review: because creating and renaming a responsibility is superuser-only, the create flow states that requirement plainly in its pre-requisites rather than naming a permission, since no system role carries it.

Generated by Ezhuthachan for #65 · opus50 · 396.7 AIC · ⌖ 14.2 AIC · ⊞ 14.4K · ◷
_{Comment /document to run again}