Friday, March 21, 2025
7 changes · saas-18.2
Resolved issues and error corrections
Employee profile pages no longer fail to open when an employee has completed a course that the viewer cannot access directly. The change safely retrieves only the course link information with elevated permissions, avoiding unnecessary access errors while preserving course visibility rules.
Original PR description
Since there are read access restrictions on the courses (for exemple courses visible only for attendees), when someone wants to see an employee havin finished one of this course, he gets an access error to the employee form because he has no access to the course. So we are getting the value in sudo as it only display a link to the course but does not do anything else. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The purchase list view now avoids showing two scrollbars when the purchase dashboard is displayed above it. This makes the purchasing screen easier to navigate and reduces visual clutter for users reviewing purchase records.
Original PR description
Due to the purchase dashboard on top, there is a double scroll on the list view. task-4664621 follow-up task-4508833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects and clarifies internal web documentation for a developer helper function. It helps developers use the function correctly, reducing confusion and the chance of mistakes in future web interface work.
Original PR description
In [1] the documentation of `protectSyncAfterAsync` was improved. The introduced example contained a mistake and it did not make it clear that the function did return a function. This commit fixes the example and insists on the fact that the return value is a function. [1]: https://github.com/odoo/odoo/commit/94b84a25ead96e6217819d7d6b54e869e5a15c41 task-4367641
Users can now type :triumph: to insert the face-with-steam-from-nose emoji in Odoo's emoji picker. This makes the emoji easier to find and use with a commonly understood meaning.
Original PR description
The :face_with_steam_from_nose: emoji shows literally a "face with steam from nose", but it also means "triumph". This is an original way to show proudness and uncultured people can learn it thanks from this additional shortcode. 
This fixes an issue where selecting certain emojis in Discuss inserted or displayed them as multiple separate symbols instead of one intended emoji. It also removes the Wales flag emoji option because it cannot be displayed consistently across supported platforms, especially Windows.
Original PR description
Before this commit, inserting emoji in composer resulted in inserted several other different emojis. Steps to reproduce: - open a composer in Discuss - type `:family` - pick the…
Before this commit, inserting emoji in composer resulted in inserted several other different emojis. Steps to reproduce: - open a composer in Discuss - type `:family` - pick the `:family:_man,_woman,_girl,_boy:` suggestion => composer contains 👨👩👧👦 rather than 👨👩👧👦 (this is a single emoji visually, as long as you use a modern font and text visualizer). This happens because this single emoji that represents a household composition is actually represented as 4 simpler emojis. When using a modern font, this is transformed into a single emoji. With non-modern fonts that have basic support of emojis, this is shown as the 4 emojis, as an attempt to keep the same semantics even with the lack of support of this modern emoji. In discuss, there's a custom font-face to size emojis bigger than pure text, so that emojis are more visible. The list of font family provided used "Color Emoji" variants on apple devices and Linux distributions, which somehow lack some modern emoji like the family household composition above. This commit fixes them trivially by using the non-color "Emoji" variants of these font families. Windows uses "Segoe UI" and didn't have the issue. This problem was also affecting the few regional flag that were supported in Discuss like `:wales:`, which was displayed as 🏴 rather than the 🏴. While the current change fixes it for apple devices and Linux distributions, the bug was still present on Windows. It looks like there's no font on Windows that support them, thus we decide to remove them like all other regional flags. As a reminder, the regional flags are not present in emoji picker because Windows made the intentional decision to not support them [1] [2] for geopolitical reasons. [1]: https://devblogs.microsoft.com/oldnewthing/20030822-00/?p=42823 [2]: https://x.com/JenMsft/status/1399979907338309633?t=jdMssoDqJ6UjML-gu9pFig&s=19 Before / After <img width="261" alt="Screenshot 2025-03-20 at 18 48 09" src="https://github.com/user-attachments/assets/4e2e4059-6376-4882-b24c-5556f8d08339" /> <img width="258" alt="Screenshot 2025-03-20 at 18 48 22" src="https://github.com/user-attachments/assets/92fee8d9-0973-4672-8320-0e019bc4b35c" />
The Discuss sidebar now shows the ongoing call icon with the correct color even when the call was started from another browser tab. This makes it clearer to users that they are already in an active call and avoids confusing visual differences between tabs.
Original PR description
Before this commit, the "ongoing call" icon in discuss sidebar has a different color when the current user is in call or not. This was working well on the tab making the call, but not on the other tab. This happens because the condition was on `rtc.state.channel` rather than `rtc.channel`. Both means the channel with self user in ongoing call but the former is set when the tab is actually making the call, whereas the later is when any tab is making the call. The indicator is meant to show when any tab is in an ongoing call, hence the fix in this commit. Before <img width="1046" alt="Screenshot 2025-03-20 at 11 39 10" src="https://github.com/user-attachments/assets/57a80274-7bb1-4ad3-a4af-80bf53c58fd1" /> After <img width="1042" alt="Screenshot 2025-03-20 at 11 38 06" src="https://github.com/user-attachments/assets/2e5748f5-9323-46c7-a2e5-624312b5e9eb" />
A payroll-related test was updated to match the corrected way applicant email names are interpreted. This helps keep automated checks reliable after recruitment email handling was aligned with standard Odoo behavior.
Original PR description
Now that hr_recruitment correctly use standard mail tools to create partners from emails it correctly calls model tools to deduce partner name, which prioritize partner_name over name found in email. See community PR for more details. Task-4656218