LBMS V7.6.0 Release Notes

User and Role Management: Maker-checker is now enabled for User/Role management and Manual Points processes.
Enhanced Insights: The maker-checker UI has been enhanced to provide more insights into the status of requests (raised, approved, or rejected).
Program-Level Activation: Maker-checker can now be enabled at the program level, and once enabled, it cannot be disabled. If the module is not enabled for a specific function, requests will follow the standard approval flow (without verification/approval).
Request Scope: Maker-checker applies only to user creation, updates, and unlocking. Other actions, such as password resets or archiving, are not part of this process.
Request Precedence: In case of multiple requests for a user/role, the latest accepted request will take precedence.
Bulk Approval/Rejection: Bulk approval or rejection of maker-checker requests has been removed in this version.
Email Notifications: Users will receive emails summarizing the number of pending actions at the program level. An enhancement for user-level notifications is planned for future releases.

Local Attributes: New custom transaction report views can now include local transaction attributes with no limit on the number of attributes.
Attribute Handling: If an attribute is deleted but still used in a report, it will be automatically removed from the report without causing any issues.
Performance Improvements:
- Faster Report Generation: Report generation has been shifted to MSSQL, significantly improving performance. Previously, generating a 1 million record report with 25 attributes took 30-40 minutes. Now, the same report is generated in just 1-2 minutes.
- Resource Optimization: This change also reduces resource demands (memory/CPU) since report generation no longer happens in the app services, freeing up resources for other tasks.

Error Log Files: The error log file creation and upload process has been moved to MSSQL, reducing the processing time by 30%. This reduces the load on application services, improving overall efficiency during large CPD or TXN uploads.

Report Overview: A new Projected Expiry Report is introduced, generated monthly at the member level. The report's columns are customizable based on user input during program setup.
Performance: The QA team tested the report with 10 million members and 11 million transactions over one year, and the report took 45 minutes to generate.

Dependent Permissions: Now, when enabling certain permissions such as "Add/Remove Points" or "Suspend Member," the system automatically enables dependent permissions like View Member. Users can still manually deselect these if needed.

For Developers: This new feature allows the DevOps team to export and import settings (e.g., member attributes, transaction attributes, groups, rules, communication templates) between different programs, as long as both are on the same LBMS version.
Limitations: Currently, disabled or archived templates and rules are exported. Future releases will focus on exporting only active items.

Configuration Cleanup: Unused configurations were removed from the dev ops config map in the QA environment. The application was thoroughly tested to ensure no breakages occurred due to this cleanup.
Security Consideration: The configuration of the storage bucket is a focus, as the public setting may pose security risks for user-related reports.

MSSQL Infrastructure: Load tests were conducted for the QIB client, who requested a 2-core MSSQL infrastructure. The current recommendation is 4-core, 16GB RAM for clients with over 1 million customers or transactions.
Test Results:

Scenario	Time Taken
1M CPD upload	12 min
1M TXN upload	62 min
1M Member Report	52 min
4M TXN Report	20 min
200k TXN processing via API	62 min
1M Segment Creation	30 sec
1M Member Tier Movement	2 min 30 sec
Redemption API for 50 concurrent users	28.99 TPS (1676 ms avg response time)

Unified Time Format: All timestamps displayed in the LBMS application will now be based on the DB/Server time. Exported files will continue to use the time based on the user's browser settings.

Email Template: The Title field in email templates is now optional for newly created templates. However, any edits to existing templates will still require a title.

No Default Emails: With this feature, if no transactional email templates are created or if they are disabled, members will not receive emails by default.

Emails Delivered to Wrong Email ID: This issue has been resolved and a patch has been released to affected customers.