Search
Navigate
Branch
Thursday, March 13, 2025
67 changes
1 change
Resolved issues and error corrections
This update adds the missing permissions needed by the Turkish Nilvera e-invoice module to read journal information. It prevents related automated checks from failing and helps keep the localization module stable.
Original PR description
missing read access rights for account_journal to fix test build error build_error-111279
18 changes
New functionality added to Odoo
The Planning calendar now supports creating and deleting multiple schedule entries at once, especially in the month view. This helps teams manage larger planning changes faster and with fewer repetitive actions.
Original PR description
task-4510549
48 changes
Enhancements to existing features
Belgian accounting now supports partial VAT deduction, such as reclaiming only part of VAT on EU purchases like fuel or electricity. This helps businesses record VAT more accurately and stay aligned with Belgian tax requirements.
Original PR description
- Implemented support for partial VAT deduction (e.g., 35% reclaimable VAT on EU acquisitions like fuel or electricity). task-4575302
Enhancements to existing features
This update aligns several enterprise apps with a newer way of loading messaging session data. It mainly updates automated tests so accounting, knowledge, and Studio workflows continue to work reliably after the underlying loading process changes.
Original PR description
*: account_accountant, web_studio This is the counterpart of the community, this commit adapts tests to support the RPC /mail/data to the lasy_session_info RPC task-4341388
Field Service users can now see the add stage button directly in the Kanban view when working with a single Field Service project. This makes it easier to create new workflow stages from task and planning views without leaving the current screen.
Original PR description
Before this commit: The add stage button is not visible in the Kanban view of FSM, making it difficult for users to add new stages. This commit makes the add stage button visible in the FSM kanban view when a single FSM project exists, allowing users to add new stages directly from the kanban view. In the 'My Tasks' menu, it is visible when grouped by stage. Affected menus: - My Tasks: Tasks, Map - All Tasks: All Tasks, To Schedule, To Invoice - Planning: By User, By Project, By Worksheet Template, By Location task-4573727
Resolved issues and error corrections
The VoIP systray now honors a user's Do Not Disturb status before triggering ringtone behavior. This prevents unwanted call sounds when users have indicated they should not be interrupted.
Original PR description
Adapt the condition in VoIP systray item code so that it takes into account the Do Not Disturb (DND) status and doesn't play the ringtone when it shouldn't.
Miscellaneous changes
We support sending credit transfers using ISO 20022 to accommodate non SEPA bank transfers (any party having no IBAN number). However when generating the XML file, we assumed that our company always had an IBAN number and put it in an IBAN node. For non IBAN numbers however we need to put it in another node. This commit fixes that. [opw-4585994](https://www.odoo.com/odoo/project.task/4585994) Forward-Port-Of: odoo/enterprise#81102 Forward-Port-Of: odoo/enterprise#80757
Original PR description
We support sending credit transfers using ISO 20022 to accommodate non SEPA bank transfers (any party having no IBAN number). However when generating the XML file, we assumed that our company always had an IBAN number and put it in an IBAN node. For non IBAN numbers however we need to put it in another node. This commit fixes that. [opw-4585994](https://www.odoo.com/odoo/project.task/4585994) Forward-Port-Of: odoo/enterprise#81102 Forward-Port-Of: odoo/enterprise#80757
To reproduce: - create two repeating planning.slot records, Shift A and Shift B - delete Shift A and all of its repeats - delete only the last repeat of Shift B - run the "Planning: generate next recurring shifts" scheduled action - Cron fails with "record is missing or deleted" error Problem: The function to create the repeat shifts (planning.recurrency _repeat_slot) iterates over recurrences and deletes them if there are 0 existing shifts linked to them (i.e. Shift A's reccurency). On
Original PR description
To reproduce: - create two repeating planning.slot records, Shift A and Shift B - delete Shift A and all of its repeats - delete only the last repeat of Shift B - run the "Planning: generate next recurring shifts" scheduled action - Cron fails with "record is missing or deleted" error Problem: The function to create the repeat shifts (planning.recurrency _repeat_slot) iterates over recurrences and deletes them if there are 0 existing shifts linked to them (i.e. Shift A's reccurency). On a subsequent loop iteration, an attempt is made to access the company_id field of the recordset (self) which will now contain a deleted planning.recurrency record, causing the missing record error. Solution: Access the company_id field on the current iterated planning.recurrency record instead of the 'self' recordset. opw-4457844 X-original-commit: b3742b576e67f0391db0e5fcf138950c6275e770 Forward-Port-Of: odoo/enterprise#81301
Outgoing emails now contain more message IDs in references to help thread formation. This is notably due to parent_id being the first thread message, hence often technical, and this cause issues in multi odoo communications. This increases a bit query counters when sending emails. Indeed when preparing outgoing emails we now have to search for messages, and check for subtype details, which means additional queries. See community PR for more details. Task-4559249 Forward-Port-Of: odoo/e
Original PR description
Outgoing emails now contain more message IDs in references to help thread formation. This is notably due to parent_id being the first thread message, hence often technical, and this cause issues in multi odoo communications. This increases a bit query counters when sending emails. Indeed when preparing outgoing emails we now have to search for messages, and check for subtype details, which means additional queries. See community PR for more details. Task-4559249 Forward-Port-Of: odoo/enterprise#81104 Forward-Port-Of: odoo/enterprise#79048
In case of having two lines with the same product, the cfdi field `ValorUnitarioAduana` is wrong, it is set as the total of the two lines. With this commit, we set it as the average of the lines. Steps (with demo data, company `ESCUELA ...`): - Partner "Azure Interior" -> change `Tax ID` from `US12345677` to `123456779` - Product `[E-COM06]` -> - `UNSPC Catgegory`: `01010101` - `Tariff Fraction`: `0101290200` - `UMT Aduana`: `Units` - Make an invoice: - Currency: USD - Two lines for pro
Original PR description
In case of having two lines with the same product, the cfdi field `ValorUnitarioAduana` is wrong, it is set as the total of the two lines. With this commit, we set it as the average of the lines. Steps (with demo data, company `ESCUELA ...`): - Partner "Azure Interior" -> change `Tax ID` from `US12345677` to `123456779` - Product `[E-COM06]` -> - `UNSPC Catgegory`: `01010101` - `Tariff Fraction`: `0101290200` - `UMT Aduana`: `Units` - Make an invoice: - Currency: USD - Two lines for product `[E-COM06]` - Incoterm: `[EXW] EX WORKS` - External Trade: `Definitive` - Confirm and sent to cfdi -> Error opw-4596628 Forward-Port-Of: odoo/enterprise#81205 Forward-Port-Of: odoo/enterprise#80660
Before the PR: As could be experienced, the SII sometimes sends responses that are not encoded properly, or instead of responding with an XML, the response is an HTML instead. As a consequence of this, a bug was discovered in the response after uploading an AEC file (stands for electronic yielding file in Spanish). After the PR: We added a special parser method, that before transforming the response to a parsed XML, analyzes the encoding, and concludes in an html parsing and posting it to th
Original PR description
Before the PR: As could be experienced, the SII sometimes sends responses that are not encoded properly, or instead of responding with an XML, the response is an HTML instead. As a consequence of this, a bug was discovered in the response after uploading an AEC file (stands for electronic yielding file in Spanish). After the PR: We added a special parser method, that before transforming the response to a parsed XML, analyzes the encoding, and concludes in an html parsing and posting it to the chatter to inform the user. This is difficult to debug since the possible undocumented responses are not easy to reproduce in an SII test environment, so we applied this method only to a particular case, found in some situations for some users. Forward-Port-Of: odoo/enterprise#80002
When a receipt was generated on a german company the tss information where not displayed on it. Steps to reproduce: ------------------- * Set up fiskaly on german company * Make a sale on the PoS * Go to the receipt screen > Observation: No tss information is displayed opw-4581169 Forward-Port-Of: odoo/enterprise#81070
Original PR description
When a receipt was generated on a german company the tss information where not displayed on it. Steps to reproduce: ------------------- * Set up fiskaly on german company * Make a sale on the PoS * Go to the receipt screen > Observation: No tss information is displayed opw-4581169 Forward-Port-Of: odoo/enterprise#81070
### Issues: Creating and validating a picking from the barcode app does not behave correctly with respect to quality check trigger and creation. Depending on your flow, you might end up with QC created twice or with QC not being triggered before validation. ### Cause of the issues: The quality checks are created during the "_action_confirm" of moves: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15 However, d
Original PR description
### Issues: Creating and validating a picking from the barcode app does not behave correctly with respect to quality check trigger and creation. Depending on your flow, you might end up with QC…
### Issues:
Creating and validating a picking from the barcode app does not behave correctly with respect to quality check trigger and creation. Depending on your flow, you might end up with QC created twice or with QC not being triggered before validation.
### Cause of the issues:
The quality checks are created during the "_action_confirm" of moves: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15
However, depending on where you click in the barcode app, the moves might end up being assigned and hence skip the "_action_confirm" of the picking (which is computed to be assigned) prior to the `_pre_action_done_hook` of the `button_validate` of the picking wich is suppose to return already created quality check:
https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_picking.py#L1145-L1147
In which case, the quality check is not triggered (Issue 1). Furthermore, since the `_action_confirm` of moves can also be applied to extra moves created to update the demand and to be merged to the initial move during the validation, the quality check creation might be called twice on a move once during its own `action_confirm` and once during the `_action_confirm` of its extra move (Issue2).
### Issue 1:
1. Create a storable product P with a barcode: XXX
2. Go to Quality > Quality Control > Quality Points > New
3. Create a new quality point for your product:
- Control per: "Operation"
- Operations: "Receipts"
4. Go to the barcode app > Operations > Receipts > New
5. Scan your product
6. Click on the pencil (key step)
7. Either edit the quantity from the digipad and confirm or go back to the picking and edit it from there.
8. Validate the receipt
#### > Even thought a quality check was created using your quality point for your receipt, it was not triggered before validation.
### Cause of the Issue:
Clicking on the pencil will trigger a call of the `save_barcode_data` which will in turn create a stock move line related to the picking during the write performed on the picking:
https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/controllers/stock_barcode.py#L68-L74
After this edition of the quantity of the picking will write on the `qty_done` dummy field of that move line which will in turn trigger a call of its inverse method and modify its quantity: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/models/stock_move_line.py#L58-L61
Changing the quantity of the ml will then update the state of the move to "assigned" because of these lines:
https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L487-L488 https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L530-L531 https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_move.py#L2022-L2023 In turns, the state compute method of the picking will determine that the picking is assigned and the picking will not be confirmed during its `button_validate` prior to the `_pre_action_done_hook` of the `button_validate` as it is not in draft anymore.
### Fix:
The state of the move should stay as draft just as if we didn't created the move line through the pencil if we were to edit the qty_done via the barcode app.
### Note:
The inverse method of the "qty_done" computed field was introduced in 17.0+ by commit: 4f19668c51a90e8c12e57b6353bbe5194f83ca10 during the quantity refactoring so that the issue is not reproducible prior to that version.
### Issue 2:
Same steps 1 -> 5.
6'. click on the +1 button.
7'. Validate > this opens the quality check
8'. Pass the quality check > Validate again
9'. Go to Quality > Quality Control > Quality check
#### > Two quality checks were created isntead of one for your receipt
### Cause of the issue:
At some later point in the button validate of the picking, an `_action_done` is called to put the pickings and its move in done state: https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_picking.py#L1157
However, during the `_action_done` of the moves if the quantity of the move exceeds its `product_uom_qty`, extra moves will be created, confirmed and merged back to the move in order to update its `product_uom_qty`:
https://github.com/odoo/odoo/blob/607d63fd4d9c07bac9cb68b2d31d86551e93d5b1/addons/stock/models/stock_move.py#L1885-L1890 https://github.com/odoo/odoo/blob/607d63fd4d9c07bac9cb68b2d31d86551e93d5b1/addons/stock/models/stock_move.py#L1823-L1832 However, the action confirm of this extra move will trigger the same override of the `_action_confirm` that creates a quality check and it will even be called on the original move that was already confirmed and already created its QC since the extra move was merged into it: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15
As a result we end up with an extra quality check creation.
### Fix:
We avoid quality check creation during extra move confirmation.
Community: https://github.com/odoo/odoo/pull/192034
opw-4266053
---
Forward-Port-Of: odoo/enterprise#80244
Forward-Port-Of: odoo/enterprise#76301Enterprise counter-part. task-4637944 https://github.com/odoo/odoo/pull/201228 Forward-Port-Of: odoo/enterprise#81279 Forward-Port-Of: odoo/enterprise#81177
Original PR description
Enterprise counter-part. task-4637944 https://github.com/odoo/odoo/pull/201228 Forward-Port-Of: odoo/enterprise#81279 Forward-Port-Of: odoo/enterprise#81177
A potential access right issue appears in the case a simple HR user accessed the employee view without payroll rights since source-tax mutations are restricted to payroll users. opw-4607112 Forward-Port-Of: odoo/enterprise#81200
Original PR description
A potential access right issue appears in the case a simple HR user accessed the employee view without payroll rights since source-tax mutations are restricted to payroll users. opw-4607112 Forward-Port-Of: odoo/enterprise#81200
Ensure that the correct fiscal position is used in `test_generate_ec_sales_list_activity`. Previously, the search for a fiscal position did not filter by the company where the invoice was created. As a result, it returned the latest "Intra-Community" fiscal position in the database for the allowed companies, potentially leading to incorrect assignments. This commit adds a call to `_check_company_domain` in the search domain, ensuring that the fiscal position is correctly retrieved for the
Original PR description
Ensure that the correct fiscal position is used in `test_generate_ec_sales_list_activity`. Previously, the search for a fiscal position did not filter by the company where the invoice was created. As a result, it returned the latest "Intra-Community" fiscal position in the database for the allowed companies, potentially leading to incorrect assignments. This commit adds a call to `_check_company_domain` in the search domain, ensuring that the fiscal position is correctly retrieved for the intended company. Bug introduced by: https://github.com/odoo/enterprise/commit/d684d074af82fbd0fac6b3a1c56b4e01a17dd74a runbot-145700 Forward-Port-Of: odoo/enterprise#81260
### Steps to reproduce: - install l10n_ec_edi_pos - Create a new POS in the EC Company. - With a use without inventory adminstrator access rights: - Open a pos session, select any product and a custome linked to the EC localisation. - Try to validate the POS order that is invoiced using the cash payment method. #### > An access error is raised with respect to the `stock_valuation_layer_ids` fields of the account.move model ### Cause of the issue: Clicking on validate will launch a
Original PR description
### Steps to reproduce: - install l10n_ec_edi_pos - Create a new POS in the EC Company. - With a use without inventory adminstrator access rights: - Open a pos session, select any product and a…
### Steps to reproduce: - install l10n_ec_edi_pos - Create a new POS in the EC Company. - With a use without inventory adminstrator access rights: - Open a pos session, select any product and a custome linked to the EC localisation. - Try to validate the POS order that is invoiced using the cash payment method. #### > An access error is raised with respect to the `stock_valuation_layer_ids` fields of the account.move model ### Cause of the issue: Clicking on validate will launch a call of the `syncAllOrders` method. During this call, missing records will be fetched recursisvely here: https://github.com/odoo/odoo/blob/2108ad3f7c851eeceb84d7459485a18e1574fa64/addons/point_of_sale/static/src/app/store/pos_store.js#L1271 (Note that this call does not exist prior to 18.0). However, as the data contains a pos order that is related to account moves and since the `account.move` model of the localisation inherit from the `pos.load.mixin`: https://github.com/odoo/enterprise/blob/efa1853cf1f9bbd945a91971ffe40c6906482063/l10n_ec_edi_pos/models/account_move.py#L6-L8 the account move will be fetched as a related record to the pos order and we will launch a `read` for the `fields=[]`: https://github.com/odoo/odoo/blob/2108ad3f7c851eeceb84d7459485a18e1574fa64/addons/point_of_sale/static/src/app/models/data_service.js#L513-L515 https://github.com/odoo/odoo/blob/2108ad3f7c851eeceb84d7459485a18e1574fa64/addons/point_of_sale/models/pos_load_mixin.py#L9-L11 However, a read performed with a false value in the `fields` tries to read the value of each field on the records: https://github.com/odoo/odoo/blob/2108ad3f7c851eeceb84d7459485a18e1574fa64/odoo/models.py#L3792-L3798 This includes protected fields such as the `stock_valuation_layer_ids` that can only be read by user's with administrator stock access rights. opw-4498024 Forward-Port-Of: odoo/enterprise#80156
In this commit: === - Integrated Rappi as a provider in pos_urban_piper. task-4632154 Forward-Port-Of: odoo/enterprise#80923
Original PR description
In this commit: === - Integrated Rappi as a provider in pos_urban_piper. task-4632154 Forward-Port-Of: odoo/enterprise#80923
Create a new module to export payroll data for Acerta. **NOTE during fw port I need to move the test for the other ss to the main test module** task-3750799 Forward-Port-Of: odoo/enterprise#71683
Original PR description
Create a new module to export payroll data for Acerta. **NOTE during fw port I need to move the test for the other ss to the main test module** task-3750799 Forward-Port-Of: odoo/enterprise#71683
Forward-Port-Of: odoo/enterprise#81135
Original PR description
Forward-Port-Of: odoo/enterprise#81135
South African customer invoice reports now display “Tax Invoice” when the company is VAT registered, helping meet local business payment and compliance expectations. The update also handles companies without a VAT number so their invoice wording remains appropriate.
Original PR description
In South Africa, many companies require that 'Tax Invoice' appears on any invoice they will pay if you are VAT registered. I took inspiration from the Zambian localisation, I just added a case for when you are not VAT registered (i.e. don't have a VAT number set). I'll create a separate PR for 16.0 since the invoice report layout changed in 18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Belgian reports module no longer shows VAT report banners for warnings, reducing unnecessary alerts for users. Rejection banners remain in place so important blocking issues are still clearly communicated.
Original PR description
- Removed VAT report banners for warnings but kept rejection banners. task-4575302
The Estonia reporting module now supports the new 13% VAT rate that applies from January 1, 2025. This helps Estonian businesses keep tax reporting and VAT XML exports aligned with upcoming legal requirements.
Original PR description
This adds 13% tax logic to Estonia Localization and VAT tax report. 13% is valid from 01.01.2025 Also in vat xml t-out is used for values true and false as otherwise these are translated during rendering.
Resolved issues and error corrections
This update corrects a styling rule in the Spreadsheet app so the interface displays as intended. It is a small visual fix that helps keep the spreadsheet experience consistent for users.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale interface no longer shows prices on every product card in the main product screen. Prices are now shown only when selecting items within a combo, reducing clutter and keeping the checkout view consistent.
Original PR description
- Fix issue where the price was displayed on every product card (like in product screen). To fix this we want to only display the price of the card in combo choice. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents blank certificate or key error messages from appearing when records are created directly in the database. Users will only see a loading error when there is an actual message to show, reducing confusion in certificate management screens.
Original PR description
Problem --------- When the certificate or the key is created through SQL INSERT, the compute functions are not triggered. This lead to the 'loading_error' field to remain FALSE. Since the condition that checked whether or not to display the loading error message was "loading_error == ''", it meant that the message would be display when it was equal to FALSE. Instead, we now just check if there is a loading error message with 'not loading_error' which solves the issue and makes it more robust. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes an internal landed costs test check records in a consistent order. It helps prevent false test failures, improving confidence in the inventory costing validation process without changing user-facing behavior.
Original PR description
This commit orders the stock valuation layer of multiple stock moves by product to make sure the assert targets the right layer index in the loop. runbot: 99086 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures overtime hours that have not yet been validated are calculated correctly when processing multiple attendance records at once. It prevents an error that could interrupt attendance or overtime reporting, helping HR teams get complete results.
Original PR description
Steps: - Compute no_validated_overtime_hours for many records Actual result: - Singleton expected Expected result: - Compute is done for all records
The signup reminder process now sends pending emails without repeatedly processing the same users. This prevents duplicate or endless reminder emails when there are more than 100 unregistered users, improving reliability for customer communications.
Original PR description
When we have more than 100 users, we send e-mails in an endless loop because we always process the same records. After this change, we send all e-mails in one call. Backport of odoo/odoo#199091 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Etisalat email addresses ending in @eim.ae are now treated like common personal email providers. This prevents CRM from incorrectly grouping unrelated leads just because they share this widely used email domain.
Original PR description
The email domain eim.ae is associated with Etisalat, a major telecommunications provider in the United Arab Emirates. Addresses ending with @eim.ae are commonly used by individuals and businesses in the UAE, similar to how @gmail.com addresses are used globally. That's why we should not use it for detect it similar leads. Reproduce --- - Install crm - Create a lead - Add email with @eim.ae as domain - BUG: Similar lead identified based on the email domain opw-4506179
This fixes an issue where split or wave-based delivery transfers from the same sales order could receive different scheduled dates. After the change, copied transfers keep the intended sales order delivery date, helping warehouse teams plan shipments accurately.
Original PR description
- Activate wave transfers and group by product or any other, easy to see it by product. - Create a sales order with two different products in the sales order lines - Changed the delivery date in the other info tab. - When confirming the sales order, two transfers will be created, each will have one product. Current behavior: - One picking will respect the scheduled date and the other one will have it for today. Expected: - Both picking have the sale order schedule date. It happens because the picking copy miss some data opw-4571808 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents call events from being handled before the related call session is ready. It reduces the risk of intermittent audio or video issues caused by timing differences between network and server updates.
Original PR description
Before this commit, we could get events for a RtcSession that is not yet available. This can happen when network information (SFU/p2p) races Odoo server information (bus). As RtcSessions' source of truth is the Odoo server, information obtained from the call network are only acknowledged if we have the record from Odoo. This commit fixes this issue by awaiting sessions for which events are obtained. Fetching should not be necessary as: - if the event is for a session that exists, the client will eventually obtain it (from the bus message that is sent when a new is created, or by the `rtc_service.ping()` which periodically fetches sessions). - if the event is for a session that does not exist, fetching does not make sense.
This update fixes several automated guided checks so they wait for pages and forms to be ready before continuing. This reduces false failures in testing for website editing, online sales localization, inventory flows, and point-of-sale restaurant loyalty scenarios, helping teams validate changes more consistently.
Original PR description
- addons/l10n_br_website_sale/static/tests/tours/brazilian_address.js We need to wait the form is loaded before to modify address to prevent js failures. -…
- addons/l10n_br_website_sale/static/tests/tours/brazilian_address.js We need to wait the form is loaded before to modify address to prevent js failures. - addons/stock/static/tests/tours/stock_picking_tour.js We prefer to use more precise trigger instead of run with console.error(). As it's the last step, it's more efficient. - addons/website/static/tests/tours/client_action_redirect.js When we exit edit mode in website, we must wait the dom is stable to continue. - addons/website/tests/test_ui.py Add a step_delay to ensure tour works each time (undeterminisms) - addons/web_tour/static/src/tour_service/tour_helpers.js Harmonize usage of async / await. Wait the dom is stable before to click on a link. - addons/web_tour/static/src/tour_service/tour_automatic.js Set a large timeout when step is paused. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how custom text background colors appear in the HTML editor, especially in dark mode. Custom solid background colors now use partial opacity so highlighted text remains easier to read, while theme colors keep their existing behavior.
Original PR description
### Description of the issue/feature this PR addresses: - Applying a background color to text caused visibility issues in dark mode. ### Current behavior before PR: - 60% opacity is applied to background colors in the solid tab, except for theme colors. task-4566382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The web editor now removes hidden placeholder characters from emptied inline required fields before saving. This prevents fields that look empty to users from being incorrectly treated as filled, improving data accuracy.
Original PR description
### Description of the issue/feature this PR addresses: - Block elements: When emptied, a `<br>` is added. - Inline elements: Instead of a `<br>`, a zero-width space (ZWS) is inserted. This makes the field non-empty. ### Desired behavior after PR is merged: - Fields marked with `data-oe-zws-empty-inline` are cleaned by removing the zero-width space in cleanForSave, preventing non-empty fields from being saved. task-4575400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Inventory users with standard access can once again view and edit serial numbers without running into an access error. The change removes valuation details from the serial number form where those users do not have permission, preventing unnecessary disruption to daily inventory work.
Original PR description
steps to reproduce the bug: - install inventory and invoicing app - change the user access right of the inventory app to `User` - access any of the serial number you have in any of the apps having it Problem: Error is raised because no access right for the `stock.valuation.layer` model to the user group. new attribute `stock_valuation_layer_ids` was added to the `stock.lot`model on the stock_account module, and hence no access right for that model for the user group so now anyone with user access to inventory app won't be able to access the serial numbers or edit them opw-4466042 opw-4551745 Description of the issue/feature this PR addresses: Current behavior before PR: users with `user access right to inventory app` can't access the serial numbers Desired behavior after PR is merged: users with `user access right to inventory app` can access the serial numbers --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The shared spreadsheet view now consistently hides the download option when there is no pre-generated spreadsheet file to download. This avoids showing users an action that cannot work and keeps the sharing interface clearer.
Original PR description
### Description: In PR #192349, we hide the download button in the live shared spreadsheet, but it remained visible in the topbar menu. This commit ensures the button is also hidden in the topbar menu when no pre-generated spreadsheet is available. Task: 4625077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale screen no longer shows unintended product prices directly on product cards, restoring the expected product browsing experience. Combo product pricing has also been clarified so extra charges are displayed more appropriately during configuration.
Original PR description
Since commit 5a26402d33570dd6ad18be122aac74bfe8397445, product prices have been unintentionally displayed on product cards. This commit fixes that issue by hiding the unintended price display. Additionally, it improves how extra prices are shown on combo products, Task: 4644777
The Brazil AvaTax product form now keeps the relevant tax information section visible for service products. This ensures users can access the correct service-related fields instead of having the whole section hidden by mistake.
Original PR description
Small oversight in odoo/enterprise#79245. Don't hide the entire group for service products. Visibility for goods/service products is determined per field below. opw-4601199
Fixed an issue where notes added to trial balance accounts could disappear when account hierarchy and subtotals were enabled. This helps finance users reliably save and review annotations while working with grouped account reports.
Original PR description
Steps to reproduce: - open the trial balance with a company having some account groups (like BE company) - activate the hierarchy and subtotals filter - create an annotation for an account - press outside the popover to save the annotation - open the annotation popover -> The annotation is no longer visible Other similar issue - create an annotation (with again hierarchy activated) - directly create another one -> The popover disappear and no annotations are visible Cause of the issue: When grouping per hierarchy, the line ids contains some unnecessary components for these grouping per account groups, which need to be filtered out with the helper function already created to handle this case. opw-4546653
This fix prevents Sendcloud delivery processing from failing when a sales order includes a deposit line without a product. It helps sales teams continue using deposits on orders without disrupting shipping service calculations or order handling.
Original PR description
Fixed error when a deposit is set on sale order line because not product on line and not display_type.
Read-only users can now open payment records without errors caused by hidden direct debit mandate details. The mandate-related fields are limited to invoicing users, matching existing access rules and reducing disruption for users who only need to view payments.
Original PR description
Before this PR: - The SDD Mandate model was accessible only to invoicing users. - As a result, read-only users could not view payment records because some fields attempted to access the SDD Mandate model. After this PR: - Fields related to the SDD Mandate model are now restricted to invoicing users using the appropriate access groups. - This ensures that read-only users can view payment records without encountering access issues.
Mexican electronic invoices can now be printed even when the customer has no language set. The amount written in words uses the customer language when available, or the current user language otherwise, avoiding errors caused by an unavailable Spanish fallback.
Original PR description
When printing an invoice in the l10n_mx_edi module, a traceback occurs if the client's language is empty. This happens because the system previously defaulted to es_ES, which may not be activated. Steps to Reproduce: 1. Install the l10n_mx_edi module and switch to a Mexican company. 2. Enable multiple languages in the system. 3. Create an invoice and leave the customer's language empty (no language set). 4. Print the invoice. 5. Issue: A traceback occurs due to the missing es_ES language. Now, there is no fallback to es_ES when the client's language is empty. The amount-to-text conversion strictly relies on `self.partner_id.lang. If no language is set, the conversion translates to the user's language. opw-4572245
Barcode inventory adjustments now ignore customer, vendor, and other non-internal locations when choosing a default product location. This helps prevent stock corrections from being recorded in the wrong place unless a user explicitly scans that external location first.
Original PR description
Steps to Reproduce: 1. Create a storable product with inventory tracking and assign a barcode. 2. Create an internal transfer from “Partners/Customers” to “Virtual Locations/Inventory Adjustment”. 3.…
Steps to Reproduce: 1. Create a storable product with inventory tracking and assign a barcode. 2. Create an internal transfer from “Partners/Customers” to “Virtual Locations/Inventory Adjustment”. 3. This will generate two quants, one in Customers and another in Inventory Adjustment. 4. Navigate to Barcode > Inventory Adjustment and scan the product’s barcode. Issue: The scan triggers an inventory adjustment for the “Customer” location instead of the correct stock location. Technical Explanation: • The system fetches all quants related to the product, including those in Vendor, Customer, and Inventory Adjustment locations. • These locations have IDs lower than the stock location (e.g., Customers = 5, Stock = 8). • The front-end caches this data (dbIdCache) and calls _defaultLocation() to determine the location. • Since the cache is ordered by ID, the first location (Customers, ID 5) is incorrectly selected instead of the stock location (8). • As a result, the inventory adjustment is applied to the wrong location. Proposed Fix: • Filter the results to include only internal locations when fetching quants. • This prevents non-internal locations (Vendor, Customers, Inventory Adjustment) from being selected by default. • If a user needs to adjust inventory for an external location, they must first scan the location barcode before scanning the product. Task-4596699
This fix ensures upsell activity line text in Sales Subscriptions is translated correctly for users in different languages. It addresses a small localization issue so customer-facing and workflow information appears consistently in the user’s selected language.
Original PR description
Translation tool `_` does not work inside a generator, but new tool* based on the environment (`env._`) does. This commit fixes the issue in upsell activity lines. *https://github.com/odoo/odoo/commit/b794f0f332f473deb2c04eba60baf4761db3b508
Discarding a newly started timesheet entry from an existing timesheet record no longer triggers an error. This makes the Timesheets workflow more reliable for users who start an entry and then decide not to save it.
Original PR description
**Issue:** An error is raised when trying to discard a timesheet entry. **Steps to reproduce:** - Open Timesheets. - Open an existing entry by clicking on the magnifying glass. - Start a timesheet entry by clicking "Start". - Click on "Discard". opw-4614472
Users can now create a new quote calculator from quotation template settings without seeing a missing name error. New calculators are automatically labeled “New Spreadsheet” at first, so teams can proceed smoothly and rename them later if needed.
Original PR description
Steps: - Sales app > Configuration > Quotation Templates. - Create a New template. - In field 'Quote calculator' select 'search more..' - select 'New' button Issue: - New button throws validation error says missing required field 'name', blocking creation. Cause: - default value was not assigned to required field 'name' in respective model. Fix: - Added a default value for 'name' field, so creating a new quote calculator will initially be labeled as 'New Spreadsheet' and can be renamed as needed. opw-4552429
Corrects how discounted invoice amounts are rounded for Mexican electronic invoicing so totals match the sum of line discounts. This prevents valid invoices with certain discount combinations from being rejected during CFDI validation.
Original PR description
Steps to reproduce: - Create an invoice with the following lines: 1. Price Unit 3163.79 | Qty 1 | Discount 25% | Tax 16% 2. Price Unit 2992.41 | Qty 1 | Discount 25% | Tax 16% 3. Price Unit 3025.86 | Qty 1 | Discount 25% | Tax 16% - Confirm, Send to validation Issue: Validation will fail with error ``` Message : Error de validaciones adicionales [Error #CFDI40111] El TipoDeComprobante no es I,E o N, y un concepto incluye el campo descuento. Folio: 1. Serie: INV/2025/. El valor del atributo Descuento (2295.51) no coincide con la suma de los importes (790.947500 + 748.090000 + 756.465000 = 2295.50) ``` This occurs because when correcting the discount rounding we round the biggest discount amount so the amounts might not add up correctly anymore opw-4596741
Code cleanup and technical improvements
This change updates Odoo's web tour testing support to ignore a specific asset-loading failure when appropriate. It helps reduce unnecessary test interruptions from this known issue, improving reliability for internal validation without changing day-to-day user workflows.
Original PR description
In this commit, we skip AssetsLoadingError
Documentation and clarification updates
This pull request adds an individual Contributor License Agreement signature for the contributor Corbiezorq. It supports Odoo's legal contribution process and does not change product functionality or user workflows.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update records LABISO GmbH's corporate contributor license agreement and listed contributors. It helps Odoo maintain clear legal permission to include contributions from this company in the project.
Original PR description
This pull request includes an update to the `doc/cla/corporate/labiso.md` file. The change adds a new corporate contributor license agreement for LABISO GmbH, including the list of contributors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request records the contributor's signed CLA and includes early draft work for real estate and Telegram notification add-ons. For the business, the legal confirmation is the key actionable change, while the added modules appear to be preliminary and may need review before any product impact.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A contributor has added their individual Contributor License Agreement record. This supports Odoo's legal contribution process and helps ensure contributions can be accepted under the project's licensing requirements.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
To reproduce: ============= - create a contact with customer location : Partners/Customer/test - enable 2 steps delivery on warehouse - create SO for the contact and confirm it - validate first step of delivery - check second step of delivery -> the destination location is Partners/Customer instead of Partners/Customer/test Problem: ======== Now that we are creating moves step by step we are not passing the destination location to the second move and using the one set on the rule.
Original PR description
To reproduce: ============= - create a contact with customer location : Partners/Customer/test - enable 2 steps delivery on warehouse - create SO for the contact and confirm it - validate first step of delivery - check second step of delivery -> the destination location is Partners/Customer instead of Partners/Customer/test Problem: ======== Now that we are creating moves step by step we are not passing the destination location to the second move and using the one set on the rule. Solution: ========= when creating second move and it's last step we set destination to final destination location. opw-4374075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199278
Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems. First, if there was an onchange on that field, the onchange was triggered multiple times with the same forget command, especially on a slow-ish network. Second, there could be a crash, but to reproduce it the timing had to be precise: backspace should have been pressed when a previous tag deletion was al
Original PR description
Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems. First, if…
Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems. First, if there was an onchange on that field, the onchange was triggered multiple times with the same forget command, especially on a slow-ish network. Second, there could be a crash, but to reproduce it the timing had to be precise: backspace should have been pressed when a previous tag deletion was already processed by the model (i.e. the tag is no longer in the list), but the DOM wasn't updated yet. This could be done more easily then it sounds, by quickly pressing backspace on a many2many_tags with a lot of tags. The related opw is about the second issue, as the first one isn't obversable functionally. However, testing the second one is really tricky, even impossible without going white-box. We thus wrote a test for the first issue only, as the fix for both is actually the same. opw-4596936 Forward-Port-Of: odoo/odoo#201233 Forward-Port-Of: odoo/odoo#201164
Before this commit, a traceback is occurred when the user would like to see the raw data of a specific project and the project stage feature is disabled. This commit adds a group on `duration_tracking` field definition to be sure this field will only be computed when the project stage feature is enabled. opw-3709542 Closes #197321 Forward-Port-Of: odoo/odoo#201313
Original PR description
Before this commit, a traceback is occurred when the user would like to see the raw data of a specific project and the project stage feature is disabled. This commit adds a group on `duration_tracking` field definition to be sure this field will only be computed when the project stage feature is enabled. opw-3709542 Closes #197321 Forward-Port-Of: odoo/odoo#201313
Live chat sessions are accessible to live chat managers so they should be able to join or invite anyone to said session. task-4637836 https://github.com/odoo/upgrade/pull/7372 Forward-Port-Of: odoo/odoo#201395 Forward-Port-Of: odoo/odoo#201321
Original PR description
Live chat sessions are accessible to live chat managers so they should be able to join or invite anyone to said session. task-4637836 https://github.com/odoo/upgrade/pull/7372 Forward-Port-Of: odoo/odoo#201395 Forward-Port-Of: odoo/odoo#201321
This fix aims to improve the user experience on mobile by removing useless tooltips on the chatter. Since the user usually does not have a keyboard on the mobile, we do not show the keybind tooltip when the screen is small task-4633869 Forward-Port-Of: odoo/odoo#201271 Forward-Port-Of: odoo/odoo#200961
Original PR description
This fix aims to improve the user experience on mobile by removing useless tooltips on the chatter. Since the user usually does not have a keyboard on the mobile, we do not show the keybind tooltip when the screen is small task-4633869 Forward-Port-Of: odoo/odoo#201271 Forward-Port-Of: odoo/odoo#200961
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200244 Forward-Port-Of: odoo/odoo#198760
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200244 Forward-Port-Of: odoo/odoo#198760
*: portal, website, web_editor Enhance user experience by resolving UI inconsistencies and ensuring readability and contrast between the dropdown active / hover states and their inner text. **Global** - Updated hover effects to use `body-tertiary-bg` instead of `gray-100`, aligning with Bootstrap 5.3's styling approach. - Added color-contrast function's variables to allow easier use in `bootstrap_overridden_frontend` **Dropdowns** - Adjusted active state colors to prevent conflicts
Original PR description
*: portal, website, web_editor Enhance user experience by resolving UI inconsistencies and ensuring readability and contrast between the dropdown active / hover states and their inner text.…
*: portal, website, web_editor Enhance user experience by resolving UI inconsistencies and ensuring readability and contrast between the dropdown active / hover states and their inner text. **Global** - Updated hover effects to use `body-tertiary-bg` instead of `gray-100`, aligning with Bootstrap 5.3's styling approach. - Added color-contrast function's variables to allow easier use in `bootstrap_overridden_frontend` **Dropdowns** - Adjusted active state colors to prevent conflicts between the primary active color and dropdown item text color. - Differentiate two active states: - Active menu entries (current page) ➡️ Primary color - Active feedback on click ➡️ color-contrast of background color - Updated the `o_extra_menu_items` dropdown to adapt the borders to the user theme settings, removing the hardcoded `gray-200` value. **Search & Misc** - Replaced `-webkit-search-cancel-button` with Bootstrap's `btn-close` design introducing a mixin for contextual color adjustments to match the input color. - Changed portal search input type from `text` to `search` ensuring proper styling and semantic. task-3969685 | Before | After | | --- | --- | |  |  | | |  | |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170922
Before this PR, a request was sent for each character typed inside the search of the invite to the channel panel. This PR introduces a debounce to avoid spamming the server with useless requests. Part of Task-4637517 Forward-Port-Of: odoo/odoo#201373
Original PR description
Before this PR, a request was sent for each character typed inside the search of the invite to the channel panel. This PR introduces a debounce to avoid spamming the server with useless requests. Part of Task-4637517 Forward-Port-Of: odoo/odoo#201373
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201246 Forward-Port-Of: odoo/odoo#200033
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201246 Forward-Port-Of: odoo/odoo#200033
Use case: When sending stock ewaybill with no taxes at that time government API is expecting the taxes values as `0`. Issue: When there is no tax applied we get an empty list due to which it doesn't set the default taxes to `0` Fix: We make sure if there no taxes then return a default taxes as `0` opw-4639009 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201118
Original PR description
Use case: When sending stock ewaybill with no taxes at that time government API is expecting the taxes values as `0`. Issue: When there is no tax applied we get an empty list due to which it doesn't set the default taxes to `0` Fix: We make sure if there no taxes then return a default taxes as `0` opw-4639009 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201118
Steps to reproduce the issue: 1. Activate the Odoo Mexican Localization Reports module 2. In a Mexican company, create a new Account with 1 as code 3. Go to Trial Balance and download COA SAT (XML) 5. In the General Settings with developer mode active, Download XSD files 6. Go to Trial Balance and download COA SAT (XML) again 7. You get a UserError with an unclear message Explanation: The Mexican Chart of Accounts have clear rules regarding `account.account.code`. The only way to v
Original PR description
Steps to reproduce the issue: 1. Activate the Odoo Mexican Localization Reports module 2. In a Mexican company, create a new Account with 1 as code 3. Go to Trial Balance and download COA SAT (XML)…
Steps to reproduce the issue: 1. Activate the Odoo Mexican Localization Reports module 2. In a Mexican company, create a new Account with 1 as code 3. Go to Trial Balance and download COA SAT (XML) 5. In the General Settings with developer mode active, Download XSD files 6. Go to Trial Balance and download COA SAT (XML) again 7. You get a UserError with an unclear message Explanation: The Mexican Chart of Accounts have clear rules regarding `account.account.code`. The only way to verify those accounts is through the XSD files check, but they are not automatically downloaded and the error received with those files downloaded is not user friendly. Fix reasoning: Instead of regulating the code when downloading the XML. We'll add warnings on the Chart of Accounts to notify the user when a code is incorrect. To make the report error clearer to the user, we added a RedirectWarning that displays the accounts with faulty codes before generating the xml. opw-4287338 Forward-Port-Of: odoo/enterprise#81111 Forward-Port-Of: odoo/enterprise#73943
The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO). Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place. This
Original PR description
The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO). Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place. This revision changes the flow by simply re-instanciating a new `Model` every time we change the target revision. Task-4506832 Forward-Port-Of: odoo/enterprise#80680 Forward-Port-Of: odoo/enterprise#77667
Before this commit a translated mail layout's header would be (e.g. in Dutch) 'Je signature'. After this commit, the model's description is translated (e.g. in Dutch) to 'Je Handtekening'. This replicates the same behavior as the _send_signature_access_mail() method. Impacted versions: 16.0, 17.0 and 18.0 Forward-Port-Of: odoo/enterprise#79575 Forward-Port-Of: odoo/enterprise#77948
Original PR description
Before this commit a translated mail layout's header would be (e.g. in Dutch) 'Je signature'. After this commit, the model's description is translated (e.g. in Dutch) to 'Je Handtekening'. This replicates the same behavior as the _send_signature_access_mail() method. Impacted versions: 16.0, 17.0 and 18.0 Forward-Port-Of: odoo/enterprise#79575 Forward-Port-Of: odoo/enterprise#77948
A potential access right issue appears in the case a simple HR user accessed the employee view without payroll rights since source-tax mutations are restricted to payroll users. opw-4607112 Forward-Port-Of: odoo/enterprise#81200
Original PR description
A potential access right issue appears in the case a simple HR user accessed the employee view without payroll rights since source-tax mutations are restricted to payroll users. opw-4607112 Forward-Port-Of: odoo/enterprise#81200