[ 
https://issues.apache.org/jira/browse/FINERACT-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105601#comment-18105601
 ] 

Bharath Gowda commented on FINERACT-2762:
-----------------------------------------

[~adamsaghy] As discussed, the fix looks good.

> 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)

Reply via email to