QA-187 | test: add Planned encounter status transition spec

[nihal467]

Proposed Changes

Adds a Playwright spec covering the encounter-status transition rules introduced in #16476.

For a Planned encounter with a future start date:

Target status	Expected outcome
In Progress	Allowed (submit succeeds)
On Hold	Allowed
Cancelled	Allowed
Entered in error	Allowed
Completed	Blocked — `period: Value error, Start Date cannot be greater than End Date`
Discontinued	Blocked — same period error

Each test creates a fresh Planned + future-date encounter in `beforeEach`, performs the transition through the Update Encounter form, and cleans up to a terminal state (Cancelled / Entered in error) so re-runs don't hit the 5-live-encounter cap on the fixture patient.

Notes

• Targets `ENG-601-planned` so the spec lands with the feature in [ENG-601] feat: allow planned encounters (w/ future start date) to transition to cancelled/discontinued/entered in error #16476.
• Uses an anchored-label locator for the bare `` + `` combobox on the Update form (no programmatic accessible name on that trigger).

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: cd30bade-bb9c-4a1f-a6d2-75836d6dc19b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

⚠️ Merge Checklist Incomplete

Thank you for your contribution! To help us review your PR efficiently, please complete the merge checklist in your PR description.

Your PR will be reviewed once you have marked the appropriate checklist items.

To update the checklist:

• Change - [ ] to - [x] for completed items
• Only check items that are relevant to your PR
• Leave items unchecked if they don't apply

The checklist helps ensure code quality, testing coverage, and documentation are properly addressed.

[github-actions]

🚀 Preview Deployment Ready!

🔗 Preview URL: https://pr-16481.care-preview-a7w.pages.dev

📱 Mobile Access:
Scan the QR code below to open the preview on your mobile device.

---

This preview will be automatically updated when you push new commits to this PR.

[greptile-apps]

Greptile Summary

This PR extracts shared encounter-form helpers into a new encounterFormHelpers.ts module and adds a six-case Playwright spec covering every status transition from a Planned encounter with a future start date.

• encounterFormHelpers.ts cleanly separates openCreateEncounterDialog, calendar navigation, and selectStatusInCreateDialog utilities, enabling both specs to share a single implementation.
• encounterPlannedStatusTransition.spec.ts exercises all allowed and blocked transitions, with inline cleanup steps that move each encounter to a terminal state.
• encounterFutureDateRestriction.spec.ts is updated to import from the new helpers but still uses raw inline combobox/option locators instead of the new selectStatusInCreateDialog helper.

Confidence Score: 5/5

Test-only change with no production code modified; safe to merge.

All three files are test/helper additions or refactors with no changes to production source. The helper extraction is correct, the new spec covers the intended transition matrix, and the one gap found is non-blocking.

encounterFutureDateRestriction.spec.ts — four inline status-selection blocks should be migrated to the new selectStatusInCreateDialog helper introduced in the same PR.

Important Files Changed

Filename	Overview
tests/facility/patient/encounter/encounterFormHelpers.ts	New shared helper module extracted from encounterFutureDateRestriction.spec.ts — cleanly separates open-dialog, class selection, calendar navigation, and status-selection utilities.
tests/facility/patient/encounter/encounterFutureDateRestriction.spec.ts	Refactored to import from encounterFormHelpers.ts, but four inline status-selection blocks still use raw locators instead of the new selectStatusInCreateDialog helper.
tests/facility/patient/encounter/encounterPlannedStatusTransition.spec.ts	New spec covering all six status-transition paths for Planned encounters; clear and well-commented.

_{Reviews (2): Last reviewed commit: "refactor(tests): extract shared encounte..." | Re-trigger Greptile}

[nihal467]

Thanks for the review @greptile-apps. Responses:

1. Cleanup contradicting CLAUDE.md — The DB snapshot is restored once per run by globalSetup, not between tests within a run. This describe block has 6 tests sharing the same fixture patient against a 5-live-encounter cap, so without cleanup the suite isn't re-entrant in a single run. The cleanup here is intra-run hygiene, not a replacement for snapshot restore.

2. xpath=.. parent traversal — Agreed it's not ideal. Root cause is in the app: the Update Encounter form uses a bare <Label> + <SelectTrigger> so the combobox has no programmatic accessible name. Proper fix is upstream (use <FormField> + <FormLabel>); leaving the locator anchored on label[data-slot="label"] + text for now, with an inline comment explaining why.

3. Duplication with encounterFutureDateRestriction.spec.ts — Valid. Pushed 38d313f extracting openCreateEncounterDialog, selectRandomEncounterClass, selectStatusInCreateDialog, openCalendarAndGetNextMonthButton, getFutureDateButtonFromCalendar, getEncounterCreateDialog into tests/facility/patient/encounter/encounterFormHelpers.ts and refactored both specs to use it.

[greptile-apps]

All three points are well-addressed:

1. Cleanup rationale — Makes sense. The beforeEach creates a live encounter each time, so without cleanup the 6th test would hit the cap mid-run. The inline comments in the cleanup steps make this self-documenting. No issue here.

2. xpath=.. locator — The inline comment at encounterStatusCombobox clearly explains the root cause (bare <Label> + <SelectTrigger> without FormLabel/htmlFor). That's the right pragmatic approach — document the workaround and fix it upstream. Accepted.

3. Deduplication — encounterFormHelpers.ts is clean. The getEncounterCreateDialog as getEncounterDialog alias in the existing spec is a fine local rename. No issues.

All concerns resolved. LGTM 👍

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.