[
https://issues.apache.org/jira/browse/FINERACT-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105596#comment-18105596
]
Foo Developer commented on FINERACT-2762:
-----------------------------------------
no — the maker/checker separation is still fully enforced. This path resolves
to the same
approveEntry()/validateMakerCheckerTransaction() logic as the existing
checker-inbox approve endpoint, which still requires the checker permission and
still blocks a user from approving their own submission. What changes is just
that a checker-only user hitting the normal action endpoint gets routed to
approve the pending entry instead of a flat 403 — not a new way to bypass the
two-person rule.
> Client Approval/Activation Fails for Branch Manager Despite Having Required
> Permissions
> ---------------------------------------------------------------------------------------
>
> Key: FINERACT-2762
> URL: https://issues.apache.org/jira/browse/FINERACT-2762
> Project: Apache Fineract
> Issue Type: Bug
> Components: Organization
> Reporter: Foo Developer
> Assignee: Foo Developer
> Priority: Major
> Labels: beginner, beginner-friendly
>
> Description
> For a **maker-checker-enabled action**, a user who has only the corresponding
> **`_CHECKER` permission** (for example, `ACTIVATE_CLIENT_CHECKER`) and does
> not have the base permission (`ACTIVATE_CLIENT`) is currently rejected when
> calling the entity's normal action endpoint.
> This occurs even when there is already a **pending maker submission** for the
> exact action, entity, and resource that is awaiting the user's approval.
> Currently, a checker-only user can approve the pending action only through
> the dedicated **Maker-Checker / Checker Inbox approval endpoint**:
> `POST .../commands/{id}?command=approve`
> There is no fallback for a checker-only user who performs the action directly
> from the entity's screen using the normal action endpoint, such as:
> `POST /clients/{clientId}?command=activate`
> # Steps to Reproduce
> 1. As a **Maker** with `CREATE_CLIENT` / base permission and without the
> checker permission:
> * Create a client.
> * Submit the client for approval.
> 2. As a **Checker** with only `ACTIVATE_CLIENT_CHECKER` and without
> `ACTIVATE_CLIENT`:
> * Open the client.
> * Call the direct activation endpoint:
> `POST /clients/{clientId}?command=activate`
> 3. Observe that the request is rejected and rolled back, even though a
> matching pending maker-checker entry exists for the exact action, entity, and
> resource.
> # Actual Result
> The checker-only user receives a generic **"not authorized"** / rollback
> response.
> The request is rejected because the user does not have the base
> `ACTIVATE_CLIENT` permission, despite having the corresponding
> `ACTIVATE_CLIENT_CHECKER` permission and an existing pending submission
> awaiting approval.
> # Expected Behavior
> When a checker-only user calls the **direct action endpoint**, and a pending
> maker submission exists for the exact:
> * Action
> * Entity
> * Resource
> the platform should recognize the request as an **approval of the pending
> maker-checker entry** and process it equivalently to the dedicated Checker
> Inbox approval endpoint:
> `POST .../commands/{id}?command=approve`
> The checker should therefore be able to approve the pending action directly
> from the entity's screen without requiring the base permission.
> # Authorization Rule
> * **Checker-only + matching pending entry exists** → Treat the request as
> approval and allow it.
> * **Checker-only + no matching pending entry exists** → Keep the existing
> **"not authorized"** behavior.
> * **User has base permission** → Keep the existing normal action behavior
> unchanged.
> This should provide a consistent experience between approving an action from
> the **Checker Inbox** and approving it directly from the **entity screen**.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
