Tuesday, November 5, 2024
2 changes · saas-17.4
Resolved issues and error corrections
Live chat operators are now correctly shown as available when they are working remotely or from another configured work location. This restores the website chat popup for businesses using remote work planning, while avoiding availability for employees marked as on leave.
Original PR description
Steps to reproduce: - Install hr_homeworking - Livechat app > website.com > Configure channels - Mitchell Admin must be among the operators - Employees > Mitchell Admin > Work information tab - Set a 'Remote work' location for the current day - Website app > The livechat popup does not appear (bottom-left) This happens because hr_homeworking changes the im_status field's value to from 'online' to 'presence_[location_type]_online'. That change was not reflected by the function which computes operator availability, meaning the operator will never show as online on days they have a location set. Additionally, im_status 'leave_online' should not be considered as a status that marks available operators. Unfortunately, since locations can be created at will we can't make an exhaustive list here. opw-4196707 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Deadline dates are now grouped into the correct calendar week for users in locales that follow ISO week numbering, such as UK English. This prevents tasks around New Year from appearing under the wrong year or week when viewed in grouped lists.
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Set localization to UK English (or any using ISO week numbering); 2. use Europe/Brussels timezone; 3. set a task's deadline to 2024-01-01 00:00:00; 4. go to task list view; 5. group by Deadline > Week. Issue ----- Task is grouped under W52 2023. The correct ISO week number for this date is 1.[^1] Cause ----- Commit 75c63315169c added a custom `weeknumber` function to `date_utils` to circumvent the issues with Babel's week numbering. If given a `datetime` object, it should be localized with the appropriate timezone instead of being passed as UTC. Solution -------- The value provided to the `_read_group_format_result` is already in the localized timezone. This gets assigned to `range_start`, which gets converted to UTC. Instead of passing `range_start` to `weeknumber`, we can provide it the unmodified `value` variable. opw-4188099 [^1]: https://www.calendar-365.co.uk/calendar/2024/January.html