Friday, March 29, 2024
4 changes · saas-17.1
Resolved issues and error corrections
This fix ensures background colors in Odoo email templates display correctly even when the Website app is not installed. It prevents parts of mass mailing templates from appearing transparent, improving visual consistency for recipients.
Original PR description
**Current behavior before PR:** Opening OXP template in mass mailing without installing website there are some background colors that became transparent. This issue is introduced by [1] commit. This issue occurs because the $bg-gradient variable referenced in the commit cannot be included within a file of web_editor. Additionally, it cannot use the o-website-value to retrieve its value. **Desired behavior after PR is merged:** Now it will show the background color of block without website installed. [1]: https://github.com/odoo/odoo/pull/75680/commits/5c4ad451787a1a52824a046c9ae81b0e86a05a3b task-3688383
Fixed a small display issue in the chatter area that showed an extra “on” indicator while users were creating a new record. This keeps the interface cleaner and avoids confusion during record creation.
Original PR description
**Current behavior before PR:** An extra 'on' indicator was incorrectly displayed in chatter while creating a new record, leading to UI display issues. **Desired behavior after PR is merged:** Resolved the issue where the extra 'on' indicator was not properly displayed during new record creation. Task-3826569 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restaurant table appointments that end after midnight now appear correctly on the following day. When an appointment started the previous day, its displayed start time is adjusted to the start of the current day to avoid confusing staff.
Original PR description
Before this commit, if the end of a table appointment was ending the day after the start day, the appointment wouldn't be displayed. Fixing this, a new issue arises, if an appointment start the day before, showing it next day will create confusion since it will display the starting time of the previous day. To fix this we simply set the starting time to the start of the day.
The appointment test setup now specifies a timezone directly when demo data is unavailable. This prevents test failures caused by users without a saved timezone, improving reliability for quality checks.
Original PR description
With no demo data, the current user does not have a timezone set. As the default value of appointment_tz is based on that, it leads to an error. We now set manually the appointment_tz for the appointment type created. runbot-55570 runbot-55571 runbot-55572 runbot-55573 runbot-55574