Friday, April 18, 2025
41 changes · 18.0
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
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#206499The 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
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
Exports 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
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
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
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
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 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