FINERACT-2769: Tax group – Start Date field validation/behavior issues on edit mode if the group is unlinked - #6290
Open
rymghosn wants to merge 1 commit into
Conversation
…e it takes effect Tax group updates could never carry a start date change through: the JSON-level id-vs-taxComponentId mismatch made the validator require a new taxComponentId even when only an existing mapping's id was submitted, and the write path always discarded any submitted start date. This also fixes a latent bug where adding a new component to an existing group left its tax_group_id foreign key unset. An existing component's start date can now be changed as long as it has not taken effect yet (its current start date is still in the future), and the group/component read side exposes groupEditable/componentEditable so clients can tell which fields are still open for editing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tax group updates could never actually carry a start date change through to
an existing component mapping, and a JSON-key bug made updates fail
unnecessarily:
validateForTaxGroupUpdate extracted a submitted mapping's id using the
taxComponentId JSON key instead of id. Since taxComponentId is
immutable and normally omitted on update, this misclassified a
legitimate "update existing mapping" request as "add a new component"
and wrongly demanded a taxComponentId.
TaxAssembler/TaxGroupMappings/TaxGroup always discarded any
submitted startDate on update — only endDate was ever applied, even
though startDate was already an accepted request parameter.
Adding a brand-new tax component to an existing group via update never
set the new mapping's taxGroup relationship, which would violate the
tax_group_id NOT NULL constraint on insert.
This PR:
Fixes the JSON-key bug.
Lets an existing component's start date be edited, but only while it
hasn't taken effect yet (i.e. its current start date is still in the
future) — once a start date is on or before today it's locked, and only
the end date remains editable.
Fixes the missing taxGroup FK assignment for newly-added components.
Exposes groupEditable (on GET /taxes/group/{id}?template=true) and
per-component componentEditable so clients can tell which fields are
still open for editing: a group linked to charge products is only
editable if at least one of its components hasn't taken effect yet.
PR:(https://issues.apache.org/jira/browse/FINERACT-2769)