Wednesday, December 17, 2025
13 changes · saas-18.4
New functionality added to Odoo
This update incorporates the Global Location Number (GLN) into delivery partner records. This is a necessary change to comply with new eInvoicing reporting requirements, ensuring accurate and complete electronic invoices are generated and submitted.
Original PR description
This commit adds the Global Location Number (GLN) to delivery partners, which is required to be reported during eInvoicing. task: 5237220 Forward-Port-Of: odoo/odoo#240020 Forward-Port-Of: odoo/odoo#237591
Resolved issues and error corrections
This update fixes a security vulnerability where Portal and Internal users could create private Knowledge Articles even without the necessary permissions. The change restricts article creation to users with 'create' access, improves the user interface by hiding creation buttons for unauthorized users, and includes new tests to ensure this fix is effective.
Original PR description
How to Reproduce : 1. Remove 'Create' access on the 'Knowledge Article' model for Portal and Internal users. 2. Now log in as a Portal. 3. Try to create a new private article. 4. Log in as an…
How to Reproduce : 1. Remove 'Create' access on the 'Knowledge Article' model for Portal and Internal users. 2. Now log in as a Portal. 3. Try to create a new private article. 4. Log in as an Internal user. 5. Try to create a new private article. Both Internal and Portal users can still create private articles even after 'Create access' is removed. Article creation logic in `knowledge.article` was bypassing the usual access rights because of `sudo` (mainly to add the creator as a member, since creation rights on the member model are not granted). This allowed users to create private articles even without create access. This commit introduces: 1. Model-level access check in `create`. Sudo the creation of articles only when the user has create rights. 2. UI imp to hide the '+' button in the sidebar and the `New` button in the topbar when the user doesn't have create access. 3. New test cases to verify that model-level access rights are respected when creating an article. task-4916280 Forward-Port-Of: odoo/enterprise#101804 Forward-Port-Of: odoo/enterprise#93034
This update automatically marks Odoo orders as paid when they are dispatched by UrbanPiper. This prevents orders from being accidentally cancelled during POS closing, improving efficiency and reducing potential order disruptions. The update also ensures UrbanPiper orders are recorded in Odoo's blackbox for comprehensive tracking.
Original PR description
*= urban_piper, black_box_be In this commit: =============== - When UrbanPiper updates an order to `dispatched`, we now automatically mark the order as paid in Odoo. - This prevents the order from being cancelled during the POS session closing if the cashier forgot to mark it as ready. - Also, we are adding this urban piper order to the blackbox, if it was not recorded in it. Task: 5261892 Forward-Port-Of: odoo/enterprise#102280 Forward-Port-Of: odoo/enterprise#99513
This update fixes an issue where pasted content in the website builder's translation mode wasn't correctly styled, leading to visual inconsistencies and reset spans. The fix ensures translated content is properly formatted and avoids unexpected HTML structure, improving the translation experience. Additionally, the system now restricts inserted content in translate mode to a whitelist of approved elements to maintain translation integrity.
Original PR description
### [FIX] html_editor: unwrap blocks when inserting in editable span When the ancestors of the selection are not elements supposed to contain blocks when pasting, nothing was done to remove those…
### [FIX] html_editor: unwrap blocks when inserting in editable span When the ancestors of the selection are not elements supposed to contain blocks when pasting, nothing was done to remove those blocks. This could lead to `span` elements containing `p` elements for example. This commit unwraps the blocks in the pasted content if the block containing the selection is outside of the `contenteditable` element that contains the selection. It also fixes the function `makeContentsInline` that was not robust to containing some nodes structures. Steps to reproduce: - Open `example.com`, and copy "Example" from the first block - Open website builder in translate mode - Paste - Bug: The appearance is weird because the pasted title is not styled as translation - Save - Bug: The span of translation where the text was pasted has been reset #### - Open `example.com`, and copy the whole content - Open website builder - Move cursor to the bottom of the footer, with the company name - Paste - Bug: it inserted a `p` element in the `span` (non deterministic, depends on the mood of the AI) - Open website builder in translate mode - Select some text (more likely to trigger the bug if it includes a line break, for example the description in the footer) - Use the "Translate with AI" tool from the toolbar - Bug: The appearance is weird because the inserted translation is not styled as translation - Save - Bug: The span of translation where the text was changed has been reset opw-5053872 opw-5109137 opw-5136337 task-5222402 ### [FIX] website: restrict inserted content in translate mode to whitelist The translate mode of the website builder should only ever insert nodes with a tag in the `TRANSLATED_ELEMENTS` whitelist or with `o_translate_inline` class inside a translation span. Doing otherwise makes the translation span "invalid" according to the server, which discards the translation. Blocks are already unwrapped when inserting in translations (by the previous commit), but some other nodes are not in the whitelist, for example `img`. This commit adds the class `o_translate_inline` on `a` elements when inserted and unwraps nodes that are not in the whitelist and do not have that class. Steps to reproduce: - Open `example.com`, and copy the link "Learn More" - Open website builder in translate mode - Paste - Save - Bug: The span of translation where the link was pasted has been reset #### - Copy an image (or a piece of html containing an image) - Open website builder in translate mode - Paste - Save - Bug: The span of translation where the image was pasted has been reset opw-5053872 opw-5109137 opw-5136337 task-5222402
This update fixes an issue where attempting to refund orders that included archived products would cause a blank page error. The fix ensures that the system correctly identifies and processes product information, allowing refunds to be processed even after a product has been archived. This improves the reliability of the point-of-sale system.
Original PR description
Step to reproduce: - start pos and finalize a order with product A - go backend - Archive product A - start the pos again - try to refund the order Observation: - Blank page with traceback in console…
Step to reproduce: - start pos and finalize a order with product A - go backend - Archive product A - start the pos again - try to refund the order Observation: - Blank page with traceback in console ``` Caused by: TypeError: Cannot read properties of undefined (reading 'filter') at __exports.getOrderChanges at Proxy.getOrderChanges ``` Cause: - until now `product.template` model is looked for filter after a reload https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/models/data_service_options.js#L91-L93 https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/services/data_service.js#L290-L295 and not `product.product`, this makes `product_id` available but `product_tmpl_id` undefined, causing inconsistency Fix: - we add `product.product` in `cleanupModels` for data to in sync with backend opw-5237961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238514
This update fixes an error in how BoM kits with nested components were valued, preventing overvaluation due to incorrect cost sharing calculations. It ensures accurate inventory valuation by correctly applying cost shares at each level of the BoM hierarchy. This requires AVCO (Average Cost) to be enabled.
Original PR description
### [FIX] purchase_mrp, mrp: correct BoM Kit valuation with nested kits #### Issue: When purchasing a BoM Kit (50/50) containing others BoM Kits (50/50), cost share was applied at each level (50%…
### [FIX] purchase_mrp, mrp: correct BoM Kit valuation with nested kits
#### Issue:
When purchasing a BoM Kit (50/50) containing others BoM Kits (50/50), cost share was applied at each level (50% instead of 25%), leading to overvaluation (e.g., 200% total instead of 100%)
#### Cause:
`cost_share` was always applied fully during BoM explosion and as a portion of the full price on `_get_unit_price()`
#### Other bug fixed:
Fix `_get_cost_share()` to correctly return 0 when BoM total cost_share already equals 100%
#### Requirement:
AVCO (Average Cost) must be enabled on all components/BoMs
#### Steps to reproduce:
1. Recreate that hierarchy with AVCO Products
- A kit "Testing Kit Complete" containing:
-- "Component01", cost share 50%
-- A kit "Testing Kit 1", cost share 50%:
--- "Component02", cost share 50%
--- "Component03", cost share 50%
2. Create and validate a Purchase Order for "Testing Kit Complete" (unit price: 1000)
3. Receive the products
4. Go in Inventory > Reporting > Valuation and search for Component
5. All 3 components are set to 500, instead of Component01: 500 / Component02: 250/ Component03: 250
opw-4806023
### [FIX] purchase_mrp: correct BoM valuation with product variants or optional lines
#### Issue:
BoM valuation ignores variant-specific lines and does not skip lines with quantity 0
#### Cause:
The code only checks that the BoM adds up to 100%
But this can cause issues with variants that do not include all products or with optional lines
As a result, the total valuation may be incorrect
#### Steps to reproduce:
1. Recreate a kit hierarchy with AVCO products:
- Kit "Variant Kit" (Variant Color: White and Wood) containing:
-- "Component01", cost share 0%, only for variant White
-- "Component02", cost share 0%
2. Create and confirm a Purchase Order for "Variant Kit" (variant: Wood, unit price: 1000)
3. Receive the products
4. Go to Inventory > Reporting > Valuation and search for the components
5. Only Component02 appears with 500$, so only half of the total value is shown
opw-4806023
opw-5085457
Forward-Port-Of: odoo/odoo#218326This update corrects a bug where a procurement group wasn't consistently linked to deliveries when multiple moves were added to a picking. The fix ensures that a procurement group is always created and associated with the delivery, streamlining the process of managing stock transfers related to sales orders. This improves the accuracy of inventory tracking.
Original PR description
### Steps to reproduce: - Create a picking with a move for any product #### Issue 1: > A procurement group is created and linked to the transfer - Add a second move on the picking and save #### Issue 2: > The procurement group of the picking is lost ### Cause of the issue: The `_set_sale_id` set method creates a procurment group and links it to the picking no matter if the `sale_id` is set or not. https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/sale_stock/models/stock.py#L90-L93 https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/sale_stock/models/stock.py#L100-L113 opw-5386424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239697
This update resolves an issue where background images were stored as base64 data, negatively impacting website loading speed. The fix now uses the original image source, and a new process automatically corrects existing database entries. This improves website performance and user experience.
Original PR description
Since saas-18.4, body background images are saved as base64 in `body-image` instead of an URL. This affects the performance of the website. To reproduce: - Install Website - Open the website builder - go on the theme tab - website > background > choose an image - In the CSS file or in the style tab of the dev tools > `body-image` value is a base64 image To fix: Instead of directly giving the image source as the `body-image` value, we should give the `originalSrc` of the image element. To retro fix databases that would maybe have base64 backgrounds, a `normalizeBodyBackgroundImage` have been added to replace them with the correct URL. This function activates when the user opens the website builder.
This update resolves an issue that previously caused errors when processing invoices with reverse charge accounting (BIS3) in Japan. The fix ensures invoices are correctly generated and transmitted, improving the reliability of financial reporting. This change primarily impacts users relying on BIS3 invoice formats for international transactions.
Original PR description
opw-5419227 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240275
This update resolves a bug preventing users from adding products to invoices when navigating from an FSM task. The issue stemmed from differing context settings – specifically, the 'out_invoice' parameter – used when accessing invoices from a sale order versus a task. This change ensures consistent domain logic for product selection, allowing users to correctly add products to invoices regardless of the initial navigation path.
Original PR description
On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task Steps to reproduce:…
On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task Steps to reproduce: ------------------- * Create a product - Purchase: False - Sale : True * Create a fsm task * Add products * Go to the sale order * Create the invoice (regular invoice) * Go back to the task * Go to the invoice using the invoices smart button * Try to add your product -> issue it's not possible. Observation: --------------- The domain of the search is not the same if we go from the sale order or from the task. This is because the domain depend on the context and the context is not the same : [Domain](https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/views/account_move_views.xml#L1134-L1141) When using the smart button on the SO, some elements will be added to the context, the important one is: default_move_type : "out_invoice": [SO context](https://github.com/odoo/odoo/blob/18.0/addons/sale/models/sale_order.py#L1453) Instead when using it on the task, the context does not have that element: https://github.com/odoo/enterprise/blob/cb79d565031ee0e1bec9db82aa35deb2e1c03576/industry_fsm_sale/models/project_task.py#L325-L327 This will be calculate here in the js files: [evalContext](https://github.com/odoo/odoo/blob/c3367bd7c6900e42394b006ccf48c3b36a1b87e9/addons/web/static/src/views/fields/field.js#L400) opw-5135567 Forward-Port-Of: odoo/enterprise#101938 Forward-Port-Of: odoo/enterprise#98612
This update resolves an issue impacting Swiss payroll calculations, specifically related to overtime payments (ST-Overtime) and the LPP (Lohn- und Premodifizierungs-Pauschale) tax calculation. The fix ensures accurate and compliant payroll processing for Swiss businesses using the l10n_ch_hr_payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#102161
This update fixes an issue where currency rates for companies outside of UYU were incorrectly dated, leading to inaccurate tax calculations. The change ensures all currency rates are now synchronized with today's date, improving the accuracy of financial reporting for companies using currencies other than UYU.
Original PR description
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to…
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to properly do the conversions. ### Steps 1. Create a new Company with country Uruguay 2. Change current logged company to new Company 3. Change the currency to USD 4. Go to Settings, option Automatic Currency rate and configure provider yo [UY] Uruguayan Central Bank 5. Click manual synchronization 6. Check rates ### Current behavior before PR All currencies except UYU currency has created taxes with date today. Only one error in UYU currency that is created with yesterday rate  ### Desired behavior after PR is merged: All the currencies are created with the same date, the correct day that is today rate. References: LATAM 1341 / ADHOC Task 51716 Forward-Port-Of: odoo/enterprise#85065
This update resolves an issue where videos added to product descriptions in the e-commerce section would disappear after saving. The fix prevents the system from automatically clearing these descriptions based on a misinterpretation of the video's HTML structure. This ensures videos are consistently displayed for customers.
Original PR description
Versions
--------
- 18.0+
Steps
-----
1. Open website editor on a product page;
2. edit the ecommerce description;
3. add a video using the `/video` command;
4. save & close editor.
Issue
-----
The video disappears.
Cause
-----
The `write` override in `website_sale` uses the `is_html_empty` method to clear "empty" descriptions. When adding a video, it gets added as a `<div data-oe-expression="URL" class="media_iframe_video"></div>` element, i.e. an "empty" `div` element according to `is_html_empty`, hence getting cleared on write.
Solution
--------
In the `write` override, don't clear the ecommerce description if it contains "media_iframe_video".
Also, for 18.0, add `options="{'embedded_components': false}"` to the product view in the back-end to disable adding video there, as it gets formatted in a way that isn't supported by the front-end. For 18.2, this was already done in 6339f261e7161.
opw-5218018
Forward-Port-Of: odoo/odoo#240080