FINERACT-2768: Tax Group cannot be edited once a linked Tax Component has ended - #6289
Conversation
… ended validateForTaxGroupUpdate() required every taxComponents[].endDate submitted in a tax group update to be strictly in the future, even for an existing component that had already ended and was simply being resubmitted unchanged as part of editing the rest of the group (e.g. renaming it or adding a new component). This made a group permanently un-editable once any of its components ended. The future-end-date check now only applies to newly added components (no mapping id yet); existing mappings continue to be validated by validateTaxGroupEndDateAndTaxComponent(), which already correctly allows an unchanged end date to pass through and only rejects an actual attempt to change it. This also fixes the extraction of taxMappingId, which read the taxComponentId JSON key instead of id, so the new-vs-existing branch below it could never distinguish the two cases.
|
The only failing check, `build-documentation / build`, is unrelated to this change — all other ~100 jobs (build-core, checkstyle/spotless/spotbugs, cucumber, e2e across 20 shards, integration tests on MariaDB/MySQL/PostgreSQL across 15 shards each, liquibase/API backward-compatibility checks) passed. Looking at the job log, it stalled at the `sudo apt-get update` step: repeated failed attempts to reach `azure.archive.ubuntu.com` (`Ign:` retries), then hung after fetching `archive.ubuntu.com/ubuntu noble-security InRelease` with no further output for over an hour, until it was killed for exceeding the 1h30m job timeout (`The operation was canceled` / `exceeded the maximum execution time`). This looks like a transient runner/apt-mirror connectivity issue rather than anything introduced by this PR. Could someone re-run the `build-documentation` job?@adamsaghy |
1 participant
What's the issue?
TaxValidator.validateForTaxGroupUpdate() required every taxComponents[].endDate submitted with a tax group update to be strictly in the future —
including for an existing, already-linked component that had already ended and was simply being resubmitted unchanged as part of editing
something else about the group (renaming it, adding a new component, etc.). Since clients typically resubmit the full taxComponents array on
update to avoid dropping existing mappings, this made a Tax Group permanently un-editable once any one of its linked components passed its end
date, even when that end date wasn't being changed.
What's the fix?
The future-end-date check now only applies to newly added components (no existing mapping id yet). Existing mappings continue to be validated by
validateTaxGroupEndDateAndTaxComponent(), which already correctly allows an unchanged end date to pass through and only rejects an actual attempt
to modify it.
Incidental fix
While tracing the new-vs-existing distinction, found taxMappingId was being extracted using the taxComponentId JSON key instead of id — a
pre-existing bug (predates this change) that made the new/existing branch a no-op. Corrected the key so the distinction — and this fix — actually
works.
PR:(https://issues.apache.org/jira/browse/FINERACT-2768)