FINERACT-2753: Improve Maker-Checker Action Endpoint Handling and Permission Responses - #6255
Open
rymghosn wants to merge 1 commit into
Conversation
…mission responses Block a maker-only user from submitting a duplicate maker-checker action while a submission for the same action/entity/resource is still awaiting checker approval, and give a checker-only user (has only the `_CHECKER` permission) a clear refusal message when attempting to initiate an action directly instead of approving a pending one. Non maker-checker flows and users holding both the base and checker permission are unaffected.
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.
Today, maker-checker enabled actions have two rough edges:
creating multiple redundant pending entries for the same underlying change.
action directly currently falls through to the generic NoAuthorizationException ("User has no authority to: ...") — which reads like a
permissions-configuration bug rather than telling the user they should be approving a pending entry instead of initiating one.
This PR adds two targeted, backwards-compatible checks in PortfolioCommandSourceWritePlatformServiceImpl#logCommandSource, only for tasks that
have maker-checker enabled:
already exists with status AWAITING_APPROVAL for the same action name, entity name and resource id, the new submission is rejected with a new
MakerCheckerDuplicatePendingSubmissionException (HTTP 409) instead of being queued as another pending entry.
the request is rejected with a new MakerCheckerCheckerOnlyInitiationException (HTTP 403) telling them to use the approval flow instead.
Users who hold both the base and _CHECKER permission for a task, and any non maker-checker-enabled action, are unaffected. This PR intentionally
does not change approveEntry or introduce any new self-approval semantics — it only tightens the initiation path.
PR:(https://issues.apache.org/jira/browse/FINERACT-2753)