Evergreen farms (pos)

• @ discussion with my Team Lead (TL) and Teja to understand and finalize the complete Module → Screen → Role → Plan → Company Access flow.
• After the discussion, Teja and I finalized the approach and process with the Team Lead, and then started the implementation work.
• Fetched the required role and screen data from the database using the API.
• Integrated the API in Evergreen POS Frontend to display the screen/menu data dynamically.
• Divided and mapped the existing screens based on the required user roles.
• Added the role-wise screen configuration for roles such as Admin, Manager, Cashier, Accountant, Service Manager, Sales Representative, Warehouse Manager, Field Staff, Contractor, Partner, Staff, Ecom Manager, etc.
• Updated the frontend to fetch the logged-in user's role and display the corresponding screens based on that role.
• Replaced the previous static screen/menu handling with the database/API-based role and screen data.
• Prepared the initial structure for Module → Screen → Role → Plan access management.
• Created the PPT/documentation explaining the proposed Modules, Screens, Roles, and Plans flow.
• Verified the role-based screen visibility in the frontend.

- Sidebar menu is now role-based: each user automatically gets only the screens their role grants, and the Admin menu lists every page RBAC allows. particalr company(evergreen) database we are store particlar collectoin of this
- Added company plan history to track plan changes and module changes.
- Improved RBAC access performance with request-level access checks and catalog caching.
- Added automatic access refresh using X-Access-Version, so plan or catalog changes show up without a manual reload.
- Implemented module dependencies using dependsOn.
- Implemented screen-level API authorization using guardScreen, with SCREEN_GUARD_MODE (off, log, enforce).
- Updated frontend RBAC to refresh access automatically and show downgrade and new-page notifications.
- access api to fetch the particlar roal to this screens
- Role Screens API: Developed the backend API to fetch and identify which screens are accessible to each role.
- Role Login: Resolved the login issue for newly created roles by updating the role-based login logic, ensuring that new roles can log in successfully.

- Identified the missing fields in the Role-Based Collection and added them by taking the Main Super Admin database as the reference.
- Developed an API to fetch the complete default screen details and screen configurations from the Super Admin database.
- Implemented plan-based screen fetching so the company database can display only the screens available for the particular plan.
- Ensured the existing company database screen configuration can be updated/fetched dynamically from the Super Admin configuration.
- Implemented automatic role synchronization from Super Admin to the company database.
- When a new role is created in Super Admin, the role is automatically fetched and created in the company database.
- Automatically fetched the screens associated with the newly created role and mapped them to the role.
- Ensured users assigned to the role can access the appropriate screens without manually configuring the role and screen mapping again.
- Reduced duplicate role and screen configuration between Super Admin and company databases.
- Handled scenarios where a role is deleted from Super Admin while users in the company database are still assigned to that role.
- Removed stale/deleted role assignments from users when the corresponding role no longer exists in Super Admin.
- Fixed the first-login issue caused by users having roles that were deleted from Super Admin.
- Updated role validation to safely handle missing, deleted, or disabled roles.
- Fixed the issue where Edit and Delete actions on the Users page were not opening when a user's assigned role no longer existed.
- Ensured User Management continues to work correctly even after roles are deleted or modified in Super Admin.
- Implemented automatic role creation/synchronization during the required user or company setup process.
- Ensured newly available roles and their associated screens are automatically available without requiring manual configuration.
- Updated Access API handling so multiple simultaneous requests share the same request/result instead of making duplicate API calls.
- Implemented 60-second result reuse for Access API requests to reduce unnecessary API calls and improve performance.
- Added automatic Access API refresh when permission changes are made so updated permissions are reflected without waiting for the existing cache period.
- Implemented Redis caching for the role/screen catalog to improve catalog API performance.
- Added Redis cache clearing whenever the catalog is saved or modified so stale role and screen information is not returned.
- Updated the role deletion confirmation to display the affected company names before deletion.
- Added assigned user information to the deletion confirmation, including the number of users assigned to the role.
- Added validation to prevent role deletion when users are still assigned to that role.
- Ensured the user must remove/reassign the affected users before the role can be deleted.
- Ensured Super Admin remains the central source of truth for roles, permissions, and default screen configurations.
- Ensured role creation, screen mapping, permission updates, and role deletion are synchronized safely without breaking user login, authorization, or User Management.