Wednesday, April 1, 2026
51 changes · 19.0
Resolved issues and error corrections
This update corrects a bug where payroll-related planned actions (Dimona and Part Time registrations) were being triggered for all new employees regardless of their country. The fix ensures these actions now 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 Forward-Port-Of: odoo/enterprise#111788
This update fixes an issue with how tax closing journals are configured in the accounting system. The fix ensures that tax closing journals are properly set up when creating or updating company chart templates, which helps prevent errors during tax period closing processes.
Fixed an issue preventing Field Service users from adding customers to tasks. When users attempted to assign a customer to a task, the system was blocking the action due to insufficient permissions. The fix allows Field Service users to complete this common workflow while maintaining proper security controls through permission-based restrictions.
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 fix resolves an issue where the "Load more" line in financial reports was being incorrectly hidden when the "Hide lines at 0" option was enabled. The update ensures that "Load more" lines remain visible even when zero-value lines are hidden, allowing users to access additional data as needed.
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
Demo Stripe accounts were staying in a restricted state and couldn't be automatically verified due to a document requirement issue. This fix enables users to test the Stripe payment feature in demo mode by adjusting how account verification requirements are handled, allowing the feature to be properly tested before the permanent solution is implemented.
Original PR description
Step to reproduce: - Click on Connect (demo) - The accounts stay Restricted (even after 5m) This is due to the requirement `company.verification.document` which is present as a pending_verification even when no document is given. Giving it a document such as `file_identity_document_success` which should "marks that document requirement as satisfied" also doesn't work. A work-around is to set the business type to individual since they dont have this requirement. This is a temporary fix, as we want to keep a flow similar to what would have been done in reality. But this is preventing users from testing the feature in 19.0 up to master.
This fix resolves an error that occurred when users tried to undo a rescheduled calendar event in the Resource Booking feature. The system was attempting to save invalid data to the database, causing the undo operation to fail. With this fix, users can now successfully undo calendar event changes without encountering errors.
Original PR description
Currently, an error occurs when user tries to undo a calendar event. Steps to replicate: - Install `appointment` with demo data. - Navigate to `Appointments > Schedule > Resource Booking`. - Drag to…
Currently, an error occurs when user tries to undo a calendar event. Steps to replicate: - Install `appointment` with demo data. - Navigate to `Appointments > Schedule > Resource Booking`. - Drag to create a calendar event. - Reschedule the event to a later time (drag and drop forward). - Click Undo on the notification that appears. Error: `ValueError: Invalid field 'originId' in 'calendar.event'` `KeyError: 'originId'` Cause: - The key `originId` was patched in the `getschedule()` [1] and later when user tried to undo the calendar event, the [fallbackschedule] included the key `originId` and made an [orm] call with it. - The [line] tries to write the data into the database where `originId` field doesnt exist and causes the error to occur. Solution: - Remove the `originId` key from `fallbackdata` before the orm call. [1]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/appointment/static/src/views/gantt/gantt_renderer.js#L110-L116 [fallbackschedule]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1425 [orm]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1473-L1477 [line]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/models/models.py#L248 sentry-7020359653 Forward-Port-Of: odoo/enterprise#100570
The barcode scanning app was crashing when users tried to confirm quantities for archived products. This fix ensures archived products are included in search results, allowing users to successfully add and confirm quantities without errors, maintaining consistent behavior across the app.
Original PR description
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to…
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to Settings and enable Multi-Step Routes > Set Warehouse Routes. - Configure 2 steps for outgoing shipments. - Go to Inventory and create a new delivery with - **Source Location:** WH/Stock - **Product:** [E-COM10] Pedal Bin with demand 1 - Mark as Todo then Archive the Pedal Bin product. - Open that delivery in barcode app - Pencil icon > +1 > Confirm ## Observed behavior: TypeError: Cannot read properties of undefined (reading 'qty_available') ## Root cause: After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above. ## Solution: Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error. It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button followed by validation, ensuring consistency. [commit]: https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 [2]- https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45 opw-5980428 Forward-Port-Of: odoo/enterprise#112495 Forward-Port-Of: odoo/enterprise#109204
This fix corrects how shifts are split when using the daily view in the planning schedule. Previously, splitting a shift within a single day would incorrectly snap the resulting shifts to standard working hours (8am-5pm), creating duplicate time entries outside the original shift. Now, shifts split within a day are correctly divided at the exact requested time without adding extra hours.
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 resolves an issue where uploading empty XML files would cause the system to crash with an error. Users can now upload empty XML files without encountering errors, and the system will gracefully skip PDF extraction when file content is missing. This improves the reliability of the document upload process.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999 Forward-Port-Of: odoo/enterprise#103801
This fix resolves a system error that occurred when creating employee contracts with work schedules that have zero working hours. Previously, the system would crash when trying to calculate hourly wages in these cases. Now the system handles this scenario gracefully, allowing users to create and manage contracts without interruption.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930 Forward-Port-Of: odoo/enterprise#112450 Forward-Port-Of: odoo/enterprise#111629
Fixed an issue where scanning a barcode with a different serial number than the reserved one would incorrectly use the original reserved serial number instead of creating a new lot. Now when processing batches in barcode mode, if a scanned serial number doesn't match the reserved one, the system correctly creates a new lot as configured, ensuring accurate inventory tracking.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921
Forward-Port-Of: odoo/enterprise#112210
Forward-Port-Of: odoo/enterprise#109671This fix resolves an issue where shifts in the Planning module remained in draft status even after a rental order was created and confirmed. The shift status now correctly updates to published immediately when a new rental order is created, ensuring the Planning view accurately reflects the current state of shifts and maintaining consistency with other order creation methods.
Original PR description
**Issue 1** **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in Planning it is still in draft. **Issue:** The shift stays in draft even after the rental order is confirmed. **Cause** When creating a rental order from a shift, the shift is not marked as planned. It only gets linked to the order after saving, so it never updates its status. **Fix:** Mark the shift as published when confirming a new rental order. This makes the shift show the correct status right away and keeps it consistent with the “Add to Last Order” button. task-5075839 Forward-Port-Of: odoo/enterprise#99642
This update corrects how the Spanish tax report (Form 347) calculates and displays partner transaction amounts. Previously, negative amounts were incorrectly hidden from the report, and insurance operations were only partially tracked. Now the report correctly shows all partners with significant transactions regardless of whether amounts are positive or negative, and properly separates insurance sales and purchases into distinct sections.
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 how payment installments are ordered in Peru's electronic invoicing system (EDI). Previously, when invoices had multiple payment installments with different due dates, they could appear in the wrong order in the electronic document if they weren't created in chronological sequence. Now installments are automatically sorted by their due date, ensuring the correct payment schedule is always transmitted to tax authorities.
Original PR description
**Steps to reproduce:**
* Install `l10n_pe_edi`.
* Set SUNAT as the signature provider.
* Create a customer invoice.
* Select a payment term with multiple installments (e.g. 50% (15 days) / 30% (10 days) / 20% (5 days)).
* Confirm the invoice and generate the EDI standard UBL document.
**Observed behavior:**
* The XML `<cac:PaymentTerms>` instalment nodes (Cuota001, Cuota002, etc.) are ordered according to the database insertion order of the receivable lines.
* If the payment term lines are created in a non-chronological order, the installments in the XML mix up the `Cuota` ID, amount, and `PaymentDueDate`.
**Cause:**
* `_add_invoice_payment_terms_nodes` iterates over `invoice.line_ids` to generate the installments, but does not sort the receivable account lines by their `date_maturity`.
**Fix:**
* Explicitly call `.sorted('date_maturity')` on the receivable lines before generating the `invoice_date_due_vals_list`.
opw-6035589This fix ensures that when you change the salesperson assigned to a subscription, the update automatically applies to all contact records associated with that company, not just the main company record. This keeps customer information consistent across the system 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
Subscription products with zero price on the product form but priced through pricelists can now be added to the cart when the "Prevent Sale of Zero Priced Product" setting is enabled. The fix ensures the system correctly checks pricing information from subscription plans when validating whether a product can be purchased.
Original PR description
A subscription product that has a price of zero on the product form and the price is set on the pricelist instead cannot be added to the cart when the `Prevent Sale of Zero Priced Product` setting is…
A subscription product that has a price of zero on the product form and the price is set on the pricelist instead cannot be added to the cart when the `Prevent Sale of Zero Priced Product` setting is enabled Steps to reproduce: 1. Install eCommerce and Subscriptions 2. Go to Settings and enable `Prevent Sale of Zero Priced Product` 3. Go to Subscriptions > Products and create a new product "subscription" with Sales Price $0.00 and publish it to the website 4. Go to Subscriptions > Pricelists and edit pricelist "Benelux" 5. In the Recurring Prices tab, create a new entry for product "subscription" with a Fixed Price of $20.00 and a monthly Recurring Plan 6. Log in as portal user, go to the shop and look for "subscription" (pricelist "Benelux" should be selected) 7. Try to add it to the cart 8. Nothing happens and an error is displayed in the log Issue: When we check if a product can be added to the cart https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/controllers/cart.py#L116-L120 we do not use the plan_id specified in kwargs We reach this code https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/models/product_product.py#L146-L147 which will prevent the addition of a product in the cart if the option `prevent_zero_price_sale` is enabled and if `_get_contextual_price` returns zero Calling `_get_contextual_price` tries to find a `product.pricelist.item` by building a domain in `_get_applicable_rules_domain` but calling this method without a plan_id eventually reaches https://github.com/odoo/enterprise/blob/252c5ab78b51d0d2f06178cf92f0489b4a46958f/sale_subscription/models/product_pricelist.py#L69-L72 which restricts the domain to pricelists that are not subscription plans Therefore, we cannot find any pricelist that applies to the product and we consider that the product cannot be added to the cart Solution: We need to use the plan_id selected by the customer in order to correctly check if a product can be added to the cart. Use the plan_id in kwargs to update the request context so we can check if a product can be added to the cart according to the plan_id the user has selected. Use this plan_id in `_get_applicable_rules` in order to correctly select the applicable `product.pricelist.item`. opw-5993614
This fix resolves two issues when setting up recurring prices for subscription products in a multi-company environment. Users can now successfully add recurring price lines without encountering company inconsistency errors, and recurring plans with specific company assignments now appear correctly in the selection list.
Original PR description
## Issues When adding a line in the *Recurring prices* tab (`product.pricelist.item`) of a product with a `company_id`, a "company inconsistencies" error appears. Also, recurring plans with their…
## Issues When adding a line in the *Recurring prices* tab (`product.pricelist.item`) of a product with a `company_id`, a "company inconsistencies" error appears. Also, recurring plans with their *Company* field set do not appear in the list of recurring plans when adding a line in the *Recurring prices* tab. ## Steps to reproduce 1. Install *Subscription* (`sale_subscription`) 2. Create a second company 3. Create a subscription product and set a company in the *Company* field (`company_id`). 4. In the *Recurring prices* tab, add a line (any recurring plan, any price) 5. **An _Invalid Operation_ error appears: _"Uh-oh! You’ve got some company inconsistencies here"_** For the second issue, after the same 3 first steps: 1. Create a *Recurring Plan* RP with its *Company* field set to the current company 2. On the *Recurring prices* tab of the subscription product, try to add a line with the Recurring plan RP 3. **The Recurring plan RP is missing from the list of available plans.** ## Cause When adding a line to the *Recurring prices* tab, a new `product.pricelist.item` is created, with no `pricelist_id`. The `ProductPricelistItem._compute_company_id` from `sale_subscription` filters out the items that don't have a `pricelist_id`, which is the case for the line we create. Also, the (potentially new) plan has no `company_id` in most cases. https://github.com/odoo/enterprise/blob/ccab0c261040ed995d12dca891caae9596bbe1eb/sale_subscription/models/product_pricelist_item.py#L18-L26 By filtering the items with no `pricelist_id`, nothing is passed to the `super()._compute_company_id`, even though it would also handle cases where the item has a `product_tmpl_id`: https://github.com/odoo/odoo/blob/9c8112d794af1ba84ade8af124967495c2ff8995/addons/product/models/product_pricelist_item.py#L170-L173 opw-5981629 opw-6051978
This fix prevents the system from unnecessarily recalculating product costs (COGS) when an invoice is reset or cancelled. Previously, resetting an invoice would trigger a full cost recomputation, which could cause performance issues and incorrect cost calculations. This change ensures costs are only recalculated when actually needed.
Original PR description
test et commit msg à faire
Users encountered an access rights error when creating private tasks with no project or assigned users. This fix automatically assigns the task creator as a user when creating a private task, ensuring they have proper access to their own tasks. This resolves the frustrating error that prevented users from creating standalone private 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 prevents the system from automatically changing document dates when the tax supply date is modified on already-posted accounting entries. Previously, the system would automatically align dates for all documents, but this created issues with Czech tax regulations that allow late tax deductions where dates should not be automatically synchronized. Users can now manually adjust dates when needed.
Original PR description
Description of the issue/feature this PR addresses: This automatic date alignment make sense in case of new document, but when you work on document that was posted. User should change it manually. In Czech republic we have something like late tax deduction and in this case there is not alignment of dates. Current behavior before PR: When you change taxable_supply_date it automatically change date Desired behavior after PR is merged: Disable this calculation od moves that hase been posted. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project users encountered an error when trying to add a customer to a task. This fix resolves the access issue by improving how the system handles customer information updates, ensuring project users can now successfully create and manage tasks with customers assigned.
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
This update fixes an issue where the virtual keyboard would automatically open when users interact with dialog windows on touch devices like tablets and phones. The fix keeps the dialog's focus protection active while preventing the keyboard from appearing, improving the user experience on mobile devices.
Original PR description
Commit 1 addressed an issue where the virtual keyboard would pop up unexpectedly when navigating on touch devices. However, due to commit 2, opening a dialog traps the focus in the dialog and automatically focuses on the first element. On touch screens, this behavior triggers the virtual keyboard. This commit changes the behavior so that, on touch devices, the focus is on the main part of the dialog instead of the first input field. This prevents the virtual keyboard from opening while ensuring the focus trap remains active. opw-5970020 1: https://github.com/odoo/odoo/commit/9d8f9d90743490c37a89fa71be087d38924164e7 2: https://github.com/odoo/odoo/commit/cd624c891f356c0527f5bb75cdfe1e05b7b79a21
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 account even though it matched the search criteria. This fix ensures that account code searches work correctly regardless of whether an account is active or archived.
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#256060This fix resolves a critical bug in the purchase order system where an outdated field reference was causing purchase orders to fail during confirmation. A previous system update renamed a field but left behind an old reference, which has now been corrected to ensure purchase orders can be confirmed without errors.
Original PR description
A big refactor of UOM in saas-18.1 (https://github.com/odoo/odoo/pull/184131) accidentally left a reference to the `product_uom` field on `purchase.order.line`. But that field was renamed to `product_uom_id` in https://github.com/odoo/odoo/pull/186250. In rare edge-cases, if we it `supplierinfo['product_uom_id'] = line.product_uom.id` while confirming a purchase order, it will block it because of a traceback: ``` supplierinfo['product_uom_id'] = line.product_uom.id ^^^^^^^^^^^^^^^^ AttributeError: 'purchase.order.line' object has no attribute 'product_uom'. Did you mean: 'product_id'? ``` This PR fixes the issues by accounting for the field rename. OPW-6068125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256768 Forward-Port-Of: odoo/odoo#256416
This update fixes how URLs are processed and displayed in email messages. Previously, URLs could appear differently to users due to encoding and decoding issues. The fix uses a more reliable method to handle URL formatting, ensuring that the URL a user sends is exactly what appears in the message.
Original PR description
Before this commit, the URL was fully encoded using encodeUrl. This commit replaces this approach with the more modern [URL api](https://developer.mozilla.org/en-US/docs/Web/API/URL), which [handles encoding](https://url.spec.whatwg.org/#dom-url-href) properly. This commit also removes decodeUrl. It was possible for a user to send a URL and have a different one displayed in the UI due to decoding. Task-6041689 Forward-Port-Of: odoo/odoo#256650 Forward-Port-Of: odoo/odoo#254383