Daily updates from Odoo
Friday, April 18, 2025
51 changes · 18.0
New functionality added to Odoo
This adds a custom product feature that makes external IDs visible in product lists and product forms, and allows users to search products by those IDs. It helps teams import bills of materials and inventory updates more efficiently without first exporting products to find system-generated identifiers.
Original PR description
# Description of the issue/feature this PR addresses: Our organization would like to manage the external ID of products (i.e. during product CSV upload) because this lets us later upload BoMs and inventory adjustments that reference this external ID. This avoid an extra step of first finding products in Odoo, downloading them to get their auto-generated external ID, and then re-uploading. # Current behavior before PR: External ID is hidden from the user # Desired behavior after PR is merged: 1. External ID is present on the product list page 2. External ID can be used for searching products 3. External ID is present on the General Information tab of the product form page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update lets authorized users import overtime approval status on attendance records instead of having it locked as read-only. It helps businesses bring in extra-hours data more reliably without the system automatically recalculating unapproved imported values.
Original PR description
overtime_status is currently readonly which prevents record importation of extra hours, since if they are not approved, the compute will get triggered
Adds placeholder text for the eInvoice format field on partner records. This helps users understand what information is expected when configuring electronic invoicing, reducing confusion during setup.
Original PR description
Add a placeholder for eInvoice format. task-4544834 (Part-of)
Resolved issues and error corrections
This update adjusts an internal holiday module test so it can create its required calendar setup with the right permissions. It helps keep automated testing stable without changing how employees or managers use the holiday features.
Original PR description
Creating a `resource.calendar` record requirest the settings group. This is only necessary for the setup of this test, so just create it in `sudo` (afterwards the calendar is only referenced to create events). https://runbot.odoo.com/odoo/error/145744
This fix reduces database strain when many accounting records receive sequence numbers in the same operation, such as batch journal posting, asset creation, or payment validation. It helps prevent transaction issues and improves reliability during large accounting workflows while preserving gapless numbering.
Original PR description
Creating many savepoints can lead to issues, not only in the current transaction, but also on other transactions from other connections on other databases[^1]. The `sequence.mixin` relies heavily on…
Creating many savepoints can lead to issues, not only in the current transaction, but also on other transactions from other connections on other databases[^1]. The `sequence.mixin` relies heavily on a unique constraint for giving a sequence without gaps[^2], which forces the use of savepoints because we expect the transaction to fail when assigning numbers with concurrent transactions. A previous commit removes savepoints created in a loop, which could happen when concurrency happens[^3], but there is still an issue when many records are getting a sequence number in the same transaction. This happens for instance when posting journal entries in batch (i.e. after an import), creating a `account.asset` in the past, or validating a batch payment with exchange differences. This commit is now caching the value as soon as the lock is held for a series in the sequence, and is now doing only one savepoint per series in the same transaction. [^1]: https://github.com/odoo/odoo/pull/71395#issuecomment-851440042 [^2]: c45998c8368c6feb3d574d6d3d0ad064faf21679 [^3]: 10565c6968a5d0f285f93c4bdc610350999a88e3
Employees on flexible working schedules now get accurate timesheet entries when they take time off. This prevents overstated absence hours, helping payroll, project tracking, and reporting reflect the expected daily hours.
Original PR description
**Issue:** When an employee's working hours are set to flexible Hours, and the employee takes time off, the Timesheet module displays incorrect hours instead of the expected hours per day, e.g. 11h instead of 8h **Steps to reproduce:** - In Employee, ensure Flexible Hours is set on the chosen employee’s working calendar - Time off > configuration > time off types > sick time off - Click the time‑off icon on top, create a new time‑off allocation for the same employee, and approve it. - Tmesheets > all timesheet Timesheet entries show incorrect hours for time off days opw-4715551
This fixes an issue where changing both the quantity and lot on a tracked inventory adjustment could create an extra negative valuation entry. Inventory valuation reports will now better reflect the real stock adjustment, improving accuracy for products tracked by lot with average cost valuation.
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot and avco valuated. - Put 10 units of that product in stock withtout set lot. - On the stock quant, click on history - Modify the…
### Steps to reproduce: - Create a storable product tracked by lot and avco valuated. - Put 10 units of that product in stock withtout set lot. - On the stock quant, click on history - Modify the inventory adjustment move to set a quantity of 3 and a lot. - Inventory > Reporting > Valuation #### > Stock valuation layer inconsistency: +10, -10, -7, +3 > the -7 should not be there ### Cause of the issue: If you change the quantity of a move line you will automatically reconcile the quantity difference because of these lines: https://github.com/odoo/odoo/blob/6f3f89f55ab67d39b2487fdf8220747f568b7eb0/addons/stock_account/models/stock_move_line.py#L34-L36 However, if you change the lot of your move line you already plan to conter balance the entire quantity of the previous lot because of these lines: https://github.com/odoo/odoo/blob/6f3f89f55ab67d39b2487fdf8220747f568b7eb0/addons/stock_account/models/stock_move_line.py#L37-L46 In partciular, the first reconciliation should not be performed in case we change both the quantity and the lot of the move line. opw-4685988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Journal Items unreconciled filter now hides entries with no residual amount, since those entries cannot be reconciled. This reduces confusion for accounting users by making the filtered list match the expected reconciliation workflow.
Original PR description
Description of the issue this commit addresses: Items with a null residual are not reconcilable but when using the unreconciled filter implying that shown items have to be reconciled, those items are not hidden which is confusing. --- Desired behavior after this commit is merged: Using the Unreconciled filter on Journal Items will filter out items that have a null residual. --- task-4723956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents draft point-of-sale orders from being sent to the server in standard retail setups. It avoids unintended order data being synced outside restaurant workflows, improving reliability for non-restaurant POS users.
Original PR description
Before this commit, draft orders were incorrectly synced to the server in non-restaurant PoS, causing several issues. This commit ensures that draft orders are only synced when the POS is in restaurant mode, preventing unintended behavior. opw-4624604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue that could cause an error when the system prepared placeholder names for multiple accounting entries at once. This helps avoid interruptions in accounting workflows when processing batches of records.
Original PR description
In the _compute_name_placeholder method, self.date is used inside the for move in self loop which causes a singleton error when self is a multiple records recordset. This commit replaces self by move to avoid the singleton error. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a mobile usability issue where the Start or Launch button in a Project dropdown only worked when tapping directly on the text. The full button area now responds to taps, making timer actions more reliable on mobile devices.
Original PR description
Reproduce: - Switch to mobile view - Go to Project module - Click on the gear icon next to a task or project - Click the Start (or Launch) button in the dropdown - Try tapping anywhere on the button…
Reproduce: - Switch to mobile view - Go to Project module - Click on the gear icon next to a task or project - Click the Start (or Launch) button in the dropdown - Try tapping anywhere on the button (not just on the text) Description of the issue/feature this PR addresses: In the mobile view of the Project module, clicking the Start button from the dropdown menu only works if the user taps directly on the text. Tapping on the surrounding area within the button does not trigger the action—instead, it closes the menu without starting the timer. Root cause: The button inside the dropdown is wrapped in a `<span>` element, but its width does not extend across the entire span. As a result, only the text area is interactive, which causes usability issues on mobile where precise tapping is harder. Solution: Ensure the button inside the dropdown item spans the full width of its container by setting `width: 100%`. This allows the entire area of the button to be clickable, improving usability on mobile devices. Desired behavior after PR is merged: Tapping anywhere on the button (not just the text) now consistently triggers the timer as expected. opw-4561724
Point of Sale now blocks a cash rounding option that can cause errors when closing a session. This temporary safeguard helps businesses avoid failed session closures until full support for that rounding method is ready.
Original PR description
Currently, when using a cash rounding method with the strategy `Modify tax amount` on a Pos config, an error message appears upon trying to close the session. Steps to reproduce: -------------------…
Currently, when using a cash rounding method with the strategy `Modify tax amount` on a Pos config, an error message appears upon trying to close the session. Steps to reproduce: ------------------- * Create a cash rounding method with strategy `Modify tax amount` * Open pos setting and apply the cash rounding method * Open pos session * Make an order that will trigger the cash rounding * Validate the order * Try closing the session > Observation: The operation cannot be completed: Missing required account on accountable line Why the fix: ------------ Prior to 18.0, the point of sale would only allow rounding methods using the strategy `add_invoice_line`. https://github.com/odoo/odoo/blob/786abeb0783461d555c4077b8258490a7aed8c21/addons/point_of_sale/models/pos_config.py#L302-L314 This constraint was removed in this commit to also allow using `biggest_tax` strategy: [8fb7e5f#diff-4c6e412c7d8f4df2a05831547e7df93d0b91f510d03b7b3ed0d689a18f5dae44](https://github.com/odoo/odoo/commit/8fb7e5fd304697aebcce085602a5f3a1ecaf757a#diff-4c6e412c7d8f4df2a05831547e7df93d0b91f510d03b7b3ed0d689a18f5dae44) This is a temporary fix bringing back the constraint has the pos wasns't fully ready to use it. It will be remove later when the integration is complete. opw-[4673618]
This fix prevents an error when Odoo calculates placeholder names for multiple accounting entries without a date. It improves reliability in accounting workflows by avoiding a crash that could interrupt users working with invoices or journal entries.
Original PR description
… 18/04/2025
Description of the issue/feature this PR addresses:
ERRER: File "/home/odoo/src/odoo/addons/account/models/account_move.py", line 915, in _compute_name_placeholder
if (not move.name or move.name == '/') and self.date and not move._get_last_sequence():
^^^^^^^^^
File "/home/odoo/src/odoo/odoo/fields.py", line 1232, in get
record.ensure_one()
File "/home/odoo/src/odoo/odoo/models.py", line 6255, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move(2620, 2606, 2592, 2584, 2582, 2580, 2578, 2576, 2574, 2572, 2564, 2550, 2536)
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-prExports now show translated labels for selection fields when the user's language is changed. This prevents users from seeing raw internal values in exported files, such as employee marital status in French.
Original PR description
Reproduce: 18.0 and 18.1 Switch your language to French Go to employee and export one record You will see not translated value of État civil Solution: Modified the convert_to_export function for selection field Description of the issue/feature this PR addresses: In the selection field selection list is defined by a method then instead of exporting the localized label, it exports the raw value this is backport of #192095 opw-4715430
This fix improves how Odoo detects missed real-time notifications after a user was disconnected. It helps ensure users are prompted to refresh when updates may have been lost, reducing the risk of working with stale information.
Original PR description
In [1], a mechanism was introduced to detect when notifications were lost due to the bus table being cleared during a disconnection. However, this approach used the autovacuum cron dates to detect this scenario. Other actions can clear the bus table, which is typically the case on odoo.com where another cron runs more frequently. This PR fixes the issue by comparing the disconnection time with the oldest bus notification's create date. [1]: https://github.com/odoo/odoo/pull/188003 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
Point of Sale sessions connected to an IoT box no longer show a brief loading icon every few seconds while checking device status. This makes the checkout screen feel smoother and less distracting for staff during daily operations.
Original PR description
Before this commit, when using a POS with an IoT box connected, there would be a brief loading icon flickering in the top right every 5 seconds. This is due to the call to get the latest status of the IoT devices. After this commit, the flickering is gone due to fetching the device status using the ORM service instead of the POS data service. task-4570905
This fix prevents an inter-company sales and purchase workflow from failing when a user lacks access to lot or serial number fields. It helps users complete related stock operations without needing unnecessary permissions.
Original PR description
`(stock.picking).move_ids_without_package.lot_ids` is gated on `stock.group_production_lot`, if the user doesn't have this group, the field is unavailable and trying to set it via the form fails. https://runbot.odoo.com/odoo/error/163100
Approving an employee leave no longer fails when another overlapping leave has already been refused. The planning holidays workflow now ignores refused leave records in this check, preventing an error and allowing valid approvals to proceed.
Original PR description
Currently, a traceback is occurring when trying to approve a leave having the same time off with the refused state of another leave. <b>To reproduce this issue:</b> 1) Install planning_holidays…
Currently, a traceback is occurring when trying to approve a leave having the same time off with the refused state of another leave. <b>To reproduce this issue:</b> 1) Install planning_holidays without demo 2) Enable flexible hours for the working schedules of an employee 3) Create two time-offs for an employee with the same date and time 4) Refuse the first one and try to approve the second one <b>Issue:-</b> ``` ValueError: Expected singleton: hr.leave(5, 6) ``` When there are more than one leave record with different states, leave_date will search the record based on the employee, date and time only. https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/planning_holidays/models/resource_calendar.py#L16-L24 So indeed we get multiple records, and this leads to the above traceback when accessing values from the leave_data. <b>Solution:-</b> Make the domain of leave_data more robust by including the state containing no refused leaves. opw-4712858,4700495
Point of Sale now prevents staff from settling customer dues or taking deposits when the required pay-later payment method is unavailable. This avoids failed partial payments, stuck screens, and follow-up errors caused by an incomplete POS payment setup.
Original PR description
Partial payments in POS are buggy if there is no pay later POS payment method Steps to reproduce: 1. Navigate to Point of Sale > Configuration > Payment Methods 2. Archive the "Customer Account" payment method (which is of `type == 'pay_later'`) 3. Try to settle a partially paid invoice in POS 4. Selecting the the "Validate" button will close the order without settling and will leave the UI in a buggy state where any further interactions produce a traceback Solution: Block the user from settling dues or making deposits when no pay_later payment method is loaded. OPW-4712869 The following error dialog is shown: <img width="163" alt="Screenshot 2025-04-18 at 00 28 41" src="https://github.com/user-attachments/assets/7651c863-bc75-4486-8483-8a8ee2fed5db" />
The payroll test setup now has the required HR administrator access to create leave types during validation checks. This prevents internal automated tests from failing after demo data changes, improving reliability without changing user-facing payroll behavior.
Original PR description
`TestPayslipValidation.setUpClass` tries to create an `hr.leave.type` but that requires hr admin access. So add that. Issue likely became visible from the removal of demo data, though it only popped up on April 1st instead of March 27th or whenever the demo data change was merged. https://runbot.odoo.com/odoo/error/162257
Fixed an issue where postpaid subscriptions with note or non-recurring lines could be treated like prepaid subscriptions. This prevented contracts from being checked every day unnecessarily and helps keep the next invoice date aligned with the subscription billing cycle.
Original PR description
Before thos commit, the next invoice date was updated at post invoice based on the order line properties. pre paid lines are will use the last deferred end date of the linked account move lines and post paid line simply increment the next invoice date. Before this commit, the post paid detection was faulty: we checked that all line were postpaid but if line notes or non recurring lines existed, they would not have the postpaid property. As a result, the next invoice date would be incremented with the prepaid condition. As a result, the next invoice date would only be incremented by one day and the cron would run on these contracts every day. opw-4618947 opw-4668741 opw-4686930
This fix makes an automated test for rental period selection on the website more stable. It reduces random test failures, helping teams trust release checks without changing the customer-facing rental flow.
Original PR description
In this commit we fix the website_sale_renting_select_wrong_period tour that can cause undeterministic errors.
The UrbanPiper username setting was renamed internally so it no longer shares the same label as another localization setting. This prevents warning messages when the module loads, with no expected change to how users configure or use the feature.
Original PR description
The field `res.config.settings.urbanpiper_username` has the same label `Username` as the field [`res.config.settings.l10n_co_edi_username`](https://github.com/odoo/enterprise/blob/e0307b19d85f9cc3dba883f3fe8eab2a4cb23ebd/l10n_co_edi/models/res_config_settings.py#L8-L9) from module `l10n_co_edi`. Having multiple fields on the same model with the same label generates warnings when loading the module. The label is already changed in [`saas-18.1`](https://github.com/odoo/enterprise/blob/e0307b19d85f9cc3dba883f3fe8eab2a4cb23ebd/pos_urban_piper/models/res_config_settings.py#L11), and the [view](https://github.com/odoo/enterprise/blob/3f828af20e7936e6730d2f94b79aef755bd4b359/pos_urban_piper/views/res_config_settings_views.xml#L11) displaying the field uses an explicit label as well.
Fixed a display issue where switch buttons in the Documents app could show incorrect padding after using the activity view switch. This improves visual alignment and makes the interface look more consistent for users.
Original PR description
This PR fixes an issue where the switch buttons in the documents module had incorrect padding when clicking on the activity switch view button.This fix ensures proper spacing and alignment across the interface. Task-4680512
Miscellaneous changes
Another check on the object received by the IoT Box containing certificate keys was always returning False, resulting in the certificate never being applied to the box. The object returned by odoo.com is a dictionary containing either: - 'error': 'an error message', - 'result': False (always False), or: - 'private_key_pem', - 'x509_pem', - 'subject_cn'. So checking `response.get("result")` would always return `False`, even if the server returned a certificate. Forward-Port-Of: odoo
Original PR description
Another check on the object received by the IoT Box containing certificate keys was always returning False,
resulting in the certificate never being applied to the box.
The object returned by odoo.com is a dictionary containing either:
- 'error': 'an error message',
- 'result': False (always False),
or:
- 'private_key_pem',
- 'x509_pem',
- 'subject_cn'.
So checking `response.get("result")` would always return `False`, even if the server returned a certificate.
Forward-Port-Of: odoo/odoo#206605
Forward-Port-Of: odoo/odoo#206499Accounts of the following account types should generally speaking not be reconcilable: - `asset_cash` - `liability_credit_card` - `off_balance` That is why the "Allow Reconciliation" (`reconcile`) field is already invisible on the 'account.account' form and list views. After this commit - All such accounts in the standard chart of accounts are not reconcilable (there were non for `off_balance`) - The compute function on 'account.account' sets those accounts to not be reconcila
Original PR description
Accounts of the following account types should generally speaking not be reconcilable: - `asset_cash` - `liability_credit_card` - `off_balance` That is why the "Allow Reconciliation" (`reconcile`) field is already invisible on the 'account.account' form and list views. After this commit - All such accounts in the standard chart of accounts are not reconcilable (there were non for `off_balance`) - The compute function on 'account.account' sets those accounts to not be reconcilable (already done for `asset_cash`) when changing the account type. task: None Forward-Port-Of: odoo/odoo#206604 Forward-Port-Of: odoo/odoo#206011
From the first of July 2025, the standard rate of VAT in Estonia is 24% instead of the current 22%. This commit adds the new tax. Also, one of the EU Intra-Community mappings was missing, specifically the 22% G (Purchases) -> 0% EU G 22% (Purchases). This was also added. task-4595806 Forward-Port-Of: odoo/odoo#205436 Forward-Port-Of: odoo/odoo#199789
Original PR description
From the first of July 2025, the standard rate of VAT in Estonia is 24% instead of the current 22%. This commit adds the new tax. Also, one of the EU Intra-Community mappings was missing, specifically the 22% G (Purchases) -> 0% EU G 22% (Purchases). This was also added. task-4595806 Forward-Port-Of: odoo/odoo#205436 Forward-Port-Of: odoo/odoo#199789
After c92e189e3850babb816a9b06f5d372f114d98359 it is not possible to order more than 2 units of same product in kiosk mode Forward-Port-Of: odoo/odoo#206424
Original PR description
After c92e189e3850babb816a9b06f5d372f114d98359 it is not possible to order more than 2 units of same product in kiosk mode Forward-Port-Of: odoo/odoo#206424
**Problem**: When a RFQ is created automatically (MTO, reordering rule, manual replenish) for a product which has a different currency in general information (next to cost) and in the vendor line (in the pruchase tab). If the conditions of the vendors pricelists aren't met (ex not enough quantity) the price on the RFQ will be the cost from the "general information tab" and the currency will come from the vendor in the purchase tab. This could be an issue especially if there's a high exchange
Original PR description
**Problem**: When a RFQ is created automatically (MTO, reordering rule, manual replenish) for a product which has a different currency in general information (next to cost) and in the vendor line (in…
**Problem**: When a RFQ is created automatically (MTO, reordering rule, manual replenish) for a product which has a different currency in general information (next to cost) and in the vendor line (in the pruchase tab). If the conditions of the vendors pricelists aren't met (ex not enough quantity) the price on the RFQ will be the cost from the "general information tab" and the currency will come from the vendor in the purchase tab. This could be an issue especially if there's a high exchange rate between the currencies. **Steps to reproduce**: - in settings, activate another currency (ex:kr) - create a new product - set the product type as "storable product" - set a cost in the general information tab and a currency (ex:1000kr) - in the inventory tab set the route as "Buy" - in the pruchase tab add a vendor line, with a vendor name, a quantity (ex:10) and a price in another currency (ex:8$) - click on the replenish button and set a quantity below the minimum quantity of the vendor line you just created **Current behavior**: A RFQ is created, with a price equal to the cost set in general information and the currency of the vendor in the purchase tab (here:1000$). **Expected behavior**: When the conditions of the vendor's pricelist aren't met the price should be 0 and the currency should be the one of the vendor **Fix**: I reversed the changes made in this commit https://github.com/odoo/odoo/pull/158650/commits/caf4974b770b3295faebdaab5014a879760ccd67 and adapted the test Now, if the seller variable is empty (which happens when no pricelist is matched), the price is set to zero https://github.com/odoo/odoo/blob/953eb7cc241e290e3e5d1ef19048213a206a1947/addons/purchase/models/purchase_order_line.py#L599 opw-4547212 Forward-Port-Of: odoo/odoo#202011
Steps to reproduce the bug: - Create a storable product P1: - Tracked by: Lot - Update the quantity of P1 with one unit and Lot 1 - Create a storable product C1 - Tracked by: Serial Number - Update the quantity of C1 with one unit and SN1 - Navigate to Product P1 → Lot/SN → Click on Lot 1 → Repair Orders - Create a repair order: - Add part: Select product C1 with SN1 - Try to save Problem: The lot "Lot 1" is incompatible with the product "C1". Since we access
Original PR description
Steps to reproduce the bug:
- Create a storable product P1:
- Tracked by: Lot
- Update the quantity of P1 with one unit and Lot 1
- Create a storable product C1
- Tracked by: Serial Number
- Update the quantity of C1 with one unit and SN1
- Navigate to Product P1 → Lot/SN → Click on Lot 1 → Repair Orders
- Create a repair order:
- Add part: Select product C1 with SN1
- Try to save
Problem:
The lot "Lot 1" is incompatible with the product "C1".
Since we access the Repair Order view from the Lot/SN view, a default
key is added with "Lot 1". As a result, when trying to create the
"stock.move.line" for C1, this incorrect lot is used.
opw-4576741
opw-4576004
Forward-Port-Of: odoo/odoo#205383
Forward-Port-Of: odoo/odoo#202979`TestItEdiDDT.test_deferred_invoice` creates a sales order but does not ensure the user has the rights to create one. https://runbot.odoo.com/odoo/error/163639 Forward-Port-Of: odoo/odoo#206613
Original PR description
`TestItEdiDDT.test_deferred_invoice` creates a sales order but does not ensure the user has the rights to create one. https://runbot.odoo.com/odoo/error/163639 Forward-Port-Of: odoo/odoo#206613
Related enterprise PR : https://github.com/odoo/enterprise/pull/81754 Forward-Port-Of: odoo/odoo#205901 Forward-Port-Of: odoo/odoo#205379
Original PR description
Related enterprise PR : https://github.com/odoo/enterprise/pull/81754 Forward-Port-Of: odoo/odoo#205901 Forward-Port-Of: odoo/odoo#205379
This reverts commit 4c7942e6bd0459fc9014d2af4a67a68c8334bca4. Steps to reproduce ================== - Install account_accountant - Go to accounting - Close the onboarding banner => TypeError: Cannot read properties of null (reading 'context') at _preprocessAction Cause of the issue ================== With commit 4c7942e6bd04, the response when calling the action changed ```diff - {"jsonrpc": "2.0", "id": 10} + {"jsonrpc": "2.0", "id": 10, result: null} ``` https:
Original PR description
This reverts commit 4c7942e6bd0459fc9014d2af4a67a68c8334bca4.
Steps to reproduce
==================
- Install account_accountant
- Go to accounting
- Close the onboarding banner
=> TypeError: Cannot read properties of null (reading 'context')
at _preprocessAction
Cause of the issue
==================
With commit 4c7942e6bd04, the response when calling the action changed
```diff
- {"jsonrpc": "2.0", "id": 10}
+ {"jsonrpc": "2.0", "id": 10, result: null}
```
https://github.com/odoo/odoo/blob/c412f11c028a8c7ff6e6c10da0e3f9dbc55e8e80/addons/web/static/src/views/view_hook.js#L86-L89
The condition `action !== undefined` is no longer met since the result is null.
Solution
========
Since this can happen anywhere we make an RPC call and there's no easy way to detect it, we revert the commit in stable.
Forward-Port-Of: odoo/odoo#206444Similar to #206050, sale_mrp has a bunch of forms which try to set the `product_id` on a bom without product variants being enabled, in which case the field is invisible and setting it fails. Since they don't seem to really care for variants, and the products are not created with variants, as in #206050 just don't set `product_id`. https://runbot.odoo.com/odoo/error/163112 Forward-Port-Of: odoo/odoo#206437
Original PR description
Similar to #206050, sale_mrp has a bunch of forms which try to set the `product_id` on a bom without product variants being enabled, in which case the field is invisible and setting it fails. Since they don't seem to really care for variants, and the products are not created with variants, as in #206050 just don't set `product_id`. https://runbot.odoo.com/odoo/error/163112 Forward-Port-Of: odoo/odoo#206437
After feff1a8 the distribution model uses it's fields to retrieve a matching analytic distribution. There's an incorrect behavior if a custom field is added to the model, for ex. with Studio or manually. Steps to reproduce: - add a custom field to the analytic distribution model with Studio - create an analytic distribution model and fill the custom field with a value ->> the model is not applied anymore when it should be. This is because of `_check_score` raising `NonMatchingDistrib
Original PR description
After feff1a8 the distribution model uses it's fields to retrieve a matching analytic distribution. There's an incorrect behavior if a custom field is added to the model, for ex. with Studio or manually. Steps to reproduce: - add a custom field to the analytic distribution model with Studio - create an analytic distribution model and fill the custom field with a value ->> the model is not applied anymore when it should be. This is because of `_check_score` raising `NonMatchingDistribution` if a field has a non-falsy value and it's not matching in the values dictionary. The custom fields are excluded from the check to fix this. opw-4689695 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205670
Until version 0.9.8 of vobject we need to ignore: - DeprecationWarning in python 3.6 and after - SyntaxWarning since python 3.12 See https://github.com/py-vobject/vobject/commit/da50fdb5fa871e4c5c3420d1e2e34e7c9ce6bb30 The warning occurs only during the first precompilation of the library. It does not occur on readonly filesystem, ie runbot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206115
Original PR description
Until version 0.9.8 of vobject we need to ignore: - DeprecationWarning in python 3.6 and after - SyntaxWarning since python 3.12 See https://github.com/py-vobject/vobject/commit/da50fdb5fa871e4c5c3420d1e2e34e7c9ce6bb30 The warning occurs only during the first precompilation of the library. It does not occur on readonly filesystem, ie runbot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206115
This commit is a backport of commit 1f761a3. The original commit message follows: Certificate banner in "advanced view" on the homepage could only display an "error" message, even when the message was not an error. This is not the case anymore. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206390
Original PR description
This commit is a backport of commit 1f761a3. The original commit message follows: Certificate banner in "advanced view" on the homepage could only display an "error" message, even when the message was not an error. This is not the case anymore. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206390
Steps to reproduce: 1. Install Indian E-waybill(`l10n_in_edi_ewaybill`) 2. Activate Unit of Measures 3. Create a Invoice with a move line product as default UOM as units. 4. Change the UOM on line to Dozens 5. Confirm and send the E-waybill On portal the E-waybill for that line is Unit instead of Dozens In this commit we fix the issue opw-4728253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206317 Forward
Original PR description
Steps to reproduce: 1. Install Indian E-waybill(`l10n_in_edi_ewaybill`) 2. Activate Unit of Measures 3. Create a Invoice with a move line product as default UOM as units. 4. Change the UOM on line to Dozens 5. Confirm and send the E-waybill On portal the E-waybill for that line is Unit instead of Dozens In this commit we fix the issue opw-4728253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206317 Forward-Port-Of: odoo/odoo#206191
This commit slightly adapts a Sortable test to accommodate adjustments made in Chrome 135 to some rounding done during painting. References (not exhaustive): - https://chromium.googlesource.com/chromium/src.git/+/a629cc4312019dfa43b686bdb2d9418a625f9bc6 - https://chromium.googlesource.com/chromium/src.git/+/2efdf2a6f8e184ece09acca4677d1ce9eb7a43ea - https://chromium.googlesource.com/chromium/src.git/+/ce7a5f6b60b175c780fb39e2f751d82abb8b011b Forward-Port-Of: odoo/odoo#206413
Original PR description
This commit slightly adapts a Sortable test to accommodate adjustments made in Chrome 135 to some rounding done during painting. References (not exhaustive): - https://chromium.googlesource.com/chromium/src.git/+/a629cc4312019dfa43b686bdb2d9418a625f9bc6 - https://chromium.googlesource.com/chromium/src.git/+/2efdf2a6f8e184ece09acca4677d1ce9eb7a43ea - https://chromium.googlesource.com/chromium/src.git/+/ce7a5f6b60b175c780fb39e2f751d82abb8b011b Forward-Port-Of: odoo/odoo#206413
Steps to Reproduce : - Drag and drop a "Text" snippet. - Click on "Hide on desktop". - Toggle on the eye button to force its visibility. - Click on a text outside the snippet & press enter. - Bug: the invisible snippet disappears. The issue comes from the fact that when we press Enter, a new paragraph is created and a history rollback is triggered at that moment. So when we go back in the history because of that rollback, the invisible snippet loses the "o_snippet_override_invisible" c
Original PR description
Steps to Reproduce : - Drag and drop a "Text" snippet. - Click on "Hide on desktop". - Toggle on the eye button to force its visibility. - Click on a text outside the snippet & press enter. - Bug: the invisible snippet disappears. The issue comes from the fact that when we press Enter, a new paragraph is created and a history rollback is triggered at that moment. So when we go back in the history because of that rollback, the invisible snippet loses the "o_snippet_override_invisible" class that had just been applied. Actually, adding and removing this class should not be inside the observer. This commit prevents that from happening. task-4690318 Forward-Port-Of: odoo/odoo#206266
The percentage sign is missing on the tax line in the invoice report opw-4661577 Forward-Port-Of: odoo/odoo#205900
Original PR description
The percentage sign is missing on the tax line in the invoice report opw-4661577 Forward-Port-Of: odoo/odoo#205900
### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock. - Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it. - Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it. - Look at the forecast rentable quantity. #### > It should be 90 but it is 100. ### Cause of the i
Original PR description
### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock. - Create a rental order for 10 units of that product planed…
### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock. - Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it. - Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it. - Look at the forecast rentable quantity. #### > It should be 90 but it is 100. ### Cause of the issue: Since c18a7d2dc36d33134c5bdb1569865bd554e04130, the rentable forecast for future dates ignores the `rented_qty_during_period` if the setting "Rental transfers" is enabled. This happens because that rented quantity during period is supposed to be absorbed by the stock forecast: https://github.com/odoo/enterprise/blob/8ea5f4f9a0a907c57844c6274688171193f6a904/sale_stock_renting/models/sale_order_line.py#L132-L134 However, the stock forecast of the 'virtual_available' relies solely on deliveries and receipt happening prior to the start of the renting period. Therefore the rental orders that are planned to start during the renting period should still contribute to the `rented_qty_during_period` in that use case. opw-4552760 Forward-Port-Of: odoo/enterprise#83262 Forward-Port-Of: odoo/enterprise#82172
`_test_send_invoice_and_credit_note` and `_test_send_invoiced_stock_moves` try to create sale orders, but don't check that the group is set on the user. https://runbot.odoo.com/odoo/error/163637 Forward-Port-Of: odoo/enterprise#83691
Original PR description
`_test_send_invoice_and_credit_note` and `_test_send_invoiced_stock_moves` try to create sale orders, but don't check that the group is set on the user. https://runbot.odoo.com/odoo/error/163637 Forward-Port-Of: odoo/enterprise#83691
In this PR we : -Allow manual input of source tax adjustments -Improve transmission error messages -Add missing translations -Reintroduce work information and skills tab Forward-Port-Of: odoo/enterprise#83381 Forward-Port-Of: odoo/enterprise#81754
Original PR description
In this PR we : -Allow manual input of source tax adjustments -Improve transmission error messages -Add missing translations -Reintroduce work information and skills tab Forward-Port-Of: odoo/enterprise#83381 Forward-Port-Of: odoo/enterprise#81754
Followup to #83427 as I missed a second issue in the test: `action_validate` can only be performed by a time off officer. So set that on the current user. Also `self.Requests.env.user` is the same as `self.env.user` so don't bother with the unnecessary indirection. https://runbot.odoo.com/odoo/error/164047 Forward-Port-Of: odoo/enterprise#83579
Original PR description
Followup to #83427 as I missed a second issue in the test: `action_validate` can only be performed by a time off officer. So set that on the current user. Also `self.Requests.env.user` is the same as `self.env.user` so don't bother with the unnecessary indirection. https://runbot.odoo.com/odoo/error/164047 Forward-Port-Of: odoo/enterprise#83579
This commit slightly adapts a Gantt test to accommodate adjustments made in Chrome 135 to some rounding done during painting. To do so, and to avoid a purely arbitrary value, the related assert is modified to check the visibility of the "today" column and that there is an actual scroll applied instead of an arbitrary scroll of 762px. References (not exhaustive): - https://chromium.googlesource.com/chromium/src.git/+/a629cc4312019dfa43b686bdb2d9418a625f9bc6 - https://chromium.googlesource.co
Original PR description
This commit slightly adapts a Gantt test to accommodate adjustments made in Chrome 135 to some rounding done during painting. To do so, and to avoid a purely arbitrary value, the related assert is modified to check the visibility of the "today" column and that there is an actual scroll applied instead of an arbitrary scroll of 762px. References (not exhaustive): - https://chromium.googlesource.com/chromium/src.git/+/a629cc4312019dfa43b686bdb2d9418a625f9bc6 - https://chromium.googlesource.com/chromium/src.git/+/2efdf2a6f8e184ece09acca4677d1ce9eb7a43ea - https://chromium.googlesource.com/chromium/src.git/+/ce7a5f6b60b175c780fb39e2f751d82abb8b011b Forward-Port-Of: odoo/enterprise#83587
This PR follows the new format of the pairing code introduced in the internal PR https://github.com/odoo/internal/pull/3462/ It removes the spaces around the introduced pairing code and makes all leters uppercase before sending them to odoo iot proxy Forward-Port-Of: odoo/enterprise#82905
Original PR description
This PR follows the new format of the pairing code introduced in the internal PR https://github.com/odoo/internal/pull/3462/ It removes the spaces around the introduced pairing code and makes all leters uppercase before sending them to odoo iot proxy Forward-Port-Of: odoo/enterprise#82905
In [1] we added a compute on wa_account_id in stead of a default to allow for a smarter default. We forgot to mark the field readonly in the process. This prevents the import of existing templates, or of templates from different accounts. task-4734669 Correction for: task-4369979 [1]: 7a593a4aa5040998dc12468dec12dca62f573030 Forward-Port-Of: odoo/enterprise#83562
Original PR description
In [1] we added a compute on wa_account_id in stead of a default to allow for a smarter default. We forgot to mark the field readonly in the process. This prevents the import of existing templates, or of templates from different accounts. task-4734669 Correction for: task-4369979 [1]: 7a593a4aa5040998dc12468dec12dca62f573030 Forward-Port-Of: odoo/enterprise#83562
Forward-Port-Of: odoo/enterprise#83524
Original PR description
Forward-Port-Of: odoo/enterprise#83524
This PR fixes two behavior on the lipe xml export in Italy. --- The first one linked to this fix: https://github.com/odoo/enterprise/commit/7323435468c8db15cd5643f7d6ecf5928ab2f3dc . It makes sure the options are gathered the right way depending on whether we export the xml from the report or from the closing entry. --- The second one makes sure the closing entry move is posted when the xml export is done pressing the "Post" button on it. --- no-task Forward-Port-Of: odoo/ente
Original PR description
This PR fixes two behavior on the lipe xml export in Italy. --- The first one linked to this fix: https://github.com/odoo/enterprise/commit/7323435468c8db15cd5643f7d6ecf5928ab2f3dc . It makes sure the options are gathered the right way depending on whether we export the xml from the report or from the closing entry. --- The second one makes sure the closing entry move is posted when the xml export is done pressing the "Post" button on it. --- no-task Forward-Port-Of: odoo/enterprise#83503
The percentage sign is missing on the tax line in the invoice report opw-4661577 Forward-Port-Of: odoo/enterprise#83497
Original PR description
The percentage sign is missing on the tax line in the invoice report opw-4661577 Forward-Port-Of: odoo/enterprise#83497