Tuesday, March 31, 2026
2 changes · 17.0
Resolved issues and error corrections
This update fixes an issue where payment reminder emails for subscriptions were missing key information like the subscription end date and code. The fix ensures that these details are automatically included in the email template when a payment reminder is manually generated through the email composer. This improves the clarity and accuracy of payment reminders for subscription customers.
Original PR description
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In…
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing. ### Steps to reproduce the issue: 1. Install subscription and go to that app 2. Open one subscription 3. Send message > Load template: "Subscription: Payment Reminder" 4. Sentence is incomplete: missing end date of the subscription ### Cause of the issue: The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template. ### Reason to introduce the fix: The fix introduces a dedicated method to dynamically compute and inject the correct context when the payment reminder template is selected in the email composer. It ensures that the logic is only applied for subscription records (sale.order with is_subscription = True) and specifically for the relevant template. opw-6031613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a flaw in the website user leaderboard, ensuring users are ranked accurately based on their recent activity (karma gain) within specified time periods like 'This Week' or 'This Month'. Previously, the system incorrectly sorted users, leading to inaccurate rankings. This fix improves the user experience by presenting a more reliable and relevant leaderboard.
Original PR description
[FIX] website_profile, gamification: fix weekly/monthly leaderboards Prior to this commit, the leaderboard pagination logic was flawed when filtering by specific time periods (e.g., "This Week" or…
[FIX] website_profile, gamification: fix weekly/monthly leaderboards Prior to this commit, the leaderboard pagination logic was flawed when filtering by specific time periods (e.g., "This Week" or "This Month"). The system would first retrieve users sorted by their *all-time* global karma, apply pagination (taking the top X users), and only then calculate the karma gain for the specific period for those few users. This caused users with high recent activity but low all-time karma to only be displayed much later in the page order than they should. This commit fixes the issue by introducing a pre-search step that calculates the karma gain for the requested period at the database level. Pagination is now applied to this specific result set, ensuring users are correctly ranked by their actual performance during that week or month. Note: A new method `_get_users_by_tracking_karma_gain` was added to `res.users` to handle this logic. This approach was chosen to strictly preserve the signature of existing methods for the stable version. A distinct refactor to unify these calculation methods is planned for the master branch. Steps to reproduce: - Install the eLearning module. - Create a few users with different karma_points (more than 25 to have 2 pages). - Go to /profile/users. - Group by week. - Paginate, and you will notice that the order is wrong; the first user on the second page might have more points than users on the first page. Also, when the logged-in user is not on that page, they do not appear at the bottom. task-5344657 opw-3979785