PR Custody

PRPR Custody

feat: Consolidate Workday actions

@shreysingla11checks n/achecks…workday-more-composite-actions → master233 files · +4315 −20022updated 1w ago

GitHub

▸Description

Summary

Consolidates the Workday action reductions into one PR while preserving endpoint coverage and request schema detail.

#24552 has been merged, so #24549 is reverted from master and all Workday consolidation changes now live in this PR.

This PR includes:

The #24549 consolidation: Business Process event-step actions and Staffing contact-information-change actions
The later consolidation batches: value lists, subresources, contact/person collections, payroll values, prospect subresources, performance values, expense values, absence/connect values, and related typed composites
Registered Workday action count on this branch: 334
Narrow Literal[...] selector fields for composites instead of free-form path strings
Original request fields, constraints, and selector-specific behavior where applicable

Example: Subresource Consolidation

Business Process event subresources used to be four separate read actions:

ListBusinessProcessEventComments
GetCompletedStepsBusinessProcess
GetInProcessStepsBusinessProcessEvent
ListBusinessProcessEventRemainingSteps

They are now one composite action: GetBusinessProcessEventSubresources.

The request schema stays explicit by adding a required selector:

{
  "ID": "c239497eddec1001997f14ccbfe30000",
  "subresource_type": "completed_steps",
  "limit": 20,
  "offset": 0
}

subresource_type is typed as Literal["comments", "completed_steps", "in_progress_steps", "remaining_steps"], so callers still get a closed set of valid choices instead of a free-form path string. The composite maps those values to the same old endpoints:

comments -> GET /businessProcess/v1/events/{ID}/comments
completed_steps -> GET /businessProcess/v1/events/{ID}/completedSteps
in_progress_steps -> GET /businessProcess/v1/events/{ID}/inProgressSteps
remaining_steps -> GET /businessProcess/v1/events/{ID}/remainingSteps

Selector-specific behavior is preserved too: completed_steps and in_progress_steps still convert upstream 404 responses into {"data": [], "total": 0}, matching the deleted actions.

Validation

Local checks on the rebuilt branch:

Full Workday registry import and request/response schema generation -> 334 actions, 0 schema errors
ruff check apps/workday/tool.py apps/workday/actions -> all checks passed
python -m compileall -q apps/workday/tool.py apps/workday/actions -> passed
pytest tests/test_apps/test_workday/test_common.py -> 22 passed
git diff --check origin/master..HEAD -> clean
Confirmed mercury_actions_analysis/actions.db clean

Live replay previously run using connection ca_qWLknNUm0KSI:

Replayed saved scenarios for every deleted action in the consolidated groups against the corresponding composite action
Fully matched saved scenarios for staffing values, performance values, prospect subresources, expense values, business-process event subresources, absence status values, and audience values
For Job Change, Worker Skill, and Organization Assignment Change groups, stale saved Workday IDs now return upstream 404s on the original paths too; route construction is identical, and fresh live coverage was run where needed
Created one fresh Organization Assignment Change in the test Workday tenant to verify all Organization Assignment Change subresource selectors and by-id selectors; local DB was not modified

Notes:

Response schemas are intentionally allowed to be weaker where useful, per review guidance, but request schemas remain detailed and typed with selector literals plus the original ID/query constraints.
Further movement toward ~250 actions would require less conservative composites that mix less-related operations or weaken request shapes for mutating/body-heavy actions, so this PR keeps only the reductions that fit the stated invariants.

loading diff…