Daily updates from Odoo
Navigate
Branch
Wednesday, May 7, 2025
68 changes
18 changes
Enhancements to existing features
VoIP contact searches now keep numbers in partner names instead of replacing them with placeholder characters. This makes it possible to find contacts or companies whose names include digits when using T9-style phone keypad search.
Original PR description
Prior to this commit, digits in a partner name would be converted to an x, preventing you from searching for digits in a T9 name search. After this commit, the digits remain as they are, so they can be searched for in a T9 name search.
The VoIP softphone now includes a keypad during active calls, allowing users to enter numbers when navigating automated phone menus. The keypad styling has also been adjusted so it remains clear and usable while calls are pending.
Original PR description
part of task-4642428
Resolved issues and error corrections
Users can now rearrange apps on the home screen and see the new order immediately. This removes the need to refresh the page, making personalization feel smoother and more reliable.
Original PR description
### Before this commit: - Dragging and dropping apps on the home screen did not reflect their new order until the page was refreshed. ### After this commit: - The home screen immediately displays the updated app order after a drag-and-drop, without requiring a page reload. Task: 4664362
Miscellaneous changes
If you have a company A that has a journal set up with bank synchronization, and a company B that is a branch of company A, you have access to the journal and the bank synchronization (account.online.link) of company A in company B. This causes an issue when fetching the transactions from the context of company B, as that will create the fetched transactions with a `company_id` set to B, which will cascade on the journal entries and items linked to these transactions. To ensure the correct
Original PR description
If you have a company A that has a journal set up with bank synchronization, and a company B that is a branch of company A, you have access to the journal and the bank synchronization…
If you have a company A that has a journal set up with bank synchronization, and a company B that is a branch of company A, you have access to the journal and the bank synchronization (account.online.link) of company A in company B. This causes an issue when fetching the transactions from the context of company B, as that will create the fetched transactions with a `company_id` set to B, which will cascade on the journal entries and items linked to these transactions. To ensure the correct company is set on the transactions, we force the company in the context when creating them. As a result: - When only company A is selected, transactions are correctly created in company A. - When both company are selected, no matter if the transactions are fetched from A or B, the transactions are correctly created in company A. - When only company B is selected, the user is faced with an access error, as Odoo is trying to open a view with the fecthed transaction, which belong to company A. To prevent this access error, it was decided that the "Fetch Transaction" buttons should not appear when the company owning the bank synchronization is not selected. A new computed field was then introduced on the account.online.account to check if we should allow fetching given the currenctly selected companies. That field is also added on the account.online.link as a logical conjunction of its account.online.account values of the field. These fields are then used to decide whether if we show the transaction fetching buttons on the dashboard and on the online link form view. Another issue with branches is the 'connect bank' button. With the same configuration as above, let's have companies A and B enabled, with B as the selected company. If you connect a bank to a journal belonging to company A by clicking on the 'connect bank' button on the dashboard, it will successfully connect, but the account.online.link will belong to company B. Then, if you try to access the accounting dashboard with only company A enabled, you will be faced with an access error, as the journal from company A tries to diplay informations computed with the above account.online.link of company B. To prevent this, we only make the 'connect bank' button appear if company A (i.e. the company owning the journal) is selected as the active company. This did not require a new field, and was done by adding an entry in the dashboard data. opw-4515862 Forward-Port-Of: odoo/enterprise#84694 Forward-Port-Of: odoo/enterprise#83134
Currently it's possible for a timesheet user to set and write the project to False in the timesheet list view. The UI will say the project is missing but the analytic line is changed anyway. This PR add check that the project is set before writing to the analytic line record. opw-4649817 Forward-Port-Of: odoo/enterprise#84636 Forward-Port-Of: odoo/enterprise#83420
Original PR description
Currently it's possible for a timesheet user to set and write the project to False in the timesheet list view. The UI will say the project is missing but the analytic line is changed anyway. This PR add check that the project is set before writing to the analytic line record. opw-4649817 Forward-Port-Of: odoo/enterprise#84636 Forward-Port-Of: odoo/enterprise#83420
The error occurred because multiple `iap.extracted.words` records matched the search filter for `user_selected_box`, and the code tried to access `.word_text` directly on the multi-recordset, which expects a singleton. Error: `ValueError: Expected singleton: iap.extracted.words(35683, 35697)` Solution: - Added `('word_text', '=', text_to_send['content'])` to the search domain to ensure only matching record is returned. sentry-6547557298 Forward-Port-Of: odoo/enterprise#83878
Original PR description
The error occurred because multiple `iap.extracted.words` records matched the search filter for `user_selected_box`, and the code tried to access `.word_text` directly on the multi-recordset, which expects a singleton.
Error:
`ValueError: Expected singleton: iap.extracted.words(35683, 35697)`
Solution:
- Added `('word_text', '=', text_to_send['content'])` to the search domain to ensure only matching record is returned.
sentry-6547557298
Forward-Port-Of: odoo/enterprise#83878See also: odoo/odoo#208257 Forward-Port-Of: odoo/enterprise#84595
Original PR description
See also: odoo/odoo#208257 Forward-Port-Of: odoo/enterprise#84595
Currently a ParseError is arising when the user installs the `pos_settle_due` module after deleting the `Services` in Product Categories/Configuration. Steps to reproduce: --- - Install `Invoicing` application (without demo data). - Invoicing > Configuration > Product Categories > Delete `Services` - Now install `pos_settle_due` module Traceback: --- ``` ValueError: External ID not found in the system: product.product_category_services ParseError: while parsing /home/odoo/src/ent
Original PR description
Currently a ParseError is arising when the user installs the `pos_settle_due` module after deleting the `Services` in Product Categories/Configuration. Steps to reproduce: --- - Install `Invoicing`…
Currently a ParseError is arising when the user installs the `pos_settle_due` module after deleting the `Services` in Product Categories/Configuration.
Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Product Categories > Delete `Services`
- Now install `pos_settle_due` module
Traceback:
---
```
ValueError: External ID not found in the system: product.product_category_services
ParseError: while parsing /home/odoo/src/enterprise/saas-18.2/pos_settle_due/data/pos_settle_due_data.xml:4, somewhere inside <record id="product_product_settle" model="product.product">
<field name="name">Settle Due</field>
<field name="categ_id" ref="product.product_category_services"/>
<field name="type">service</field>
<field name="weight">0.00</field>
<field name="available_in_pos">False</field>
<field name="taxes_id" eval="[]"/>
</record>
```
The error occurs because the user deleted `Services` in Product Categories, and then tried to install the other module.
This commit resolves the error by providing a False value for the field if the product category is missing.
sentry-6377659355
Forward-Port-Of: odoo/enterprise#81741Community PR: https://github.com/odoo/odoo/pull/207457 The Blackbox driver was sometimes being blocked by the Adam scale driver due to them having the same priority. This commit raises the priority of the Blackbox driver to ensure it runs before other Serial drivers. task-4750364 Forward-Port-Of: odoo/enterprise#84122
Original PR description
Community PR: https://github.com/odoo/odoo/pull/207457 The Blackbox driver was sometimes being blocked by the Adam scale driver due to them having the same priority. This commit raises the priority of the Blackbox driver to ensure it runs before other Serial drivers. task-4750364 Forward-Port-Of: odoo/enterprise#84122
#### [FIX] account_accountant: reco wizard: exchange rate rounding In the related community commit we improved the reconciliation behavior with regards to exchange rate and rounding issues. See there for more details. For one of the tests there we manually created the write-off line with the correct amount. Here we add a test to check that the wizard computes the right amounts for the write-off line / entry. opw-4438542 #### [FIX] account_accountant: reco wizard: show company amou
Original PR description
#### [FIX] account_accountant: reco wizard: exchange rate rounding In the related community commit we improved the reconciliation behavior with regards to exchange rate and rounding issues. See there…
#### [FIX] account_accountant: reco wizard: exchange rate rounding In the related community commit we improved the reconciliation behavior with regards to exchange rate and rounding issues. See there for more details. For one of the tests there we manually created the write-off line with the correct amount. Here we add a test to check that the wizard computes the right amounts for the write-off line / entry. opw-4438542 #### [FIX] account_accountant: reco wizard: show company amount The reconciliation wizard may create a write-off line / entry. Roughly speaking this happens in case - the amount of the input lines does not sum to 0 - and the "Allow partials" option is not ticked The write-off line can be in foreign currency. Currently the wizard only displays the amount in foreign currency but not the amount in company currency. So currently the company currency amount can not be checked before reconciling. After this commit the wizard also displays the amount in company currency. opw-4623933 Forward-Port-Of: odoo/enterprise#84652 Forward-Port-Of: odoo/enterprise#82865
Before This **PR**: If a company attempted to generate a GST token using a GST number already assigned to another company with a valid token, the system returned an ambiguous error: {'message': 'API access is not available or user expiry duration is less than or equal to auth token expiry duration', 'error_cd': 'AUTH4037'}. This caused confusion for users, as the message did not clearly indicate the issue. After This **PR**: A new function has been introduced to check whether another compa
Original PR description
Before This **PR**:
If a company attempted to generate a GST token using a GST number already assigned to another company with a valid token, the system returned an ambiguous error: {'message': 'API access is not available or user expiry duration is less than or equal to auth token expiry duration', 'error_cd': 'AUTH4037'}. This caused confusion for users, as the message did not clearly indicate the issue.
After This **PR**:
A new function has been introduced to check whether another company has the same GST number and a valid token before sending the request. If such a case is detected, the system now displays a warning, recommending the use of a Tax Unit.
**task**-4636041
Forward-Port-Of: odoo/enterprise#84684
Forward-Port-Of: odoo/enterprise#81218How to reproduce: - Select a Belgian company - Create an invoice for a EU country - Add a line with no product - Display the intrastat report for the invoice period - Export the xml The default sql query allows the selection of account move lines with no product to be able to trigger a warning. Those lines are then filtered out when displayed in the web interface. Those lines were not filtered out when getting data for file exports. An error would trigger rendering the xml as the weight
Original PR description
How to reproduce: - Select a Belgian company - Create an invoice for a EU country - Add a line with no product - Display the intrastat report for the invoice period - Export the xml The default sql query allows the selection of account move lines with no product to be able to trigger a warning. Those lines are then filtered out when displayed in the web interface. Those lines were not filtered out when getting data for file exports. An error would trigger rendering the xml as the weight would be None where an integer is required. This commit adds a condition to only select move lines with a product_id when querying data for a file. Task 4763185 See opw-4671512, opw-4735439, opw-4642781 Forward-Port-Of: odoo/enterprise#84635 Forward-Port-Of: odoo/enterprise#84517
### Issue: If `l10n_br_avatax` is installed, portal users are not able to view any products via the shop on a Website. An inherited field's domain requires access to the `city_id` from the Website's company's `res.partner` record, but Portal users cannot access this. This is only an issue on 18.2+, as this value was originally stored in the field cache due to a separate workflow in previous versions. Previously, opening a product would trigger `_compute_fiscal_position_id`, which would event
Original PR description
### Issue: If `l10n_br_avatax` is installed, portal users are not able to view any products via the shop on a Website. An inherited field's domain requires access to the `city_id` from the Website's…
### Issue: If `l10n_br_avatax` is installed, portal users are not able to view any products via the shop on a Website. An inherited field's domain requires access to the `city_id` from the Website's company's `res.partner` record, but Portal users cannot access this. This is only an issue on 18.2+, as this value was originally stored in the field cache due to a separate workflow in previous versions. Previously, opening a product would trigger `_compute_fiscal_position_id`, which would eventually call `_compute_address`. `_compute_address` contains a sudo, allowing the retrieval of the address fields (like `city_id`) and would store them in cache. The domain would be able to retrieve from the cache rather than needing to fetch the values. In 18.2, the `fiscal_position` workflow was refactored, and the address fields are no longer stored in cache for the domain `_l10n_br_property_service_code_origin_id_domain` to access prior to hitting any security limits. ### Solution: We should be safe to `sudo` the `city_id`, allowing the domain to complete. opw-4732256 Forward-Port-Of: odoo/enterprise#84140
A `CheckViolation` traceback occurs when uploading an XML file that lacks the `Nombre` attribute. **Steps to Reproduce:** - Install `l10n_mx_edi` module - Navigate to `Accounting>Vendors>bills` try to upload [this](https://drive.google.com/file/d/1DRON2ftkDhwASqy_OFi9FtUNj7tODyKm/view?usp=sharing) `[demo file]` **Error:** `CheckViolation: new row for relation 'res_partner' violates check constraint 'res_partner_check_name'` **Root Cause:** - The `Nombre` attribute in the XML file is
Original PR description
A `CheckViolation` traceback occurs when uploading an XML file that lacks the `Nombre` attribute. **Steps to Reproduce:** - Install `l10n_mx_edi` module - Navigate to `Accounting>Vendors>bills` try…
A `CheckViolation` traceback occurs when uploading an XML file that lacks the `Nombre` attribute. **Steps to Reproduce:** - Install `l10n_mx_edi` module - Navigate to `Accounting>Vendors>bills` try to upload [this](https://drive.google.com/file/d/1DRON2ftkDhwASqy_OFi9FtUNj7tODyKm/view?usp=sharing) `[demo file]` **Error:** `CheckViolation: new row for relation 'res_partner' violates check constraint 'res_partner_check_name'` **Root Cause:** - The `Nombre` attribute in the XML file is missing, which results in the `name` field being set to `None` at [1] in the `partner_vals` dictionary. [1]- https://github.com/odoo/enterprise/blob/1d06bf93a2be03e969a5fce134b7323a70b2aef1/l10n_mx_edi/models/account_move.py#L2504 - The `res.partner` model has a database constraint (**res_partner_check_name**) that requires the `name` field to be non-null. When attempting to create a `partner` with a None value for `name`, the database raises a **CheckViolation error**. **Solution:** - Added a check in the `_l10n_mx_edi_import_cfdi_fill_partner` method to handle cases where the `Nombre` attribute is missing. - This prevents the creation of a partner with an invalid `name` field and avoids the **CheckViolation error**. sentry- 6546905710 Forward-Port-Of: odoo/enterprise#83776
Version: - saas-17.4 Steps to reproduce: - Create request signature activity for sign request. - Try to send document for sign from activity. Issue: - It will give a traceback to user. Cause: - It will try to create a record for 'sign.request' model and in reference_doc field it was showing wrong value as we are not allowing to create reference_doc for 'sign.request' model. Solution: - Since reference_doc is not supported for 'sign.request', this fix adds a condition to explici
Original PR description
Version: - saas-17.4 Steps to reproduce: - Create request signature activity for sign request. - Try to send document for sign from activity. Issue: - It will give a traceback to user. Cause: - It will try to create a record for 'sign.request' model and in reference_doc field it was showing wrong value as we are not allowing to create reference_doc for 'sign.request' model. Solution: - Since reference_doc is not supported for 'sign.request', this fix adds a condition to explicitly skip setting it for that model task-4416253 Forward-Port-Of: odoo/enterprise#84599 Forward-Port-Of: odoo/enterprise#75611
Before, `l10n_ar_edi` had only live test cases. This means that if there is an error in a PR or forward port, no tests would catch it as the were marked `external_l10n` and not ran. Using both `l10n_ke_edi_oscu` and and `l10n_br_edi_pos` recent mock setup as an example, this PR aims to mock the soap requests sent in the module. Notes: - As of now this is only one individual test case. More tests will come as there is time, but having 1 will prevent errors from happening again. - Within th
Original PR description
Before, `l10n_ar_edi` had only live test cases. This means that if there is an error in a PR or forward port, no tests would catch it as the were marked `external_l10n` and not ran. Using both…
Before, `l10n_ar_edi` had only live test cases. This means that if there is an error in a PR or forward port, no tests would catch it as the were marked `external_l10n` and not ran. Using both `l10n_ke_edi_oscu` and and `l10n_br_edi_pos` recent mock setup as an example, this PR aims to mock the soap requests sent in the module. Notes: - As of now this is only one individual test case. More tests will come as there is time, but having 1 will prevent errors from happening again. - Within this module, when the first record within an EDI journal is created, it will try to pull the sequence from the database, and if it can't find a suitable last sequence, it will query the API. This means that any onchange on the first journal entry that will recompute the name or sequence leads to the `_get_last_sequence` function being called and making an API request as the sequence isn't stored in the database yet. The point of this appears to be convenience when transfering from another system to odoo and pulling the latest invoice number they had. The main downside of this feature is that creating the first record now has around 11 API calls returning the same value due to different onchanges on the record. The main calls come from `_compute_name` in the base account module but the rest are from other methods that use the sequence or call `_compute_name` (like `_onchange_l10n_latam_document_type_id`) As this PR is only intended to write tests for the module, the test file matches what occurs in the front-end but future PRs can look into if there are improvements that can be made on stable to simplify this. task-4714096 Forward-Port-Of: odoo/enterprise#84824 Forward-Port-Of: odoo/enterprise#83553
Apply the HSN schema based on the 'l10n_in_reports.hsn_new_schema_apply_date' system parameter. If the parameter is missing or invalid, default to 2025-05-01 as per government guidelines. Forward-Port-Of: odoo/enterprise#84825 Forward-Port-Of: odoo/enterprise#84745
Original PR description
Apply the HSN schema based on the 'l10n_in_reports.hsn_new_schema_apply_date' system parameter. If the parameter is missing or invalid, default to 2025-05-01 as per government guidelines. Forward-Port-Of: odoo/enterprise#84825 Forward-Port-Of: odoo/enterprise#84745
Community: https://github.com/odoo/odoo/pull/208609 Design Themes: https://github.com/odoo/design-themes/pull/1059
Original PR description
Community: https://github.com/odoo/odoo/pull/208609 Design Themes: https://github.com/odoo/design-themes/pull/1059
8 changes
New functionality added to Odoo
WhatsApp message templates can now include a Copy Offer Code button, making it easier for recipients to copy promotional codes directly to their clipboard. This helps businesses share discounts and special offers with less friction for customers.
Original PR description
PURPOSE This commit adds a new `Copy Offer Code` button to the WhatsApp template. SPECIFICATION A new `Copy Offer Code` button copies a text string (defined when the template is sent in a template message) to the device's clipboard when the app user taps it. Whatsapp Templates are limited to one copy code button. The button will allow users to easily copy promotional offer codes and use them for discounts or special offers. Task-3818664 Upgrade PR - https://github.com/odoo/upgrade/pull/6122
Enhancements to existing features
Payroll contracts now include an analytic account widget, making it easier to allocate an employee's costs across multiple analytic accounts. This helps businesses track payroll expenses more accurately by department, project, or other cost centers.
Original PR description
To be able to split the employee's cost on multiple analytic accounts, an analytic account widget has been added to the UI. Task: 4775857
WhatsApp conversations now use the actual WhatsApp account record instead of a separate account name field. This simplifies the underlying data model and adds a demo WhatsApp account so demonstrations and tests better reflect real usage.
Original PR description
This PR converts `whatsapp_account_name` to it's record `wa_account_id`. This PR also adds a demo whatsapp account to the demo data. Related: https://github.com/odoo/odoo/pull/208397 Task-4675978
Resolved issues and error corrections
Planning open shifts now use the company calendar instead of an employee schedule when no specific resource is assigned. This prevents Sunday open shifts from showing 00:00 allocated time and avoids incorrectly greying out weekends for open shifts.
Original PR description
Steps to reproduce: ------------------- - Install `Planning` module - Go to `Planning` - Create a new slot in the `Open Shifts` for Sunday Issue: ------ The default `Allocated Time` is set to `00:00` while it should be set to on the average hours per day configured on the company's calendar, which is `08:00` by default. Cause: ------ If no resource is assigned to the slot by default, the employee resource is used instead. Therefore, since we have an employee on the slot, the slot duration is computed based on the employee's working hours, instead of the company's calendar. Solution: --------- Don't fall back on the employee resource if no resource is set by default opw-4353378
The deferral revenue and expense report no longer interrupts users with a “No entry to generate” message when there is nothing to create. When entries are generated, users are taken to the appropriate list or form view, making it easier to review the resulting accounting entries.
Original PR description
- Do not pop ''No entry to generate.'' error message. Open the the list view in more than 1 of the generated entries. task-4636850
Miscellaneous changes
Steps to reproduce: - Install payroll, payroll Mexican localisation - Switch to the Mexican company - Choose an employee from the Mexican company - Change the contract to be hourly waged instead of monthly - Set a value for the wage/hour - Create some work entries for that employee - Generate a payslip for the employee in the duration you are testing - Edit the work entries you have to have some unpaid leaves - Generate another payslip for the employee Current Behavior: Payslip is g
Original PR description
Steps to reproduce: - Install payroll, payroll Mexican localisation - Switch to the Mexican company - Choose an employee from the Mexican company - Change the contract to be hourly waged instead of…
Steps to reproduce: - Install payroll, payroll Mexican localisation - Switch to the Mexican company - Choose an employee from the Mexican company - Change the contract to be hourly waged instead of monthly - Set a value for the wage/hour - Create some work entries for that employee - Generate a payslip for the employee in the duration you are testing - Edit the work entries you have to have some unpaid leaves - Generate another payslip for the employee Current Behavior: Payslip is generated without taking into consideration the number of hours actually worked and the unpaid leaves taken by the employee. It also generates the payslip with the value of the wage/month regardless of the value of the wage/hour you added. Issue: In df8f53b0cad4738537f18890e628c286dedaa141, Mexican localisation was implemented but with computing the amount of the `payslip_worked_days` using the `contract.wage` which is the fixed amount of wage/month. https://github.com/odoo/enterprise/blob/25caeeab01abc0b47f6bd6b02658c3bbbe0aba96/l10n_mx_hr_payroll_localisation/models/hr_payslip_worked_days.py#L19-L20 opw-4604675 Forward-Port-Of: odoo/enterprise#83135
The SpreadsheetName component is designed to grow indefinitely with the length of its text content. However, this means that it'll end up breaking the page layout. This revisions revisits the component structurea and embedding to prevent it from growing larger than the visible viewport of the client. Task: 4760366 Forward-Port-Of: odoo/enterprise#84664 Forward-Port-Of: odoo/enterprise#84410
Original PR description
The SpreadsheetName component is designed to grow indefinitely with the length of its text content. However, this means that it'll end up breaking the page layout. This revisions revisits the component structurea and embedding to prevent it from growing larger than the visible viewport of the client. Task: 4760366 Forward-Port-Of: odoo/enterprise#84664 Forward-Port-Of: odoo/enterprise#84410
Before this commit, when a sign field type was attached to a model, it could be automatically completed if the sign.request was linked to another model. Steps to reproduce: 1) Create a sign field type: text, model: sale.order, field: reference 2) Add this field in a sign.template. 3) Open a manufacturing order (mrp.production), create a sign request for it 4) sign the MO, the reference field is automatically filled. The method getting the value to fill, don't check the model. As a reus
Original PR description
Before this commit, when a sign field type was attached to a model, it could be automatically completed if the sign.request was linked to another model. Steps to reproduce: 1) Create a sign field type: text, model: sale.order, field: reference 2) Add this field in a sign.template. 3) Open a manufacturing order (mrp.production), create a sign request for it 4) sign the MO, the reference field is automatically filled. The method getting the value to fill, don't check the model. As a reuslt if the same field exists, it will be filled. taskid: 4672517 Forward-Port-Of: odoo/enterprise#84204 Forward-Port-Of: odoo/enterprise#82085
42 changes
New functionality added to Odoo
This change adds custom financial add-ons to the repository. It may introduce additional accounting-related capabilities, but the pull request description does not specify the exact business behavior or user impact.
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
Enhancements to existing features
Electronic invoices now include the customer's or supplier's internal reference in the standard party identification section. This helps recipients match UBL invoice files to the correct business partner more reliably, while updating related test examples to reflect the new information.
Original PR description
Add the partner's `ref` field to the list of PartyIdentification>ID. task-4720252
Somehow, translations files were lacking for this module. Done by Larissa (lman) 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
Original PR description
Somehow, translations files were lacking for this module. Done by Larissa (lman) 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
Belgian CODA bank statement imports now extract the vendor name and city from ATM/POS debit transaction details when available. This helps Odoo match card payments to the correct business partner more reliably, reducing manual reconciliation work.
Original PR description
When dealing with statements with communication type 113 (ATM/POS debit), the partner is actually "hidden" in the communication field. We use this to retrieve a potential `partner_name` (name + city of vendor) that we can match to a real partner in the database. [format_description_CODA.pdf](https://github.com/user-attachments/files/20080995/format_description_CODA.pdf) opw-4653293
Resolved issues and error corrections
This fixes account code mapping rules so non-German companies can update their mappings even when the shared account belongs to a German company. German company mappings remain protected for compliance, preventing changes when the account already has related journal entries.
Original PR description
Description: Description of the issue/feature this PR addresses: --- In #172660 we prevent changing the code of accounts used in German companies as part of changes for GoBD compliance. This was…
Description: Description of the issue/feature this PR addresses: --- In #172660 we prevent changing the code of accounts used in German companies as part of changes for GoBD compliance. This was valid before V18.0 where we introduced cross company accounts where the same account can have different code mappings for different companies. The constraint needs to adapt to allow changing the mapping of non-German companies even if the account itself is from a German company. Current behavior before PR (steps to reproduce): --- 1. In a German company, open a used account (has some entries) from chart of accounts. 2. switch to "Mapping" tap, and try to set a code for any other non German company. 3. you will get the error "You can not change the code of an account" as if you are changing a German company code. Desired behavior after PR is merged: --- The error only raises if you change the mapping of a German company, and allow other companies mappings to change. Also adding a check for non-German accounts, if the code mapping of a German company is changed. opw-4670638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a layout issue where PDF report page numbering could split across two lines when Montserrat was selected for document layouts. This keeps report footers cleaner and more consistent for downloaded or printed business documents.
Original PR description
Steps to reproduce: 1. Go to Settings > Configure your document layout> Select Text as Montserrat 2. Preview Document > open downloaded file Issue: The issue is when printing reports using the ‘Montserrat’ text font with ‘A4’ paper format in the ‘Configure Document Layout’ section of the general settings. The word "Páge" does not align correctly in a single line with "X/X" at the bottom right of the report. However, it prints correctly when using the other fonts. Solution: Applied Bootstrap's text-nowrap class to prevent pagination text from breaking onto separate lines when using the Montserrat font. This addresses the issue where "<span class="page"/>" and "<span class="topage"/>" components were displaying on different lines in PDF reports. opw-4654332 Before FIX:  After FIX: 
Custom background images in document layouts now scale proportionally and remain centered instead of being cut off. This improves the appearance of reports and customer-facing documents that use branded background images.
Original PR description
Steps to reproduce: 1. Settings > Navigate to Configure Document Layout 2. Under Layout Background, select Custom and upload an image. Issue: Background image was being cut off at the end. The image was not covering the entire div. Solution: Updated the `.o_report_layout_background` CSS to use `background-size: contain` and remove 300px from `background-position` to ensure the image scales proportionally and stays centered. opw : 4727408 Before FIX :  After FIX : 
This fixes an access issue that prevented users limited to a Belgian company branch from opening a Point of Sale session. The system can now load the required parent-company tax configuration when the user is authorized for the branch, helping branch staff start POS operations without unnecessary parent-company access.
Original PR description
- Before this fix, when a user which have only access to a company branch (not access to the parent company), he was not able to open a POS session. This issue was only appearing when using a belgian…
- Before this fix, when a user which have only access to a company branch (not access to the parent company), he was not able to open a POS session. This issue was only appearing when using a belgian company (with `l10n_be_pos_sale` installed). This error was raised becaues we try to load Intra-Community chart template which is defined on the parent company. - Now we use `sudo()` to correctly load the Intra-Community chart template of the parent company, because if the user has permission to open a POS session on a company branch, he should be able to load its Intra-Community chart template (even if it's defined on the parent company). - Update the test `test_pos_branch_company_access` so the `pos_user` have only access to the company branch (not the parent company anymore). Steps to reproduce: - Install ``l10_be_pos_sale` module - Create a new belgian company with a branch - Create a new user with access to this company branch (not the parent company) - Create a new POS config for this company branch (with admin user) - Try to open a POS session with the newly created user - => Access error opw: 4736949 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that could stop users from scanning vendor bills in the India localization. The change prevents a processing crash, helping invoice capture continue smoothly.
Original PR description
When user tries to scan Vendor Bill, a traceback will appear.
Traceback:
```
File "/home/odoo/src/odoo/saas-18.2/addons/l10n_in/models/res_partner.py", line 219, in _l10n_in_get_partner_vals_by_vat
for fname in partner_data:
RuntimeError: dictionary changed size during iteration
```
https://github.com/odoo/odoo/blob/ac3924508016178427c7962fa3b8e645e7e03835/addons/l10n_in/models/res_partner.py#L103-L105
Here, this method modifies the ``partner_data`` dictionary
(using pop()) while iterating over it,
which leads to the above traceback.
To resolve this, the loop now iterates over a list of keys from ``partner_data``.
[ref](https://github.com/odoo/enterprise/blob/6f5e6a43f6149b4a8418d78a457f543de2dcfea3/l10n_in_qr_code_bill_scan/models/account_move.py#L90)
sentry-6586138810
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSpanish POS simplified invoices now keep the price list manually selected by the cashier instead of replacing it with the simplified invoice customer’s default price list. This prevents unexpected remaining balances at checkout and helps orders validate correctly when a different price list was intentionally used.
Original PR description
Currently, when you make a simplified invoice in pos, the pricelist will always be set to the simplified invoice partner pricelist, even if you had specifically set another pricelist during the…
Currently, when you make a simplified invoice in pos, the pricelist will always be set to the simplified invoice partner pricelist, even if you had specifically set another pricelist during the order. Steps to reproduce: ------------------- * Create 2 pricelists, A and B, let's say A always adds a 10$ fee * Set both as available in the POS, with A being the default one * On the contact "Simplified invoice parner", set the pricelist A * Open pos * Change pricelist to B * Pay and validate order > Observation: Order is not validated, 10$ left to pay Why the fix: ------------ Prior to the use of `set_partner`, we used to simply write the partner field of the order when using the simplified invoice partner. Now we are using `set_partner` which is a generic function that handles everything related to changing partners, such as updating pricelist. https://github.com/odoo/odoo/blob/69057e41fb4cd800d23401ead8ae11bf7cba7c64/addons/point_of_sale/static/src/app/models/pos_order.js#L941-L948 In our example since the default pos pricelist was manually changed it means that the intention was to use this set pricelist. What we do now in this case is to check if the pricelist was purposefully changed (it differs from the default pricelist), and in this case we want to use this pricelist on the order. opw-4662248
The invoice portal now hides the electronic format field when there are no available options to show. This prevents customers from seeing an empty, confusing field when accessing invoices through self-invoicing flows such as PoS.
Original PR description
The electronic format field should not be displayed in the portal when no option is available for it. Steps to reproduce: ------------------- * (The reported flow was using PoS) * Install the l10n_mx_edi_pos module * Create a PoS and use the self invoicing feature * Make an order and pay for it * On the ticket scan the QR Code and access the invoice portal > Observation: The electronic format field is displayed in the portal but it is empty Why the fix: ------------ We hide the field when no value is available for it. opw-4628351
This fix prevents manufacturing orders from crashing when a customer selects a no-variant product option that does not match a component restriction in the bill of materials. It ensures irrelevant component lines are skipped safely, improving reliability for made-to-order products with multiple configurable options.
Original PR description
Steps to reproduce: - Create a product with two separate 'no-variant' attributes - Set that product as MTO / Manufacture - Create a BoM for that product, with a single component - Set that component as limited to the first 'no-variant' attribute - Create a Sale Order for that product, and select the second 'no-variant' attribute - Confirm the Sale Order Issue: A traceback will be raised, as the given attribute won't be found within the attributes set on the bom. When chekcing if we should skip the bom line, there will be an issue if there's a miss-match between the attributes written on a line and the ones given to the MO. To avoid this, we now directly exclude a line when there's no common attribute between the two, then validate it once at least one match was found. opw-4758951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects how dashboard content is displayed in the selected language. It helps users see dashboard information consistently in their preferred language, especially on mobile views.
Paid Point of Sale orders can no longer be accidentally reopened or changed when another device reconnects after being offline. This prevents completed restaurant orders from returning to draft status and gives users a clear message when an order has already been finalized.
Original PR description
Before this commit, when working with PoS on several devices, one of which is offline, a synchronization error occurred. Example: 1. PoS-1 creates a command and then loses its connection 2. PoS-2 the order is received from PoS-1, it is paid here. 3. PoS-1 adds a command line and recovers its connection. The command returns to “draft” state, which should not be possible. Now, once a command has been paid for, it cannot be drafted again. An error is returned to the user indicating that the order has been finalized. This commit also adds a server request in case of error during orders synchronization.
Self-order customers can now pay with Adyen without seeing an immediate error after sending the payment to the terminal. This prevents confusing failed-payment messages when the terminal payment is actually processing successfully.
Original PR description
Introduced in odoo/odoo#164793. Steps to reproduce: - Configure a POS to use self order - Add an Adyen payment method to this POS - Attempt to pay for a self order using the Adyen payment method - The payment fails immediately with an error message, however the payment does go through to the payment terminal. This bug was introduced by the refactor to use related models. The `start_payment` method in the payment page wasn't updated accordingly, leading to an error due to calling a non-existent function. All other payment terminals are unaffected as they override this method, but Adyen does not, so the bug was only affecting Adyen payments. task-4749171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a cashier closes the scale weighing window without confirming a weight, the product is no longer added to the order automatically. This prevents accidental sales lines and avoids charging customers for items that were not weighed or purchased.
Original PR description
Steps to reproduce: - Connect IoT box with scale to DB - Configure PoS with the scale - Configure product to be available in PoS and has to be weighed - Make an order with the product - Scale window pops up for weighing - Close window directly - One unit of product is still added, we expect nothing to be added opw-4643243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change renews the demo certificate used for Spain's TicketBAI electronic invoicing tests so it remains valid with the updated 2025 date. It also avoids sending an extra business activity code requirement to tax agencies that do not need it, reducing unnecessary validation issues.
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
Bullet lists pasted into code-style sections in the HTML editor will now stay where users put them after saving. This prevents content from unexpectedly moving outside the code section in Knowledge articles and other editor uses.
Original PR description
**Description**
there is quirk in lxml library which do not allow `<ul>` directly inside `<pre>`
currently
```
doc = html.fromstring("<pre><ul><li>item1</li></ul></pre>")
html.tostring(doc)
```
results into
```
<div><pre></pre><ul><li>item1</li></ul></div>
```
**step to reproduce**
1. open a knowledge article
2. create a bullet list
3. create a code section
4. copy the list and paste it inside code section
5. save the article
observation: the list moved outside of code section
Desired behavior after PR is merged:
- this commit mitigates this by wrapping such ul's with a <div> when pasting such content inside <pre>
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixed an issue where orders placed through self-order in pickup mode did not automatically show up in the Point of Sale screen. This helps staff see and process incoming orders without manual workarounds or delays.
Original PR description
Before this commit, when an user was ordering from self-order in picking mode, the order was not automatically displayed in the POS. This was because of related models that was trying to access records variable with a wrong way. This commit fixes this issue by using the correct way to access the records variable.
Check payments can now be printed for draft bills that do not yet have a bill number. This prevents an error during payment processing by using a safe placeholder until the bill is posted.
Original PR description
**Steps to reproduce:** - Create new bill and save it manually (still in draft, with no name) - Select bill from the list view and press `Pay` button - Select check payment method - On the new payment page press `Print Check` button - Press `Print` button on the pop-up **Issue:** As task-id 3979071 (https://github.com/odoo/odoo/commit/3ccdd62bb9ce2f623e31f2e82aa1d5b35afe9d95) allowed payment on draft invoices, bills with unset name were throwing an error when printing check payment. **Fix:** Added '/' as default value of the invoice name for check payment which have unposted bills. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4662760) opw-4662760
Fixed a display issue on Point of Sale receipts where order lines could scroll unexpectedly when product names were long. This makes printed or viewed receipts cleaner and easier for staff and customers to read.
Original PR description
<b>Steps to reproduce:</b> 1. Go to Sales > Create New Quotation. 2. Add a customer and a product(e.g., "Acoustic Bloc Screens testingggggggggg"). 3. Go to POS > Open any register. 4. Navigate to Actions > Quotation/Order, select SO. 5. Apply a down payment percentage. 6. Enter the percentage, select Payment > Cash, and validate the payment. 7. Navigate Print full receipt. <b>Issue:</b> Unintended scrolling behavior in the order line section. <b>Cause:</b> Although the container had the class overflow-y-auto, it wasn't the root cause. The issue occurred with long product names in certain configurations, leading to unintended scrolling behavior. <b>Solution:</b> Added the product-name class to handle content display and prevent unnecessary scrolling. opw-4479286
This fix ensures copied databases for the Belgian payroll DMFA SFTP module are neutralized so they do not contact external systems by mistake. It helps support teams investigate issues on database duplicates without risking unintended actions affecting production data or customers.
Original PR description
This commit adds the missing neutralization necessary for the l10n_be_hr_payroll_dmfa_sftp module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/enterprise/pull/83244
This fix prevents users from accidentally creating an incomplete private key entry while configuring Argentinean electronic invoicing. It avoids an error during renewal request generation, helping companies complete required tax setup more reliably.
Original PR description
The system failed to retrieve `company.l10n_ar_afip_ws_key_id.pem_key` because of quick create. Steps to Reproduce: 1. Switch to `(AR) Exento Company`. 2. Navigate to `Settings `> `Invoicing`. 3. Search for `Argentinean Localization`. 4. In `Primary Key`, clear the field, enter any value, and click Create. 5. Click `Generate Renewal Request`. Error: `TypeError: argument should be a bytes-like object or ASCII string, not 'bool'` Solution: Add `no_quick_create : True` for l10n_ar_afip_ws_key_id field. Sentry - 5999498377
Quality check lists now respond properly when users select activity deadline groups such as Late, Today, or Future. This prevents unrelated quality checks from appearing and makes activity follow-up more reliable for quality teams.
Original PR description
Steps to reproduce the issue:
- Create a quality check with any parameters
- Add a future activity
- Click on the activity icon in the top bar
- The activity summary shows:
- 0 Late, 0 Today, 1 Future
- Click on "Late"
Issue:
No filter is applied and all quality checks are displayed.
Solution:
Added predefined filters for activity deadlines (Late, Today, Future) in the search view of the quality.check model, to align with other models using mail.activity.mixin.
opw-4727840Employees or freelancers without an Odoo user or contract can now still complete document signing requests. The system assigns the request sender as the document owner when no other owner is available, preventing signing from being blocked.
Original PR description
It is possible that a employee won't have a contract (maybe a freelancer) nor a user related. In such case when asked to sign a document, the document cannot be signed. It is possible to reproduce this behaviour on runbot https://www.awesomescreenshot.com/video/39482670?key=9eed08257cc76b5749c1c8c0dda62377 This commit aims to set a user, since the user cannot be false. I believe that since one of the options would be set it to the manager of the contract the employee is under, it would be a valid option considering that the employee has no contract, to set it to whoever sent the request, in this case, the request create_uid opw-4750010
Financial reports now correctly include analytic simulations when users enable the related option. This ensures simulated analytic entries appear in the expected analytic columns, helping teams review planned or unposted analytic impacts more accurately.
Original PR description
Current behavior before PR: - When showing analytic columns in reports, a filter can be applied from 'Options' menu to show analytic simulations (analytic items not linked to any move). This filter didn't work properly. Desired behavior after PR is merged: - Analytic simulations are integrated in the already existing analytic groupby columns Link to the task : - https://www.odoo.com/odoo/project/967/tasks/4603267
Fixed an issue where Intrastat report lines could fail to expand when an invoice had no delivery terms set but the company did. The report now correctly uses the company’s default Incoterm in that case, helping users review the expected transaction details.
Original PR description
The incoterm code of a line in the intrastat report is the incoterm code from the move or if there is no incoterm code on the move, the one from the company. When creating the request when unfolding report lines, the incoterm code was always checked on the move and not on the company. This would not return lines without incoterm code. This commit changes the incoterm domain to also check the incoterm code of the move company when no incoterm code is set on the move. Steps to reproduce: - From an EU company, create an invoice to a company in another EU country - Do not set an incoterm on the invoice - In settings, set a default incoterm on the company - Display the intrastat report for the time period of the invoice - Try to unfold the line corresponding to the invoice opw-4642781
Intrastat product and services reporting logic was simplified to avoid unnecessary repeated checks and make calculations more efficient. A duplicate test assertion was also removed, improving maintainability without changing expected user workflows.
Original PR description
compute imp & assert deduplicate
Users can once again find contacts by name when inviting people to access documents or folders. This makes sharing documents easier and avoids confusion when an email address is not the quickest way to identify someone.
Original PR description
**How to reproduce:** - Create a partner with name 'abc' and email 'xyz@xyz.com' - Select a document/folder - Click the 'Share' button - Search by email, it'll work - Search by name, it doesn't work **Before this commit:** Search by name is not working **Technical reason:** Partner's display name is passed in a variable called 'label' **After this commit:** Search on name will work on member invite modal Task-4758923
Miscellaneous changes
### Steps to reproduce: - In the settings enable Multi-Steps Rules - Inventory > Configuration > Warehouse Management > Warehouses - Put your warehouse in delivery in 2 steps and modify the rules to be in the old pull set up Stock 1-> Output 2-> Customer. - Enable the "Cancel next move" option of the pick rule. - Create an SO for 1 unit of a storable product > This should generate both a pick and a ship move. - Cancel the pick move #### > The ship move was not cancelled ### Cause of
Original PR description
### Steps to reproduce: - In the settings enable Multi-Steps Rules - Inventory > Configuration > Warehouse Management > Warehouses - Put your warehouse in delivery in 2 steps and modify the rules to…
### Steps to reproduce: - In the settings enable Multi-Steps Rules - Inventory > Configuration > Warehouse Management > Warehouses - Put your warehouse in delivery in 2 steps and modify the rules to be in the old pull set up Stock 1-> Output 2-> Customer. - Enable the "Cancel next move" option of the pick rule. - Create an SO for 1 unit of a storable product > This should generate both a pick and a ship move. - Cancel the pick move #### > The ship move was not cancelled ### Cause of the issue: While the moves of the chain are correctly linked and the `move_dest_ids` of the pick move is planed to be cancelled, it does not satisfy the filtering condition of moves that should be cancelled because as it is at the end of the chain it does not have a `move_dest_id` it self: https://github.com/odoo/odoo/blob/eb43cdbfeb3d141283dbd9274fae45bf0bf641db/addons/stock/models/stock_move.py#L1966-L1968 IMO, the condition on the locations should be set between the move we are cancelling and the move we plan to cancel rather than on next step of the chain that might not even exist. Note (fix sale_stock): The forward port of commit 853d9c46fc506564c5c40a2ce7cd14507109a923 has not been merged in 17.2 since its issue was not reproducible in that version. This is because the propagate cancel option was not working properly since the push pull refactor. To merge our change we therefore need to reintroduce the associated `sale_stock` fix. opw-4689175 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205120
Before this commit, if the generic manufacture route was in a different company, the user won't be able to create a new warehouse. Steps to reproduce ----- 1. Set the company of the Manufacture route to company A 2. Switch to company B 3. Create a new warehouse 4. Access Error `Due to security restrictions, you are not allowed to access 'Inventory Routes' (stock.route) records.` Cause ----- There is an if-statement to check if the found global route is of the same company. https://g
Original PR description
Before this commit, if the generic manufacture route was in a different company, the user won't be able to create a new warehouse. Steps to reproduce ----- 1. Set the company of the Manufacture route to company A 2. Switch to company B 3. Create a new warehouse 4. Access Error `Due to security restrictions, you are not allowed to access 'Inventory Routes' (stock.route) records.` Cause ----- There is an if-statement to check if the found global route is of the same company. https://github.com/odoo/odoo/blob/856409a1fb35c6c49fe4c404931587a95d99d370/addons/stock/models/stock_warehouse.py#L385 But this conditional is likely to raise an access error if the route is in a different company, since we don't have read access to `route`. Solution ----- Use `route.sudo()` to read the route without an access error. opw-4725501 Forward-Port-Of: odoo/odoo#208234
We needed to change the 2022 frozen date to 2025 to avoid having an invalid certificate. 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#208568
Original PR description
We needed to change the 2022 frozen date to 2025 to avoid having an invalid certificate. 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#208568
Backport of #194647 Basically, starting from `saas~16.4` we have action window in `hr_recruitment` which is pointing at `sms` module. If client does this steps: 1. Install `hr_recruitment` in version 17.0 2. Uninstall the module `sms` 3. Try to upgrade db to `18.0` We will have the issue similar to this: ``` Traceback (most recent call last): File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1318, in preload_registries registry = Registry.new(dbname, update_modul
Original PR description
Backport of #194647 Basically, starting from `saas~16.4` we have action window in `hr_recruitment` which is pointing at `sms` module. If client does this steps: 1. Install `hr_recruitment` in version…
Backport of #194647
Basically, starting from `saas~16.4` we have action window in `hr_recruitment` which is pointing at `sms` module.
If client does this steps:
1. Install `hr_recruitment` in version 17.0
2. Uninstall the module `sms`
3. Try to upgrade db to `18.0`
We will have the issue similar to this:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1318, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 127, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 476, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 227, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line 608, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line 679, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line 594, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line 548, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/odoo/18.0/addons/hr_recruitment/views/hr_candidate_views.xml:220
Invalid model name “sms.composer” in action definition.
View error context:
'-no context-'
```
Th bridge module was intrdocued in #194647 targeting to version `saas~18.2`, but we need it for `17.0, 18.0, saas~18.1` as you see in the example above. This PR will only target to `17.0` and `saas~17.4`. Then we will make another patch for `18.0` and `saas~18.1` as they have some additional change.
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#199238PURPOSE - Integrate the latest set of e-waybill error codes as per the recent government notification. REFERENCES - https://docs.ewaybillgst.gov.in/apidocs/downloads/API-interoperableservices.pdf - https://docs.ewaybillgst.gov.in/apidocs/downloads/Additional_Validations_20241217.pdf Forward-Port-Of: odoo/odoo#208418 Forward-Port-Of: odoo/odoo#208247
Original PR description
PURPOSE - Integrate the latest set of e-waybill error codes as per the recent government notification. REFERENCES - https://docs.ewaybillgst.gov.in/apidocs/downloads/API-interoperableservices.pdf - https://docs.ewaybillgst.gov.in/apidocs/downloads/Additional_Validations_20241217.pdf Forward-Port-Of: odoo/odoo#208418 Forward-Port-Of: odoo/odoo#208247
Steps to reproduce: - Create an invoice through Accounting app - Post the invoice - Register the payment using the "Register Payment" wizard with an electronic payment method. Description of the issue/feature this PR addresses: **The payment transaction was not being linked to the invoice for electronic payments.** To resolve this, I passed the current invoice IDs as context through action_register_payment in the account.move.line model. Then, I retrieved this context value in _prepa
Original PR description
Steps to reproduce: - Create an invoice through Accounting app - Post the invoice - Register the payment using the "Register Payment" wizard with an electronic payment method. Description of the issue/feature this PR addresses: **The payment transaction was not being linked to the invoice for electronic payments.** To resolve this, I passed the current invoice IDs as context through action_register_payment in the account.move.line model. Then, I retrieved this context value in _prepare_payment_transaction_vals of the account.payment model to set the invoice_ids Many2many field. Current behavior before PR: The payment transaction is not linked to the invoice for electronic payments. Desired behavior after PR is merged: The payment transaction will be correctly linked to the invoice for electronic payments. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197091
In odoo/odoo#192634, the `-dNORANGEPAGESIZE` option was added to the Ghostscript call used when printing PDF reports. This fixed the orientation of landscape reports. However, recently this option seems to be causing a crash, reproducible by running Ghostscript directly: > .\gswin64c.exe -dNORANGEPAGESIZE .\test.pdf This happens for all PDF files, and occurs in both the Ghostscript version used by Odoo (10.01.2) and the latest version (10.05.1). However it doesn't seem to happen for eve
Original PR description
In odoo/odoo#192634, the `-dNORANGEPAGESIZE` option was added to the Ghostscript call used when printing PDF reports. This fixed the orientation of landscape reports. However, recently this option seems to be causing a crash, reproducible by running Ghostscript directly: > .\gswin64c.exe -dNORANGEPAGESIZE .\test.pdf This happens for all PDF files, and occurs in both the Ghostscript version used by Odoo (10.01.2) and the latest version (10.05.1). However it doesn't seem to happen for everyone, as it was not reported as an issue when this task was first implemented. The version has not changed so it may be an issue caused by a Windows update or similar. Regardless, this is a blocking issue that is preventing clients from printing, so for now we will just revert the support for landscape printing. opw-4666794 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208545
### Issue: Spamming the validation button in the barcode app can end up performing the operation on an already processed record and raise an invalid operation. ### Steps to reproduce: - Create and confirm a delivery for 1 unit of a storable product. - In the barcode app, scan 1 unit - Spam the validate button #### > An invalid operation is raised: You can not validate a transfer if no quantities are reserved. ### Cause of the issue: Spamming the validate button will launch conc
Original PR description
### Issue: Spamming the validation button in the barcode app can end up performing the operation on an already processed record and raise an invalid operation. ### Steps to reproduce: - Create and confirm a delivery for 1 unit of a storable product. - In the barcode app, scan 1 unit - Spam the validate button #### > An invalid operation is raised: You can not validate a transfer if no quantities are reserved. ### Cause of the issue: Spamming the validate button will launch concurrent calls of the `validate` method. However, if the record has already been processed by a call of the validate method, the next call might be performed on an updated record that should not be able to be validated. opw-4599862 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207795 Forward-Port-Of: odoo/odoo#204790
web push payloads currently get their body truncated when the payload comes out to more than 4096 bytes. However this only keeps the plaintext payload under that limit, not accounting for encryption. As we need the payload to be 4096 bytes at most *after encryption* the threshold for body truncation is reduced to around 3990 bytes to account for the fixed overhead of encryption as laid out in the added constants and getters so that they can be adjusted as needed. Additionally there we
Original PR description
web push payloads currently get their body truncated when the payload comes out to more than 4096 bytes. However this only keeps the plaintext payload under that limit, not accounting for encryption.…
web push payloads currently get their body truncated when the payload comes out to more than 4096 bytes. However this only keeps the plaintext payload under that limit, not accounting for encryption. As we need the payload to be 4096 bytes at most *after encryption* the threshold for body truncation is reduced to around 3990 bytes to account for the fixed overhead of encryption as laid out in the added constants and getters so that they can be adjusted as needed. Additionally there were some issues with the logic for truncation: - Checking character length against byte length for the comparison, which led to potentially a lot more truncated text than necessary. - Truncation being done with the assumption the text would be encoded in utf-8 when it is actually transformed to json unicode escape sequences (see ensure_ascii argument in json.dumps) again making the truncation inaccurate. - The calculation of body_max_length was incorrect, as it allowed for negative values which sometimes resulted in an empty body. Steps to reproduce: 1. Activate desktop notifications. 2. Fastest way will be to send to an account A (with activated notis), a message through discuss from an account B. 3. Additionally this affects the current flow too: 3.1 When we try to notify a user following a heldesk team. 3.2 We create an alias and set this to that current team. 3.3 We simulate an email to that heldesk team, eg vip-support@test.com opw-3939019 Forward-Port-Of: odoo/odoo#207848 Forward-Port-Of: odoo/odoo#193641
Currently, when a loyalty program has expired, loyalty card are still getting created even though points are not granted. Steps to reproduce: ------------------- * Create a loyatly program and make it sot that is has already expired * Open pos and make an order selecting any customer * Go to the backend and check the loyalty program > Observation: 1 card has been created with 0 points Why the fix: ------------ Not loading the expired programs prevent the creation of loyalty cards.
Original PR description
Currently, when a loyalty program has expired, loyalty card are still getting created even though points are not granted. Steps to reproduce: ------------------- * Create a loyatly program and make it sot that is has already expired * Open pos and make an order selecting any customer * Go to the backend and check the loyalty program > Observation: 1 card has been created with 0 points Why the fix: ------------ Not loading the expired programs prevent the creation of loyalty cards. Using the same logic as module `sale_loyalty` https://github.com/odoo-dev/odoo/blob/5acb89b8ba9be0e18bca65e26c03f47199fcfb4b/addons/sale_loyalty/models/sale_order.py#L461-L465 opw-4671522 Forward-Port-Of: odoo/odoo#208602 Forward-Port-Of: odoo/odoo#208134
A mismatch between backend and frontend caused the time displayed in the grid to be incorrect. The cell value was doubled due to a frontend-only calculation, but the actual data was correct on the backend. Refreshing the page fixed the display issue. Steps to reproduce: ------------------- * Open the view form of a timesheet cell (🔍) * Start the timer in the Hours Spent column * Go back to My Timesheets * Stop the timer > Observation: timer displayed was previous_timer * 2 + new_tim
Original PR description
A mismatch between backend and frontend caused the time displayed in the grid to be incorrect. The cell value was doubled due to a frontend-only calculation, but the actual data was correct on the backend. Refreshing the page fixed the display issue. Steps to reproduce: ------------------- * Open the view form of a timesheet cell (🔍) * Start the timer in the Hours Spent column * Go back to My Timesheets * Stop the timer > Observation: timer displayed was previous_timer * 2 + new_timer Why the fix: ------------ 'stopTimer()' waits for the orm call 'action_timer_stop' to return a value that will be added to the current cell value. opw-4701396 Forward-Port-Of: odoo/enterprise#84658 Forward-Port-Of: odoo/enterprise#84416
BUR-REE and inhouse id can not coexist in the xml scheme Forward-Port-Of: odoo/enterprise#84797
Original PR description
BUR-REE and inhouse id can not coexist in the xml scheme Forward-Port-Of: odoo/enterprise#84797
A `CheckViolation` traceback occurs when uploading an XML file that lacks the `Nombre` attribute. **Steps to Reproduce:** - Install `l10n_mx_edi` module - Navigate to `Accounting>Vendors>bills` try to upload [this](https://drive.google.com/file/d/1DRON2ftkDhwASqy_OFi9FtUNj7tODyKm/view?usp=sharing) `[demo file]` **Error:** `CheckViolation: new row for relation 'res_partner' violates check constraint 'res_partner_check_name'` **Root Cause:** - The `Nombre` attribute in the XML file is
Original PR description
A `CheckViolation` traceback occurs when uploading an XML file that lacks the `Nombre` attribute. **Steps to Reproduce:** - Install `l10n_mx_edi` module - Navigate to `Accounting>Vendors>bills` try…
A `CheckViolation` traceback occurs when uploading an XML file that lacks the `Nombre` attribute. **Steps to Reproduce:** - Install `l10n_mx_edi` module - Navigate to `Accounting>Vendors>bills` try to upload [this](https://drive.google.com/file/d/1DRON2ftkDhwASqy_OFi9FtUNj7tODyKm/view?usp=sharing) `[demo file]` **Error:** `CheckViolation: new row for relation 'res_partner' violates check constraint 'res_partner_check_name'` **Root Cause:** - The `Nombre` attribute in the XML file is missing, which results in the `name` field being set to `None` at [1] in the `partner_vals` dictionary. [1]- https://github.com/odoo/enterprise/blob/1d06bf93a2be03e969a5fce134b7323a70b2aef1/l10n_mx_edi/models/account_move.py#L2504 - The `res.partner` model has a database constraint (**res_partner_check_name**) that requires the `name` field to be non-null. When attempting to create a `partner` with a None value for `name`, the database raises a **CheckViolation error**. **Solution:** - Added a check in the `_l10n_mx_edi_import_cfdi_fill_partner` method to handle cases where the `Nombre` attribute is missing. - This prevents the creation of a partner with an invalid `name` field and avoids the **CheckViolation error**. sentry- 6546905710 Forward-Port-Of: odoo/enterprise#83776