[FIX] Add Limit Parameter to User Role List for Org Function

[apoorvdixit88]

Feature Description

Description: The function generic_user_roles_list_for_org_and_extra currently fetches all roles for a give organisation and additional parameters. To improve performance and allow better control over data retrieval, we need to add a limit parameter to restrict the number of results returned.

pub async fn generic_user_roles_list_for_org_and_extra(
        conn: &PgPooledConn,
        user_id: Option<String>,
        org_id: id_type::OrganizationId,
        merchant_id: Option<id_type::MerchantId>,
        profile_id: Option<id_type::ProfileId>,
        version: Option<UserRoleVersion>,
    ) -> StorageResult<Vec<Self>> 

Task:

• Modify the existing function generic_user_roles_list_for_org_and_extra to include an optional limit parameter (Option).
• Pass this limit parameter down to the database query to restrict the number of user roles returned.
• Ensure the limit parameter is optional, and when it's not provided, the function should return all results as it currently does.

Possible Implementation

• Add an additional parameter limit: Option<type> to the function signature of generic_user_roles_list_for_org_and_extra
• Modify the query logic to apply the limit if it is provided.
• Ensure the modified function still works with existing code that doesn't use the limit parameter. ( For older implementations, where this function is getting called, pass limit as None so that it doesn't change expected behaviour)

Additional Context: This change is analogous to the generic_user_roles_list_for_user function, which already includes a limit parameter. You can refer to that function’s implementation for guidance.

How to Test

For testing, we can check where this generic_user_roles_list_for_user is used, currently this function is invoked from db function list_user_roles_by_user_id and this function is getting called from many core function, like list_merchants_for_user_in_org , list_orgs_for_user.

We can hit user/list/merchants api to invoke this list_merchants_for_user_in_org core function:

Signup:

curl --location 'http://localhost:8080/user/signup' \
--header 'Content-Type: application/json' \
--header 'api-key: test_admin' \
--data-raw '{
    "email": "email1@gmail.com",
    "password": "Pass@123"
}'

Response:

{
    "token": "JWT",
    "token_type": "totp"
}

We will get intermediate token for setting up 2FA, it is skippable: Skip 2FA, we will be getting a login token:

curl --location 'http://localhost:8080/user/2fa/terminate?skip_two_factor_auth=true' \
--header 'Authorization: Bearer Intermediate_Token'

{
    "token": "JWT",
    "token_type": "user_info"
}

It depicts successful signup, default one merchant_id has been created. (Baisically one org, with one merchant and one profile) Now we can call list/merchant:

curl --location 'http://localhost:8080/user/list/merchant' \
--header 'Authorization: Bearer LOGIN_JWT'

Response:

[
    {
        "merchant_id": "merchant_test"
        "merchant_name": null
    }
]

We can create more merchant accounts:

curl --location 'http://localhost:8080/user/create_merchant' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer LoginJWT' \
--data '{
    "company_name": "hyperswitch"
}'

And if we try got get list it now, it will show more merchant_ids in list. Limit parameter in the function that controls how much data we need for our use case, say, sometimes we only want to get first one from list, we can just pass limit one instead of fetching whole list.

Acceptance Criteria:

• The function should accept an optional limit parameter.
• When a limit is provided, the number of results returned by the query should not exceed the limit.
• Tests the behaviour with and without the limit parameter.

Have you spent some time checking if this feature request has been raised before?

• [X] I checked and didn't find a similar issue

Submission Process:

• Ask the maintainers for assignment of the issue, you can request for assignment by commenting on the issue itself.
• Once assigned, submit a pull request (PR).
• Maintainers will review and provide feedback, if any.
• Maintainers can unassign issues due to inactivity, read more here.

Refer here for Terms and conditions for the contest.

[vil02]

Where this should be tested? Could you please provide some pointer to the tests of generic_user_roles_list_for_user for reference?

I would like to work on this issue.

[apoorvdixit88]

Hey @vil02 , Assigning this issue to you.

Added Testing flow for generic_user_roles_list_for_user in description, similarly we can check implementation of `generic_user_roles_list_for_org_and_extra, from where it is being invoked and which core function calls corresponding db function. We can modify the limit (after adding it) in the core function, to test it.

Feel free to ask if you have any questions.

[vil02]

@apoorvdixit88 Thanks for the feedback. I am still not sure how to create some automated tests.

I created #6191: could you please have brief look and tell me if it goes into right direction and approve the workflows.

[apoorvdixit88]

The changes look fine. To test the behaviour of the limit, you can manually hit the following route after signing up.

curl 'http://localhost:8080/user/user/v2/list' \
  -H 'authorization: Bearer JWT' \

For testing purposes, try setting the limit to 0(or some number, when invoking from core function) and observe how it affects the response. This will help verify that the limit functionality is working as expected.