Monday, May 18, 2026
12 changes · saas-18.4
Resolved issues and error corrections
Point of Sale now includes archived units of measure when loading product data. This prevents checkout or order creation errors when a product still uses an archived unit, helping sales continue smoothly.
Original PR description
If a product uses an archived UOM and an order is then created in the POS with this product, an error would occur because it could result in trying to use a UOM that wasn't loaded in the POS since it was archived. To fix this issue, we now load archived UOMs in the POS. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6197465 Forward-Port-Of: odoo/odoo#264441 Forward-Port-Of: odoo/odoo#263838
Sales users can now re-enter a discount coupon code if they closed the reward selection without applying a reward. This avoids a confusing validation error and lets them continue the sales order workflow without unintended duplicate discounts.
Original PR description
Issue: --- ### Steps to reproduce: 1- Create a `Discount Code` program. 2- In SO, use `Coupon Code` wizard and use the code. 3- After available rewards are shown, discard the wizard. 4- Re-apply the code. Validation Error: The promo code is already applied. As the reward is not applied, this is functionally confusing. At this point We can see the reward only inside the rewards wizard view. If we allow re-apply the code in case no reward line is created for the `rule.program_id`, we can still see the reward by re-applying the same code, without any side effects. opw-6164198 Forward-Port-Of: odoo/odoo#264105 Forward-Port-Of: odoo/odoo#261950
Clicking archived users in channel or group member lists is now prevented, avoiding an error screen. This keeps the member list behavior consistent with messages and improves reliability for users browsing discussions.
Original PR description
Previously, clicking on an archived user from the channel or group member list triggered a traceback. This PR prevents archived users from being clickable, aligning the behavior with the message model where the popover is not opened for archived users, thus avoiding the traceback. enterprise: https://github.com/odoo/enterprise/pull/117480 task-6179486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor color picker now correctly detects colors defined with the modern CSS color format. This prevents confusing editing behavior where existing background colors appeared unrecognized, helping users maintain page styling reliably.
Original PR description
Following the website refactoring (commit 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2) `BuilderColorPicker` no longer recognizes colors defined using `color()`, introducing a regression. This commit restores support for `color()` values. Steps to reproduce: 1. Add the snippet `s_text_image`. 2. Manually, in the DOM, set the style of the first column to "background-color: color(srgb 0.4 0.2 0.8 / 0.4);". 3. In edit mode, click on the column to observe that the colorpicker does not recognize the background color. The same behavior can also be observed in the custom tab. Task: [5453922](https://www.odoo.com/odoo/project/974/tasks/5453922)
Searching click records by the displayed short link now works as expected instead of triggering a server error. This helps marketing users filter link click activity reliably when reviewing email campaign engagement.
Original PR description
Overview ------ When searching based on the `Link (short_url)` field in the search bar, in the `link.tracker.click` list view, an error fires up. How to Reproduce ------ 1. Open the Email Marketing…
Overview ------ When searching based on the `Link (short_url)` field in the search bar, in the `link.tracker.click` list view, an error fires up. How to Reproduce ------ 1. Open the Email Marketing app 2. Create a new mailing (or you can use an existing one that has some clicks) and send it 3. Make a click in the email from the recipient's side 4. Open the link tracker `click` related to that mailing (select the mailing → `Link Trackers` stat button → click on a link → `Clicks` stat button) 5. Make a search based on the Link (short_url) field Expected Behavior ------ Return the list of links that matches the entered search query. Current Behavior ------ Odoo Server Error. Cause & Solution ------ The cause of this error is that the `shor_url` field is a computed, non-stored, field, and hence, we cannot directly make a search on it. So, either we make the `short_url` a stored field, which is not so efficient, or we create our own custom `_search_..` method. Task-6131693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260146
Fixed an issue where weekly time off accrual plan milestones could show the wrong weekday after saving. This helps HR users verify accrual schedules accurately and avoid confusion when configuring employee time off rules.
Original PR description
**Steps to reproduce:** 1. Install Time Off 2. Go to Accrual Plans and create a new plan with a milestone 3. Set frequency to Weekly and choose a day other than Monday (e.g., Tuesday) 4. Save and…
**Steps to reproduce:** 1. Install Time Off 2. Go to Accrual Plans and create a new plan with a milestone 3. Set frequency to Weekly and choose a day other than Monday (e.g., Tuesday) 4. Save and check the displayed weekday in the accrual plan level **Issue:** The displayed weekday is incorrect (e.g., shows Monday instead of Tuesday). **Cause:** Previously, the weekday value was directly displayed using: https://github.com/odoo/odoo/blob/b40184ab371f7a4708621ecf7f25b4e2daaae38d/addons/hr_holidays/views/hr_leave_accrual_views.xml#L212-L214 so no conversion was involved. Now, the value is processed using Luxon. However, the week_day field stores values from 0 (Monday) to 6 (Sunday), while Luxon expects ISO weekday numbers from 1 (Monday) to 7 (Sunday). This mismatch causes an off-by-one error during conversion. https://github.com/odoo/odoo/blob/1b3d0a3c2f794324f8b230a9ae19f097454e3bdd/addons/hr_holidays/models/hr_leave_accrual_plan_level.py#L54-L62 **Solution:** Adjust the value before passing it to Luxon by adding +1 to match ISO format. opw-6112614 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the process of fetching transactions from Codabox for users connected through Odoo. Previously, users needed write access to the company record, which wasn't necessary after an initial connection was established. This change removes that requirement, streamlining the process and improving user experience.
Original PR description
Currently, we use the `_l10n_be_codabox_verify_prerequisites` method before trying to fetch transactions. This method checks if the user has write access rights on res.company model which should not be mandatory to fetch transactions from codabox when the connexion is already created. opw-6108811 Forward-Port-Of: odoo/enterprise#117097
This update resolves a test failure in the WhatsApp discuss sidebar by aligning it with a recent change that now only considers active users when determining available commands. This ensures the test accurately reflects the current system behavior and prevents errors.
Original PR description
This PR updates the discuss sidebar testcase to match the new behavior where only active users are considered when computing main_user_id, reducing the number of available commands and fixing the failing assertion. community: https://github.com/odoo/odoo/pull/262247 task-6179486
This update fixes issues with the XML structure used for Swedish bank payments (l10n_se_bban). Specifically, it ensures the correct format for mandatory fields and prioritizes using BIC codes for bank identification, enhancing compatibility with Nordea and other Swedish banks. This improves the accuracy and reliability of payment processing.
Original PR description
Here is few fixes added to the swedish iso 20022 XML: - CdtrAgt seems to be always mandatory, change the condition in `_skip_CdtrAgt` to always use the CdtrAgt if payment_method is iso20022_se - The `_is_se_bban` is too restrictive, this should be always True when payment method is swedish iso - The `FinInstnId` node can either contain BIC or ClrSysMmbId. But as ClrSysMmbId seems to change from one bank to another, it's more relevant to always use the BIC. opw-5395736 Forward-Port-Of: odoo/enterprise#114662
This update resolves an error that occurred when generating the SD Worx report under specific circumstances – namely, when a company had a public holiday without a defined working schedule. The fix ensures the report correctly handles employees without schedules, preventing a system error and improving report reliability.
Original PR description
## Steps to reproduce: - Install l10n_be_hr_payroll_sd_worx module - Create a public holiday in one company without a working schedule - Create an employee that doesn't have a working schedule nor a contract - Try to generate the sd worx report - A traceback will pop-up ## Cause: Since we fetch all employees if we have a public holiday with no schedule, this puts us in a scenario where we try to access a key in that doesn't exist and it will trigger a KeyError ## Fix: Make sure we fallback on an empty recordset in case we don't have the employee in the key list of the dict we are checking opw-5500070 Forward-Port-Of: odoo/enterprise#117268
This update resolves an issue where users without write access to the Fiskaly Point of Sale (PoS) module would receive an access error when attempting to authenticate with a token that had expired. The fix ensures that the correct error message is displayed, preventing disruptions to sales transactions.
Original PR description
When trying to auth directly from the PoS when the token expires, if you are logged in with a user that doesn't have write access to the PoS. You would get an access error. Steps to reproduce: ------------------- * Setup Fiskaly in an AT company * Open PoS and try to make a sale * To fake the token expiration I modified the code so that the request always return 401 status code > Observation: You get an access error opw-5925203 Forward-Port-Of: odoo/enterprise#112474
This update corrects a technical issue where an approval rule was being applied incorrectly due to a duplicate XML ID. The change ensures that approval rules are applied correctly based on user and manager roles, improving the reliability of the approval process. This resolves a potential inconsistency in how approvals were handled.
Original PR description
The XMLID `approval_approver_manager` was defined twice, causing the rule to be applied with the last evaluated access configuration for both `group_approval_user` and `group_approval_manager`. This commit renames the first occurrence of the duplicated XMLID to `approval_approver_user` to restore the intended separation between user-level and manager-level approval access rules. task-6095010 Forward-Port-Of: odoo/enterprise#113480