Skip to content

Allow renaming custom eligibility checks - #518

Merged
prestoncabe merged 2 commits into
mainfrom
512-ability-to-rename-custom-eligibility-checks
Sep 27, 2026
Merged

prestoncabe merged 2 commits into
mainfrom
512-ability-to-rename-custom-eligibility-checks

Conversation

@prestoncabe

Copy link
Copy Markdown
Collaborator

Summary

  • Add a Rename action for working custom eligibility checks.
  • Use KIE Tools to rename the DMN decision and its FEEL references, including decision table expressions, while preserving decision IDs, string literals, and local variables.
  • Validate the refactored model before saving, reject stale submissions, and restore the previous DMN if the metadata update fails.
  • Keep existing published versions unchanged and preserve the check's version lineage across renames.
  • Give new checks generated IDs and reserve names transactionally so former names can be reused and concurrent requests cannot claim the same name.
  • Make example imports preserve existing renamed checks and published versions.

Verification

  • Focused backend tests: eligibility check resource, DMN rename validation, check IDs, and example imports.
  • Frontend: 12 focused tests passed; production build passed.
  • The full TypeScript check still reports existing unrelated errors; no diagnostics were reported in the files changed for the rename flow.

Closes #512

@prestoncabe prestoncabe linked an issue Sep 27, 2026 that may be closed by this pull request
@prestoncabe
prestoncabe force-pushed the 512-ability-to-rename-custom-eligibility-checks branch from 5991c49 to 8b84912 Compare September 27, 2026 16:21
prestoncabe and others added 2 commits September 27, 2026 13:32
A check's id was built from its name and kept after a rename, so the old
name stayed reserved: creating a check with it, or renaming another check
to it, was refused. New checks now get a generated id, and existing ids are
treated as opaque. Published ids are still derived from the working id, so
a check's versions stay linked across renames.

Name uniqueness is enforced with a reservation document per owner, module
and name, taken in a Firestore transaction so concurrent creates or renames
cannot both claim a name. A reservation whose check no longer holds the name
can be reclaimed after five minutes, so a failed request cannot block a name
for good.

The example import records which example check each imported check came
from and matches on that, instead of an id built from the name. It now only
adds what is missing, so re-importing no longer undoes a rename or rewrites
an existing published version, and it refuses to duplicate a name used by
another check.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@prestoncabe
prestoncabe force-pushed the 512-ability-to-rename-custom-eligibility-checks branch from 8b84912 to 2c30eaf Compare September 27, 2026 17:32
@prestoncabe
prestoncabe merged commit 724fb21 into main Sep 27, 2026
@prestoncabe
prestoncabe deleted the 512-ability-to-rename-custom-eligibility-checks branch September 27, 2026 17:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Ability to rename custom eligibility checks

1 participant