Thursday, March 13, 2025
55 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
16 changes
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
38 changes
Enhancements to existing features
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
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
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
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
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 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
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
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.
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
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