[
https://issues.apache.org/jira/browse/FINERACT-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Foo Developer updated FINERACT-2762:
------------------------------------
Description:
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**.
was:
# Allow Checker-Only Users to Approve Pending Maker-Checker Actions via Direct
Entity Endpoint
## 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**.
> 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
> 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)
