Doc on Tags

[john-d03]

/document admin/tag

[github-actions]

✅ Ezhuthachan completed successfully!

[github-actions]

Ezhuthachan

Opened a pull request with the tag documentation.

Note on the slug: there is no admin docs domain. Tags are already documented under platform, so I worked there:

• Rewrote concepts/platform/tagging.mdx to the concept template. The previous page predated the template and put backend permission slugs into a user-facing page.
• Added two flows: flows/platform/create-a-tag.mdx and flows/platform/apply-a-tag-to-a-record.mdx, plus a new platform flow category, registered in the sidebar of both versions.
• Left references/platform/tag-config.mdx unchanged. It is still faithful to care/emr/models/tag_config.py and care/emr/resources/tag/config_spec.py.

Mirrored to version-3.0 and version-3.1. npm run build is green for both locales.

Bugs and inconsistencies

1. system_generated is served but does not exist on the model. TagConfigReadSpec in care/emr/resources/tag/config_spec.py declares system_generated: bool, but TagConfig in care/emr/models/tag_config.py has no such field, and neither does EMRBaseModel. The generic serialize only copies model fields. care_fe reads it in src/pages/Admin/TagConfig/TagConfigView.tsx and shows a "System generated" Yes/No row. Confidence: high that the field is missing from the model; medium on the runtime effect, since I did not run the serializer.

2. Tag category and resource values have no dedicated locale keys. care_fe renders them with a bare t(config.category) and t(config.resource) (TagConfigForm.tsx, TagConfigTable.tsx), not the PREFIX__value convention. The values happen to resolve because generic keys such as admin, clinical, lab, contact and patient exist for other purposes. That makes the tag labels fragile — for example the tag category admin shares the key with the unrelated "Admin" label. Confidence: high.

3. The frontend offers tag assignment for resource types the backend has no manager wiring shown for. ENTITY_CONFIG in src/components/Tags/TagAssignmentSheet.tsx covers patient, encounter, appointment, prescription, service request, delivery order, request order, account and charge item definition, but charge_item and activity_definition are commented out while both remain selectable TagResource values in the tag form. An administrator can therefore create a tag that no screen can apply. Confidence: high.

4. The archive action rewrites the whole child record. In TagConfigView.tsx, archiveMutation re-fetches the child and PUTs every field back with status: archived, including parent and resource. TagConfigUpdateSpec accepts neither parent nor resource, so those keys are silently dropped. It works, but it is a fragile read-modify-write. Confidence: medium.

5. Version drift in the docs, unrelated to this change. versioned_docs/version-3.0 and version-3.1 are no longer identical: 3.1 has a flows/clinical/patient/ set that 3.0 does not, and intro.mdx, concepts/clinical/patient.mdx and references/clinical/patient.mdx differ. The conventions say the two versions stay byte-identical. I did not touch those files. Confidence: high.

Open questions

1. Is flows/platform/ the right home for the tag flows, or should tagging a patient stay in flows/clinical/patient/manage-patient-tags.mdx (3.1 only) and the new flows cover administration only? The two now overlap slightly.
2. Should the tag docs be renamed from tagging / tag-config to a single tag slug for concept and reference? I kept the existing slugs to avoid breaking inbound links.

Generated by Ezhuthachan for #69 · opus50 · 253.2 AIC · ⌖ 14.6 AIC · ⊞ 14.4K · ◷
_{Comment /document to run again}

[github-actions]

Comment Memory

# Tag docs (issue #69)

- Slug `admin/tag` has no `admin` domain. Tags live under **platform**:
  `concepts/platform/tagging.mdx`, `references/platform/tag-config.mdx`.
- Concept rewritten to `concept-template.md`; reference left as-is (still accurate).
- Added `flows/platform/create-a-tag.mdx` and `flows/platform/apply-a-tag-to-a-record.mdx`,
  new `flows/platform/_category_.json`, registered in both versioned sidebars.
- Branch: `docs/tag-docs`. Build green for `en` and `ml`.

## Facts established (do not re-derive)
- Permissions (`care/security/permissions/tag_config.py`):
  - Can Create Tag Config on Facility — Facility Admin, Admin
  - Can Apply Tag Config to Resources — Facility Admin, Admin, Staff, Doctor, Nurse, Pharmacist
  - Can Read Tag Config — Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer, Pharmacist
  - Instance-level (no facility) tag create/update requires superuser.
- Statuses: Active, Archived. Categories: Diet, Drug, Lab, Admin, Contact, Clinical,
  Behavioral, Research, Advance Directive, Safety.
- UI routes: `/admin/tag_config` and facility Settings → Tag config.
- No keyboard shortcut exists for any tag action.

## Known drift
- version-3.0 and version-3.1 are NOT identical (3.1 has `flows/clinical/patient/*`;
  intro/patient concept+reference differ). Pre-existing, not caused by this run.

## Open questions asked
1. Do the new platform flows overlap `flows/clinical/patient/manage-patient-tags.mdx` (3.1 only)?
2. Should slugs be normalised to `tag` for both concept and reference?

Note

This comment is managed by comment memory.

It stores persistent context for this thread in the code block at the top of this comment.
Edit only the text inside the backtick fences; workflow metadata and the footer are regenerated automatically.

Learn more about comment memory

Generated by Ezhuthachan for #69 · opus50 · 253.2 AIC · ⌖ 14.6 AIC · ⊞ 14.4K · ◷
_{Comment /document to run again}