Daily updates from Odoo
Wednesday, April 1, 2026
29 changes · saas-18.4
Resolved issues and error corrections
This update fixes two issues in the Dutch tax reporting module. First, it corrects a bug where the wrong user identifier was being used when adding followers to tax documents, which caused incorrect people to receive notifications. Second, it improves the automated tax status processing to ensure all records are properly handled instead of only the last one.
Original PR description
The method call that is supposed to subscribe the current user to the closing entry when posting XBLR used the User id as a Contact id. This caused random contacts to be added as followers of the chatter thread and as a result receiving notifications for it. The fix is simply using the id of the User's Contact instead. Also, as discussed with prro on Discord, fixed the cron clearing its dictionary each loop. opw-5886621 Forward-Port-Of: odoo/enterprise#107843
This fix corrects an error in Pakistan payroll tax calculations that was causing employees with yearly salaries over 2,200,000 PKR to be charged excessive taxes. The tax calculation was incorrectly accumulating amounts across tax brackets instead of resetting properly at each bracket level, resulting in overstated tax amounts. This fix ensures employees are taxed correctly according to Pakistan's official tax bracket rules.
Original PR description
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install…
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install `l10n_pk_hr_payroll_account`,`hr_contract_salary` with demo data. 2) Switch to PK company. 3) Create an employee and a running contract with yearly cost 2,200,001 4) Create a payslip and compute it from the Salary Computation tab. ### **Observed Behavior:** 'Tax Bracket Yearly' is computed as `122000.24` ### **Expected Behavior:** 'Tax Bracket Yearly' should be `116000.24` ### **Root Cause:** since [commit](https://github.com/odoo/enterprise/pull/98345/commits/62f5e216518d83317618d7dbc0be4db92d1881a3), the tax computation relies on [_l10n_pk_get_tax](https://github.com/odoo/enterprise/blob/a9656336583a4d5c5b12d4d6120ec62ba1cf9151/l10n_pk_hr_payroll/models/hr_payslip.py#L9-L20) , In this method, the `result` is incorrectly accumulated with `fix` when iterating through brackets, leading to an inflated tax value. [official pakistan document](https://download1.fbr.gov.pk/Docs/20258181281745641WHT-RateCard.pdf) ### **Fix:** Use `result = fix` instead of `result += fix` so that the cumulative tax is correctly reset at each bracket. **opw-5979265** Forward-Port-Of: odoo/enterprise#110939
Fixed an issue where subscription product billing periods were not showing when products were displayed as cards on website pages. The billing period information is now properly included when products are added to pages using the website editor, ensuring customers see complete pricing details just like they do on the shop page.
Original PR description
Steps to reproduce: 1) Go to the Website app. 2) Add a product snippet to any page using the editor. 3) See product card of any subscription product. Issue: - The billing period is not displayed for subscription products in the product snippet, unlike on the shop page. Cause: - `temporal_unit_display` is not included in the `combination_info`which is passed in data used by the product snippet. Fix: - Include `temporal_unit_display` in `combination_info`. opw-6070943 Forward-Port-Of: odoo/enterprise#112171
Fixed an error that prevented Field Service users from adding customers to tasks. The issue occurred when the system tried to update customer phone information without proper permissions. The fix allows Field Service users to complete this common task without encountering access errors.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only "Field Service > User" access. 2. Create a new task in an field service project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Field service users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Used sudo() in the inverse method to update the partner phone securely, bypassing restricted access. task-5039657 Forward-Port-Of: odoo/enterprise#112549 Forward-Port-Of: odoo/enterprise#93969
This update fixes an issue where the "Load more" line in financial reports was being incorrectly hidden when users enabled the "Hide lines at 0" option. The fix ensures that the "Load more" line remains visible so users can access additional data, while still properly hiding rows with zero values as intended.
Original PR description
When activating the 'Hide if 0' option, the 'Load more' line is hidden. Fix: Filtering out the lines with empty columns (Load more lines) from the zero lines. Steps: - Open GL (occurs with other reports as well), and open configuration for this report - Set Load more limit to 1, and hide if zero to optional - Go back to GL report and select the 'Hide lines at 0' option -> Load more lines are hidden as long as the zero lines opw-5953725 Forward-Port-Of: odoo/enterprise#109380
Fixed an issue where splitting a shift within a single day in the planning calendar was incorrectly snapping to standard working hours, causing duplicate shifts with wrong timeframes. Now when splitting a shift in the daily view, it correctly divides at the exact time requested without adding extra hours outside the original shift.
Original PR description
Since odoo/enterprise#69963, splitting a shift in Gantt view snaps the resulting shifts to the standard working hours (e.g., 08:00 to 17:00). This behavior makes sense when splitting a multi-day shift across a day off, where we want to generate a full working day for the day off as well. However, when splitting a shift within a single day (day scale), this behavior is not wanted, otherwise creating two shifts as follows: 1. A shift from [Original Start] to 5pm 2. A shift from 8am to [Original End] Clearly, the shift is duplicated with the wrong timeframes and adding time outside the original shift's hours. This commits ensures that, when splitting a shift in hours (i.e., when using `day` view scale), the shift is appropriately split at the time requested. For instance: 1. A shift from [Original Start] to [Split Time] 2. A shift from [Split Time] to [Original End] task-5387243 Forward-Port-Of: odoo/enterprise#105991
This fix ensures that when scanning barcodes from the main menu, the system uses the correct company's barcode nomenclature (such as GS1) instead of defaulting to the user's primary company. This resolves issues where valid barcodes were not being recognized when working with multiple companies that have different barcode formats.
Original PR description
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong…
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature. ### Steps to reproduce: - Have 2 companies: company 1 and company 2 - Set the barcode nomenclature of company 1: default, company 2: GS1 - Incarnate a user allowed in both companies but with default company 1 - With company 2, create a product and set its barcode to 36939282410106 - From the main menu open the barcode app and scan 0136939282410106 #### > No product was found (even thought it is correct in GS1) ### Cause of the issue: Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11 As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083 based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722 ### Fix: Setting the company slices the `current_company` in first position of the `allowed_company_ids`: https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81 which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491 Note that passing the context in the arguments of the `main_menu` JSON route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f ### Additional Issue: The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56 ### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set the barcode nomenclature to GS1 - Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365 - From the main menu open the barcode app and scan 4133033710074365 #### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination) opw-5847529 Forward-Port-Of: odoo/enterprise#112302 Forward-Port-Of: odoo/enterprise#111662
This update fixes a technical error that occurred when importing sales orders with subscription discounts into the Point of Sale system. The fix ensures subscription discount lines are properly handled as notes during the import process, preventing the system from crashing when using subscription features with POS.
Original PR description
This is a test for the related community fix and an override of the **isSaleOrderLineNote** method to add the subscription specific **subscription_discount** lines to be treated as a note when importing it from the Sales module. https://github.com/odoo/odoo/pull/247846 opw-5582448 Forward-Port-Of: odoo/enterprise#107002
This update corrects two critical issues in Spain's Form 347 tax reporting. First, it now properly shows partners with negative amounts below the -3,005.06 € threshold, which were previously hidden. Second, it separates insurance operations into distinct Sales and Purchase sections, ensuring amounts from both transaction types are correctly reported in their respective categories.
Original PR description
Before this PR: - Partners were only shown if their total was positive and above 3,005.06 €. Negative totals were hidden, even if they were lower than -3,005.06 €. - Insurance operations only took Purchase journal amounts into account. Amounts from Sales journals were ignored, and there was no distinction between the two types of operations. After this PR: - The report now uses the absolute value of the total. Partners with amounts exceeding 3,005.06 €, whether positive or negative, are now shown correctly. - Insurance operations are now divided into two distinct sections: Sales and Purchases. Amounts from both Sales and Purchase journals are now correctly taken into account and reported in their respective sections. task-5214023 Forward-Port-Of: odoo/enterprise#112136 Forward-Port-Of: odoo/enterprise#100413
This fix corrects a bug where users could incorrectly change the "Recurring" setting on subscription products that have confirmed sales orders. The system now properly prevents these changes and displays the correct warning message, ensuring data integrity for subscription products.
Original PR description
**Problem:** When attempting to change "Recurring" on products in the form view, if there are confirmed SOs, the change should be reverted and a message should appear explaining this. However, there is a bug in how the change is reverted where it takes the current form value of the field. This cannot be trusted as it's possible to trigger another onchange before the first one resolves, so the second onchange is based on the wrong value. **Steps to Reproduce:** - w/Demo Data, go to product "Office Cleaning Service (SUB)" (This is a subscription product which has confirmed SOs) - Quickly click the checkbox for "Recurring" twice -> Two warnings appear, but Recurring is False and can be saved **Solution:** Instead of reading the current form value and setting its opposite, we can revert to the current value on the server. Forward-Port-Of: odoo/enterprise#110877
This fix ensures that when you change the salesperson assigned to a subscription, the update automatically applies to all contacts associated with that company, not just the main company record. This keeps customer information consistent across the portal and eliminates the need for manual updates to individual contacts.
Original PR description
Before this commit, changing the salesperson on a subscription only updated the company partner, leaving child contacts with outdated salesperson info. After this commit, updating the subscription's salesperson also updates all child contacts of the company, ensuring consistency across the portal and reducing manual work. An unit test was added to ensure this behavior. task-5917271 Forward-Port-Of: odoo/enterprise#111499 Forward-Port-Of: odoo/enterprise#108339
This fix corrects an issue where Belgian payroll actions (Dimona and Part Time registrations) were being triggered for all new employees regardless of their contract country. Now these actions only apply to employees with Belgian contracts, preventing unnecessary processing for non-Belgian staff.
Original PR description
Previously, planned actions (Dimona/Part Time) were triggered for all new employees with a contract start date, regardless of country. Now, the trigger is filtered to only apply to Belgian contracts. task-5942339
This fix ensures that when an employee's first or last name is updated in the Swiss payroll system, the legal name field used for payslips is automatically recalculated. Previously, payslips were showing outdated employee names because the legal name field wasn't being refreshed when names were changed.
Original PR description
## Issue When using the Swiss localization, updating the *First Name* and/or *Last Name* on an employee's page does not update the `hr.employee.legal_name` field. It is an issue, as that field is the…
## Issue
When using the Swiss localization, updating the *First Name* and/or *Last Name* on an employee's page does not update the `hr.employee.legal_name` field. It is an issue, as that field is the one used when creating payslips.
## Steps to reproduce
1. Install *Switzerland - Swissdec Certified ELM 5.0 - Payroll* (`l10n_ch_hr_payroll`) and create a Swiss company
2. Create an Employee
- Company: Swiss company
- Name: "LastName FirstName"
3. In the *Personal* tab, the *First Name* and *Last Name* are filled with the given first and last names. This also sets the (hidden) `hr.employee.legal_name` field to *"LastName FirstName"*
4. Modify the *First Name* and/or the *Last Name* field(s) to any new name(s)
5. In Payroll > Payslips > Payslips, create a new Payslip
- Employee: FirstName LastName
6. **The name given to the Payslip is wrong, it uses the initial `legal_name` (_"LastName FirstName"_)**
## Cause
In 18.0, the `hr.employee.legal_name` was updated by the `_compute_legal_name` overridden in `l10n_ch_hr_paryoll_elm_transmission`.
https://github.com/odoo/enterprise/blob/2953e5cd7666bd45547f26863253f107473aed0b/l10n_ch_hr_payroll_elm_transmission/models/hr_employee.py#L176-L184
That module was removed in 18.4, and the behavior updating the `legal_name` was lost.
opw-5882222This update adds support for three new fields (price, currency, and support) in the app manifest validation for Odoo's app store. These fields are now recognized as valid manifest keys, allowing app developers to properly list pricing and support information when publishing apps to the Odoo marketplace.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256726 Forward-Port-Of: odoo/odoo#255857
This fix corrects undefined variables in the website store editor that were causing preview elements to display incorrectly. When customizing store layouts, certain design elements like placeholder rectangles were not showing properly. This update ensures all editor previews render with the correct styling and appearance.
Original PR description
The editor previews are not having the expected design due to the `c` and `p` variables being undefined. Steps to reproduce for eg. filmstrip: - Disable the `categories_opt_top` (Categories: top) - Hover the "Top" editor button - See the filmstrip is missing it's placeholder rectangle "text" due to the width style not being applied. task-6047816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255339
This update fixes a bug in the Jordan electronic invoice system where refunds with multiple identical product lines were not being processed correctly. The system now properly matches each refund line to the correct invoice line, preventing duplicate matches and ensuring accurate credit note processing.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
Optional product tables in sales reports were not displaying with the correct styling due to DOM structure differences. This fix applies the proper table styling to ensure optional products appear consistently formatted in sales documents. Users may need to update their document layout settings for color changes to take effect.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
Users can now successfully search for archived accounts by their account code. Previously, when filtering for inactive accounts and searching by code, the system would not display the archived records because the search logic was only looking at active accounts. This fix ensures that archived accounts are properly included in search results when users specifically filter for them.
Original PR description
# How to reproduce - Go to the chart of account - Archive any record (e.g. Code 101401) - Search with the filters : - Inactive Accounts - Account: 101401 (the code of the record) # The problem The…
# How to reproduce
- Go to the chart of account
- Archive any record (e.g. Code 101401)
- Search with the filters :
- Inactive Accounts
- Account: 101401 (the code of the record)
# The problem
The record that we searched for is not shown
# Cause
The domain for the "Account" filter is the following : https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L147
And this is the domain for "Inactive Accounts":
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L159
This is correct and the search should return what we wanted, but the code's search is overriden by:
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/models/account_account.py#L383-L384
And the search with the `code_store` domain only explicitely looks for accounts that are active, so our "[('active', '=', False)]" is essentialy ignored
This is fixed in 19.1 because this commit (https://github.com/odoo/odoo/commit/de959adf7c806e09864b52fec78d981e66804280) replaced the custom search by a `compute_sql`
# Proposed solution
We change the search with the `code_store` to look for records that are both active and inactive, since the active value will be handled by the parent search
opw-6059404
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#256060Fixed an error that prevented project team members from adding customers to tasks. The system now properly handles customer assignments without triggering permission errors, making it easier for project users to manage task details and customer relationships.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only Project > User access. 2. Create a new task in project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Project users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Added a check before writing to avoid unnecessary writes. - Used sudo() to update the partner phone securely. - Added view-level restriction using base.group_partner_manager to control who can edit the phone number. task-5039657 Forward-Port-Of: odoo/odoo#256755 Forward-Port-Of: odoo/odoo#252406
Users encountered an access rights error when trying to create private tasks (tasks with no project and no assigned users). This fix ensures that when a task is created as private, the creator is automatically assigned to it, giving them proper access rights. This resolves the frustrating error that prevented users from creating private tasks while maintaining the ability to modify existing tasks.
Original PR description
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear…
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task. 4.Create the private task. 5.An access rights error occurs, stating that the user does not have permission to create the record. ⚠️ Note: This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs. Root cause: When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation. This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users. Fix (implemented): Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing. To address this, we now require at least one user to be assigned to a task when it is not attached to a project. This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record Versions : 17.0 -> master Task [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242216
This fix resolves an issue where replacing the contact form on the /contactus page would cause submission errors. The problem occurred because the system was using email settings from the old form configuration even after the form was deleted and recreated. The fix ensures that email settings are only applied when the original form is still present, preventing mismatches during form submission.
Original PR description
Problem: There is a data-for span in the /contactus page that sets specific values on the page's form. If this form is deleted and a new form is added, an error will occur when trying to submit the new form. This is because the value set for website_form_signature will use the email set in the data-for, which will not match with the new form. Purpose: Modify the code that sets the website_form_signature value to ensure that the original form is present as well if using the data-for values. Steps to Reproduce in Runbot: 1. Use the Website Editor to delete the form on the /contactus page and create a new one. 2. Attempt to submit the new form. opw-5956030 Forward-Port-Of: odoo/odoo#253410
Mozambique users were seeing the incorrect Brazilian tax ID label "CPF/CNPJ" on their sales orders and invoices instead of the correct Mozambican label "NUIT". This fix adds the proper tax ID label for Mozambique so users now see the correct terminology on their business documents.
Original PR description
Currently the "Tax ID" title used e.g. on sales orders, invoices, etc. was translated as "CPF/CNPJ" in Portuguese, which is the tax ID used in Brazil. However, in Mozambique, the tax ID is called "NUIT", and there is no language variant for Portuguese in Mozambique. This caused Mozambique users to see "CPF/CNPJ" instead of "NUIT" on their documents, which was wrong. This commit adds a `vat_label` field for Mozambique to display the correct tax ID label. Issue reported by functional support. Forward-Port-Of: odoo/odoo#256603
This update improves the payment demo module by adding validation checks for provider configuration. The fix ensures that payment provider settings are properly validated before use, preventing potential errors and improving system reliability when processing demo payments.
Original PR description
opw-3097856 Forward-Port-Of: odoo/odoo#256362
Fixed a crash that occurred when users deleted text from a toggle list title in the To-Do application. The issue happened because the system tried to check properties of a non-existent element. This fix ensures the system only checks for the next element when it actually exists, preventing the crash and allowing users to delete toggle list titles without errors.
Original PR description
Steps to Reproduce: - Go to To-Do → Create New - Create a toggle list - Type something in the title - Press the delete button Description of the issue: - A traceback occurs. Cause: - In `handleDeleteForwardTitleEnd`, there is a check to verify whether the toggle title’s next sibling matches the toggle selector. However, when there is no next sibling, calling `matches()` results in a traceback. Solution: - Only check `matches()` if the next sibling exists. task-6040479 Forward-Port-Of: odoo/odoo#254557
This fix resolves an issue where the system was not checking archived accounts when validating account codes during unaffected earnings account creation. This was causing upgrade failures for companies using the Saudi Arabia localization module, where an archived account with code 999999 was triggering validation errors. The fix ensures archived accounts are properly considered to prevent false validation conflicts.
Original PR description
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived. Forward-Port-Of: odoo/odoo#256112
Fixed a crash that occurred when using Point of Sale to settle orders containing subscription products with discounts. The system was incorrectly trying to process discount information lines as regular order items, causing the application to crash. The fix treats these informational lines similarly to notes, preventing the error.
Original PR description
**Steps to reproduce:** - Make a subscription product - Make a quotation with it, confirm it, then invoice it - Go back to the sale order and upsell it - Add another product - Go to the PoS to settle the order - A traceback appears **Why the fix:** Why tried to treat the informative line that says that this is a discount as a normal pos order line. We then tried to access the line's template, which caused a crash as the line's template was undefined. We now treat the line as we do a note, meaning to add it to the previous line in the order. We create a function to check if the line is a note and we override it in the **pos_sale_subscription** module. Enterprise PR: https://github.com/odoo/enterprise/pull/107002 opw-5582448 Forward-Port-Of: odoo/odoo#247846
This fix corrects how buttons with custom sizes or shapes are displayed in the website editor's button styling panel. When buttons have size or shape customizations applied, they are now properly recognized as "custom" buttons, ensuring the editor shows the correct styling options to users.
Original PR description
Before this commit: Since the removal of button style options for the preset primary and secondary styling, the type of a primary/secondary button with size or shape defined in the class should be "custom". The fix is made to saas-18.4 cause the custom button option is removed in saas-18.3 and reintroduced only from saas-18.4. The button option removal commit: https://github.com/odoo/odoo/commit/a7b71d700e4997e4a2f646e2ae12f58f20058dc4 The button custom option reintroduction: https://github.com/odoo/odoo/commit/ea22b28bbae009c9eab4ff397affa9a3cb71037a After this commit: when the button has size or shape classes, we consider it as "custom" button. task-6061443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where PDF invoices containing embedded XML attachments organized in a nested structure were not being properly extracted, resulting in empty bills. The system now correctly handles both flat and nested PDF attachment formats, ensuring that invoice data is properly captured regardless of how the PDF organizes its embedded files.
Original PR description
Steps to reproduce: - From the accounting dashboard, upload a PDF containing intermediate /Kids nodes representing separate xml attachments Issue: No xml will be extracted, as result the bill will be empty. However, in the chatter pdf preview, the js pdf toolkit correctly show the xml attachemnts. Analysis: The PDF spec defines two ways to organize embedded files under /EmbeddedFiles in the document's name dictionary: - /Names: a flat array of pairs located directly under /EmbeddedFiles - /Kids: an array of child nodes, each of which carries its own /Names array. The extractor currently only handled the /Names case, not detecting embedded attachments in case of PDF using a /Kids tree. This change add lookup for both structures. opw-5929274 Forward-Port-Of: odoo/odoo#252523
Fixed a bug where gradient text colors were not properly removed when switching to solid colors in the note editor. Previously, when users applied a gradient color and then switched to a solid color, the gradient would incorrectly appear as a background color instead of being replaced. This fix ensures gradients are properly cleared in all cases.
Original PR description
Steps to reproduce: - Go to a To-do note - Select a word - Apply a gradient as the text color - Re-open the color picker - From the Solid tab, select the primary color (o-color-1) Description of the issue: - The gradient is not removed and ends up being displayed as a background color Cause: - In the `colorElement` method, the gradient is removed when applying a text color via inline styles. However, when applying a color via class (e.g., text-*), the gradient is not properly cleared. Only the text-gradient class is replaced, while the gradient style remains, causing it to appear as a background color. Solution: Ensure the gradient is removed in both cases: - when applying a color via class and when applying a color via inline styles in `colorElement`. task-6045533