Sandeep Kumar

As part of introducing modular product types (e.g., Payments, Recon, Vault), permissions should be scoped specifically to each product, ensuring that access is properly segregated. For example, a user with...

We can try to support explicit user preferences by allowing users to select and save a preferred merchant account and profile, in the Users section of the dashboard. This allows...

fix(users): use global Redis prefix for all user-related cache operations

1

## Type of Change - [x] Bugfix - [ ] New feature - [ ] Enhancement - [ ] Refactoring - [ ] Dependency updates - [ ] Documentation -...

Currently, the **last used lineage context** (org_id, merchant_id, profile_id, role_id, tenant_id) is cached temporarily in Redis with a 7-day TTL. While this improves user experience across sessions, it introduces problems...

Currently, user-related data in Redis (such as SSO IDs, TOTP codes, email token blacklists, lineage_context etc.) is using tenant-specific prefixes like `public:` or `public_v2:`. This causes issues when users use...

feat(users): store and retrieve lineage_context from DB instead of Redis

1

## Type of Change - [ ] Bugfix - [x] New feature - [x] Enhancement - [x] Refactoring - [ ] Dependency updates - [ ] Documentation - [ ]...

Currently, the `Platform Organization` only supports a `Platform Merchant Account` by default, and `Connected Merchant Accounts`. But in addition to extension of the VSaaS Architecture, the Platform Organization should now...

Extending VSaaS to support Platform Merchant Standard Merchant interaction in the Platform Org

In the current Authentication System, at max, only two kinds of authentications are possible for an API: - JWT Auth - Any API Key based Auth (API Key, Admin API...

Need to create a new kind of authentication: PlatformAuth (and its variations) This authentication will enable Platform Merchants to perform the following operations: **Merchant Account** - Create - Retrieve -...