Wednesday, January 26, 2022
37 changes · master
Enhancements to existing features
Email fetching now treats processing problems as reportable errors, making them easier to capture in external monitoring tools such as Sentry. This helps teams detect and respond to failed incoming email processing more reliably.
Original PR description
Description of the issue/feature this PR addresses: It you use an external system to catch warning and error like sentry, with this PR it is simple. @tde-banana-odoo it is more an error if mail cannot be processed (see last issue found recently) cc @odony -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies and standardizes how Odoo manages internal locking for shared resources such as registries and caches. It reduces duplicated code and helps make core system behavior easier to maintain without changing day-to-day user workflows.
Original PR description
It's not entirely clear whether `@synchronized` is even useful, but keep it for now. `locked` is just the default instance of `@synchronised`. - rewrite `@synchronized` using `decorator`, don't fold everything into a single call as there's a potential for parametric conflict - remove the independent `locked` in `sql_db.py` - convert `lru` to `locked` - move `Registry` over to `locked` where applicable
Calendar reminder records are now included when populating calendar data. This helps test and demonstration environments better reflect real usage, making calendar-related workflows easier to evaluate.
Original PR description
Task-2728093 See odoo/enterprise#23707
Delivery package data now includes direct links to the related sales order or warehouse picking, making shipping information easier to access. This reduces the need to pass around extra shipment details and supports cleaner delivery carrier integrations.
Original PR description
Before this commit, to access some values of the DeliveryPackage objects, we needed to take the value from the related picking. for example, for the `payment country code` linked to the package, we need to retrieve the value from the related picking or order. To avoid passing too much data to the request objects, it is convenient to be able to access to the order/picking related to the package directly from the package. Because these objects are not children of odoo.models.Model, I do not need to follow the convention for the names, however, calling the picking > picking_id in the DeliveryPackage suggests that the picking is actually a odoo.models.Model child, which should be the case if it exists. reference-PR= https://github.com/odoo/enterprise/pull/23124
This update adds data preparation scripts for appointment types and available time slots, helping teams test and optimize appointment scheduling at scale. It supports better performance validation for both standard appointments and website-based appointment booking, while reminder behavior remains handled separately by the calendar module.
Original PR description
For performance purposes, populate script for appointment types and slots. Alarms/reminders are covered in the calendar module. Task-2728093 See odoo/odoo#83265
Resolved issues and error corrections
This change ensures the reversal date chosen in the accrued orders wizard is kept when accounting entries are created. It prevents the date from being reset to a default value, helping users avoid inconsistent or incorrect reversal entries.
Original PR description
Before this commit, the field reversal_date was not stored, which lead to inconsistent behaviour when creating entries, as the reversal date was always recompute with the default value. opw-2722435 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
Code cleanup and technical improvements
This update simplifies internal code patterns across several Odoo apps without changing business functionality. By replacing verbose code constructs with clearer equivalents and tidying regular expressions and strings, it reduces maintenance effort and lowers the chance of future mistakes.
Original PR description
* cleans up unecessary `set()` calls, by replacing them with set literals or set comprehensions * cleans up unnecessary `dict()` calls, by replacing them with dict literals or dict comprehensions, or the odd `dict.fromkeys` * cleans up a few regex (unnecessary escapes) and implicit string concatenations (unnecessary continuations) Originally partially in #73535 but that PR is too large and unfocused, so breaking it up into more specific cleanups (and also more complete thus this one being twice the size of that one),
Miscellaneous changes
When Jabberwock was introduced in [1], forms were not selected anymore by clicking on the form fields. That behavior got fixed when Jabberwock was removed in [2] but this commit introducing a test about it was not attached to a task - and did not get merged at the time. Before this commit there was no test to verify if the form became selected when clicking on one of its input field or textarea. After this commit there is a test that makes sure that the form is selected when the user
Original PR description
When Jabberwock was introduced in [1], forms were not selected anymore by clicking on the form fields. That behavior got fixed when Jabberwock was removed in [2] but this commit introducing a test…
When Jabberwock was introduced in [1], forms were not selected anymore by clicking on the form fields. That behavior got fixed when Jabberwock was removed in [2] but this commit introducing a test about it was not attached to a task - and did not get merged at the time. Before this commit there was no test to verify if the form became selected when clicking on one of its input field or textarea. After this commit there is a test that makes sure that the form is selected when the user clicks on either an input field or a textarea. Also added the renaming of a field label followed by a blur to ensure it triggers all UI events. [1] https://github.com/odoo/odoo/commit/347f4413d1b1a2b1a6a9ecd6d9c20cf7f3ec5ff3 [2] https://github.com/odoo/odoo/commit/e5572c317a7775a58675ed73efc89b5c9f6c0c39 task-2729643 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#63256
This change makes automated test cleanup more reliable when multiple builds create databases at the same time. It reduces random test failures in the runbot environment, helping developers get clearer feedback from builds without affecting everyday users.
Original PR description
On runbot database can be create concurently by other builds, meaning that the teardown may fail randomly if a database is create between setup and teardown. Filtering on the dbfilter in all case may miss some errors but will be enough in this case.
A small issue was corrected that could cause an error when users selected a disallowed expense from the chart of accounts. This helps keep accounting workflows smoother and prevents an unnecessary interruption during account setup or review.
Original PR description
This fixes a small bug in the `name_get()` method that was causing a traceback when selecting a disallowed expenses from the chart of accounts. Related: https://github.com/odoo/enterprise/commit/5be63b1c735a0b30cca166d2f7f4b97b4330439e
This update cleans up the styling of the email attachment list as part of a broader interface optimization effort. It should help keep the mail interface easier to maintain while preserving the existing user experience.
Original PR description
Part of the overall v16 SCSS optimization/restyle (task-2704984) task-2731819 Notes: - requires https://github.com/odoo/odoo/pull/83260 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes a couple of things; 1. Backorder use case when unassigning a move in reception report. To reproduce: - Create a Delivery w/ Demand = 8 of a stored product not in stock - Create a Receipt w/ Demand = 10 of the product - Assign 8 of product to delivery (don't forget to activate Reception Report in settings - Mark 4 of product as done > mark as done > create a backorder - Open reception report in backorder (shows 6 instead of 4, this is a known limitation of reception report)
Original PR description
Fixes a couple of things; 1. Backorder use case when unassigning a move in reception report. To reproduce: - Create a Delivery w/ Demand = 8 of a stored product not in stock - Create a Receipt w/…
Fixes a couple of things; 1. Backorder use case when unassigning a move in reception report. To reproduce: - Create a Delivery w/ Demand = 8 of a stored product not in stock - Create a Receipt w/ Demand = 10 of the product - Assign 8 of product to delivery (don't forget to activate Reception Report in settings - Mark 4 of product as done > mark as done > create a backorder - Open reception report in backorder (shows 6 instead of 4, this is a known limitation of reception report) + unassign + close report - Reopen report + assign 4 - Finish the backorder Expected result: Delivery has 2 moves totaling a demand and reserved amount of 8 Actual result: Delivery has 2 moves where 1 is fully reserved but the other isn't and cannot be reserved (even though product in stock). Issue was due to move split during unassign not taking into account that the amount being unassigned could be greater than the amount still assigned (due to backorder amount > demand qty since it doesn't know how much was done in the original receipt). This would lead to the move linked to the original receipt's move expecting a greater quantity from the original move (and therefore not reserving any more quantities.) 2. Trying to unassign from an already done move. (i.e. backordered move from above unassigned after the delivery is already done) isn't allowed, so in case of unassigning from a done move, we don't do a split. 3. In case of failure of unassigning, fail gracefully (i.e. don't switch button status since this is misleading). Discovered during task: 2662730 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83318 Forward-Port-Of: odoo/odoo#81247
When installing 'l10n_fr_pos_cert', some fields become always editables on the bank statement form even the state is not 'open'. This allows the user to introduce a lot of unconsistencies regarding the bank statement balances. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83314
Original PR description
When installing 'l10n_fr_pos_cert', some fields become always editables on the bank statement form even the state is not 'open'. This allows the user to introduce a lot of unconsistencies regarding the bank statement balances. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83314
[FIX] web,mail: fix wrong assertions in tests This is not a big deal, but by passing a widget instance or a DOM node as message to a QUnit.assert function, QUnit keeps a reference to that instance or DOM element, and it can never be garbage collected (nor its bound handlers in the case of a DOM element). For the mail case, this was a bit more critical as we didn't check what the author of the test actually wanted to check. Forward-Port-Of: odoo/odoo#83381
Original PR description
[FIX] web,mail: fix wrong assertions in tests This is not a big deal, but by passing a widget instance or a DOM node as message to a QUnit.assert function, QUnit keeps a reference to that instance or DOM element, and it can never be garbage collected (nor its bound handlers in the case of a DOM element). For the mail case, this was a bit more critical as we didn't check what the author of the test actually wanted to check. Forward-Port-Of: odoo/odoo#83381
Upon save in website or in mass_mailing, if a `cleanForSave` of a `SnippetEditor` or a `SnippetOption` wait for the end of an `this._rpc()` request AND the `SnippetEditor` or the `SnippetEditor` of the `SnippetOption` has a `SnippetEditor` ancestor, the `cleanForSave` will never resolve. Here is the scenario: - **SnippetEditor B** has **SnippetEditor A** as its odoo widget parent In `SnippetMenu` `_destroyEditors`: - **SnippetEditor A** and **all its SnippetOption** call `cleanForS
Original PR description
Upon save in website or in mass_mailing, if a `cleanForSave` of a `SnippetEditor` or a `SnippetOption` wait for the end of an `this._rpc()` request AND the `SnippetEditor` or the `SnippetEditor` of…
Upon save in website or in mass_mailing, if a `cleanForSave` of a
`SnippetEditor` or a `SnippetOption` wait for the end of an
`this._rpc()` request AND the `SnippetEditor` or the `SnippetEditor`
of the `SnippetOption` has a `SnippetEditor` ancestor, the
`cleanForSave` will never resolve.
Here is the scenario:
- **SnippetEditor B** has **SnippetEditor A** as its odoo widget parent
In `SnippetMenu` `_destroyEditors`:
- **SnippetEditor A** and **all its SnippetOption** call `cleanForSave`.
- **SnippetEditor B** and **all its SnippetOption** call `cleanForSave`.
One of the promise of **SnippetEditor B** includes the result of
`rpc()` in `ajax_service.js`.
- **SnippetEditor A** and **all its SnippetOption**
`cleanForSave promises` resolve (but not **SnippetEditor B**).
- **SnippetEditor A** get's destroyed (`snippetEditor.destroy()`). As
**SnippetEditor B** is a `Widget` child of **SnippetEditor A**:
- **SnippetEditor B** get's destroyed (here is where the problem start).
... in the mean time ...
The ajax request of a promise of **SnippetEditor B** ends. The promise
of the `rpc()` will never finish because **SnippetEditor B** is
destroyed and the condition in `rpc()` is:
```js
if (!target.isDestroyed()) {
resolve(result);
}
```
Because the promise will never finish for `_destroyEditors`, the save
action will never fully complete.
Task-2742008
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#83120When changing the background image with studio the image does not update. It works in debug=assets mode. This is due to the fact that the caching system is not aware of the presence of a possible background image enterprise: https://github.com/odoo/enterprise/pull/22915 opw-2696786 Forward-Port-Of: odoo/odoo#83259
Original PR description
When changing the background image with studio the image does not update. It works in debug=assets mode. This is due to the fact that the caching system is not aware of the presence of a possible background image enterprise: https://github.com/odoo/enterprise/pull/22915 opw-2696786 Forward-Port-Of: odoo/odoo#83259
# purpose: - Creating a tax report for danish localization - Creating the tax implementation fiting the report task: 2666277 linked to a partner pr: https://github.com/odoo/odoo/pull/64547 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83288 Forward-Port-Of: odoo/odoo#80823
Original PR description
# purpose: - Creating a tax report for danish localization - Creating the tax implementation fiting the report task: 2666277 linked to a partner pr: https://github.com/odoo/odoo/pull/64547 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83288 Forward-Port-Of: odoo/odoo#80823
Steps to repdroduce: - install Purchase - Accounting - Create a new Purchase Order - Add a product - Add a section or a note - in Actions select Accrued Expense Entry -> traceback rounding error OPW-2728854 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83022
Original PR description
Steps to repdroduce: - install Purchase - Accounting - Create a new Purchase Order - Add a product - Add a section or a note - in Actions select Accrued Expense Entry -> traceback rounding error OPW-2728854 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83022
It is sometimes impossible to unbuild a product because of decimal values. To reproduce the issue: (Enable debug mode) 1. In Settings, enable "Units of Measure" 2. Set the decimal accuracy of "Product Unit of Measure" to 4 3. Set the rounding precision of "Units" to 0.001 4. Create two products P1, P2 5. Create a BoM: - Product: P1 - Quantity: 3 - Type: Manufacture - Components: 5 x P2 6. Process a MO with 3 x P1 7. Create an unbuild order UO: - Manufacturing
Original PR description
It is sometimes impossible to unbuild a product because of decimal values. To reproduce the issue: (Enable debug mode) 1. In Settings, enable "Units of Measure" 2. Set the decimal accuracy of…
It is sometimes impossible to unbuild a product because of decimal
values.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Units of Measure"
2. Set the decimal accuracy of "Product Unit of Measure" to 4
3. Set the rounding precision of "Units" to 0.001
4. Create two products P1, P2
5. Create a BoM:
- Product: P1
- Quantity: 3
- Type: Manufacture
- Components: 5 x P2
6. Process a MO with 3 x P1
7. Create an unbuild order UO:
- Manufacturing Order: MO
- Quantity: 1
8. Unbuild
Error: An error message is displayed "The quantity done for the product
"P2" doesn't respect the rounding precision[...]"
At some point, for each SM associated to the UO, the modules uses the
value of `product_uom_qty` to write the done quantity of the SM. The
rounding of `product_uom_qty` is based on "Product Unit of Measure" so
the component's SM has its quantity equal to `1.6667`. Moreover, writing
the done quantity trigger the creation of the associated SML. As a
result, the SML has its done quantity equal to `1.6667` while the
rounding of the associated UoM is `0.001`. When calling `_action_done`
on such a SML, it will raise an error because the value doesn't respect
the rounding.
Side note: the error message is incorrectly written, the indents in the
file are displayed on the front-end.
OPW-2710038
Forward-Port-Of: odoo/odoo#83235
Forward-Port-Of: odoo/odoo#83207**Steps to follow** - Use an odoo instance without the planning app - Go to the survey app > feedback form - Click on "See results" - Print the document with your browser -> The output only contains the first page **Cause of the issue** A height of 100% is set to the html element It works with the planning module because this css is present https://github.com/odoo/enterprise/blob/ead53fcca721aaa06619b4113707cae3fe086731/planning/static/src/scss/planning_calendar_re
Original PR description
**Steps to follow** - Use an odoo instance without the planning app - Go to the survey app > feedback form - Click on "See results" - Print the document with your browser -> The output only contains the first page **Cause of the issue** A height of 100% is set to the html element It works with the planning module because this css is present https://github.com/odoo/enterprise/blob/ead53fcca721aaa06619b4113707cae3fe086731/planning/static/src/scss/planning_calendar_report.scss#L57-L60 **Solution** Unset the html height property in the survey layout opw-2724319 Forward-Port-Of: odoo/odoo#83347
Before this commit, a traceback occured when trying to remove a popup snippet, only if content inside was clicked on before (base case but that last part was not covered by our main test which drags and drops + removes all snippets). The problem is complex and annoying to solve in stable. The cause is the combination of [1] and [2]. Indeed, with [2] we solved the snippet activation flow to ensure the onFocus and onBlur methods are called when needed... but that new correct implementatio
Original PR description
Before this commit, a traceback occured when trying to remove a popup snippet, only if content inside was clicked on before (base case but that last part was not covered by our main test which drags…
Before this commit, a traceback occured when trying to remove a popup snippet, only if content inside was clicked on before (base case but that last part was not covered by our main test which drags and drops + removes all snippets). The problem is complex and annoying to solve in stable. The cause is the combination of [1] and [2]. Indeed, with [2] we solved the snippet activation flow to ensure the onFocus and onBlur methods are called when needed... but that new correct implementation relies on the fact that the number of snippet editor instances does not change for the whole async operation of activating a snippet. That should naturally be the case but is not because of [1]: when we remove a snippet we first trigger a snippet activation then destroy the snippet (and its editor instance)... but the snippet activation is not awaited at the moment. Thus making the snippet editor instance be destroyed *during* the snippet activation flow. Of course a better solution than this commit must be found but this fixes the traceback with a very minimal change for the 15.0 stable version while waiting for that miraculous solution. [1]: https://github.com/odoo/odoo/commit/ae219ec06baf0280c76ae09b1453cc1481eece30 [2]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e task-2735663 Forward-Port-Of: odoo/odoo#83350
Before this commit, when trying to paste an url, the editor was properly creating a link but did not create a step in the history. So when the user hit enter just after the paste, the last link insertion was reverted. Task-2720366 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82563
Original PR description
Before this commit, when trying to paste an url, the editor was properly creating a link but did not create a step in the history. So when the user hit enter just after the paste, the last link insertion was reverted. Task-2720366 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82563
Whenever the layout of the shop when editing the /shop page, all the elements mutated from _onApplyShopLayoutChange became dirty but shouldn't have as there is no intention to save those mutations. Task-2676809 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82523
Original PR description
Whenever the layout of the shop when editing the /shop page, all the elements mutated from _onApplyShopLayoutChange became dirty but shouldn't have as there is no intention to save those mutations. Task-2676809 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82523
Current behavior: When changing the type of a payment journal used in a cash payment method you couldn't close a PoS that used this payment method Steps to reproduce: - Point of Sale > Configuration > Payment Methods - Select 'Cash' payment method, go to journal 'Cash', edit the type to 'Bank' - Go to a Pos session, then try to close it. opw-2732933 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82710
Original PR description
Current behavior: When changing the type of a payment journal used in a cash payment method you couldn't close a PoS that used this payment method Steps to reproduce: - Point of Sale > Configuration > Payment Methods - Select 'Cash' payment method, go to journal 'Cash', edit the type to 'Bank' - Go to a Pos session, then try to close it. opw-2732933 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82710
Current behavior: When creating a gift card in PoS you are not able to use it in the eCommerce website Steps to reproduce: - Activate gift card in PoS, in Generate barcode mode - Create a gift card in the PoS - Try to use this gift card in the eCommerce website - You get an error "expired or not valid" opw-2727404 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83323
Original PR description
Current behavior: When creating a gift card in PoS you are not able to use it in the eCommerce website Steps to reproduce: - Activate gift card in PoS, in Generate barcode mode - Create a gift card in the PoS - Try to use this gift card in the eCommerce website - You get an error "expired or not valid" opw-2727404 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83323
Steps to reproduce the bug: - Activate packaging in inventory configurations - set the product UOM digits to more than 2 decimals - Create a storable product: - Go to inventory tab > Packaging > Add a line - Change the contained quantity to a value with more than 2 decimal places Problem: It will round it to 2 decimal places regardless of the set digits. Because the formatFloat function does not receive the digits in parameter, so it uses 2 as default value Problem: opw-2
Original PR description
Steps to reproduce the bug:
- Activate packaging in inventory configurations
- set the product UOM digits to more than 2 decimals
- Create a storable product:
- Go to inventory tab > Packaging > Add a line
- Change the contained quantity to a value with more than 2 decimal places
Problem:
It will round it to 2 decimal places regardless of the set digits.
Because the formatFloat function does not receive the digits in parameter, so it uses 2 as default value
Problem:
opw-2723068
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#83368
Forward-Port-Of: odoo/odoo#83352Since [1] the redirection supposed to happen after a lang install from the frontend was broken. Indeed, the 'url_return' was moved and used before it is actually set. [1]: 745ef9d Cheers to @JKE-be which did the same fix in another branch in parallel. Forward-Port-Of: odoo/odoo#83362 Forward-Port-Of: odoo/odoo#83275
Original PR description
Since [1] the redirection supposed to happen after a lang install from the frontend was broken. Indeed, the 'url_return' was moved and used before it is actually set. [1]: 745ef9d Cheers to @JKE-be which did the same fix in another branch in parallel. Forward-Port-Of: odoo/odoo#83362 Forward-Port-Of: odoo/odoo#83275
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83322 Forward-Port-Of: odoo/odoo#83278
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83322 Forward-Port-Of: odoo/odoo#83278
Whenever we clicked on a link that contained another element (eg. span, bold, ...), the LinkTool did not open. Task-2667989 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82569
Original PR description
Whenever we clicked on a link that contained another element (eg. span, bold, ...), the LinkTool did not open. Task-2667989 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82569
Before this commit: static XML templates could only be defined on the file system, and called by manifest assets or ir.asset records. Attachments were not taken into account when evaluating static templates. Now, if a given path does not match a file on the system, an additional check is run on ir.attachment records instead of failing directly. Task [2715333](https://www.odoo.com/web#id=2715333&cids=1&model=project.task&view_type=form) -- I confirm I have signed the CLA and read t
Original PR description
Before this commit: static XML templates could only be defined on the file system, and called by manifest assets or ir.asset records. Attachments were not taken into account when evaluating static templates. Now, if a given path does not match a file on the system, an additional check is run on ir.attachment records instead of failing directly. Task [2715333](https://www.odoo.com/web#id=2715333&cids=1&model=project.task&view_type=form) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83078
[FIX] l10n_co_edi: Impossible to process an invoice manually Steps to Reproduce: 1. use Colombian Localization 2. give a non-admin user all accounting access rights 3. use the non-admin user U to create an invoice I 4. Process I manually Bug: the non-admin user will not be able to process the invoice even if he has the proper access rights. Fix: All the accounting user can process manually the invoices OPW: 2745545 Forward-Port-Of: odoo/enterprise#23757
Original PR description
[FIX] l10n_co_edi: Impossible to process an invoice manually Steps to Reproduce: 1. use Colombian Localization 2. give a non-admin user all accounting access rights 3. use the non-admin user U to create an invoice I 4. Process I manually Bug: the non-admin user will not be able to process the invoice even if he has the proper access rights. Fix: All the accounting user can process manually the invoices OPW: 2745545 Forward-Port-Of: odoo/enterprise#23757
- Install colombian and chiliean Electronic invoicing - Create 2 companies for each country - Try to send Chilean invoice to the SII with the button "Enviar ahora al SII" when the edi_state to 'sent' => red box with "invalid fields CUFE/CUDE" which is a Colombian field The Chilean invoice form have the inherited view 'invoice_form_inherit_l10n_co_edi' from Colombian localization and this needs the colombian field "CUFE/CUDE" to be set. This PR remove the requirement of this field because
Original PR description
- Install colombian and chiliean Electronic invoicing - Create 2 companies for each country - Try to send Chilean invoice to the SII with the button "Enviar ahora al SII" when the edi_state to 'sent' => red box with "invalid fields CUFE/CUDE" which is a Colombian field The Chilean invoice form have the inherited view 'invoice_form_inherit_l10n_co_edi' from Colombian localization and this needs the colombian field "CUFE/CUDE" to be set. This PR remove the requirement of this field because it is something you receive after. opw-2730129 Forward-Port-Of: odoo/enterprise#23753
Forward-Port-Of: odoo/enterprise#23730 Forward-Port-Of: odoo/enterprise#23709
Original PR description
Forward-Port-Of: odoo/enterprise#23730 Forward-Port-Of: odoo/enterprise#23709
Before the PR: If a credit note has a line with a note or a section, when trying to generate a Chilean debit note over it, it claims that the line does not have the account defined. After the PR: As the display_type lines note or section are not passed the UserError is prevented. Forward-Port-Of: odoo/enterprise#23691
Original PR description
Before the PR: If a credit note has a line with a note or a section, when trying to generate a Chilean debit note over it, it claims that the line does not have the account defined. After the PR: As the display_type lines note or section are not passed the UserError is prevented. Forward-Port-Of: odoo/enterprise#23691
When changing the background image with studio the image does not update. It works in `debug=assets` mode. This is due to the fact that the caching system is not aware of the presence of a possible background image community: https://github.com/odoo/odoo/pull/83259 opw-2696786 Forward-Port-Of: odoo/enterprise#22915
Original PR description
When changing the background image with studio the image does not update. It works in `debug=assets` mode. This is due to the fact that the caching system is not aware of the presence of a possible background image community: https://github.com/odoo/odoo/pull/83259 opw-2696786 Forward-Port-Of: odoo/enterprise#22915
Because of the line t-att-ImpSaldoInsoluto="format_float(invoice_vals['amount_before_paid'] - invoice_vals['amount_paid'], invoice.currency_id.decimal_places)"/> Very small negative float quantities may end up in the xml triggering an error during SAT validation Fine tuning of 91decbdb2978b9772f00bd09fff4720f0034eb04 opw-2729420 Forward-Port-Of: odoo/enterprise#23740
Original PR description
Because of the line t-att-ImpSaldoInsoluto="format_float(invoice_vals['amount_before_paid'] - invoice_vals['amount_paid'], invoice.currency_id.decimal_places)"/> Very small negative float quantities may end up in the xml triggering an error during SAT validation Fine tuning of 91decbdb2978b9772f00bd09fff4720f0034eb04 opw-2729420 Forward-Port-Of: odoo/enterprise#23740
data_cleaning_model._clean_records can create lots of data_cleaning_records in one go. In case the cron timeouts, the transaction is rolled back and no record is written to the db. As it is common for crons, it is better to split the records to create in batches and commit after each batch iteration. That way, if the transaction gets rolled back, all the previously created records are kept. This is roughly the same thing that is done in `find_duplicates` in https://github.com/od
Original PR description
data_cleaning_model._clean_records can create lots of data_cleaning_records in one go. In case the cron timeouts, the transaction is rolled back and no record is written to the db. As it is common for crons, it is better to split the records to create in batches and commit after each batch iteration. That way, if the transaction gets rolled back, all the previously created records are kept. This is roughly the same thing that is done in `find_duplicates` in https://github.com/odoo/enterprise/blob/14.0/data_merge/models/data_merge_model.py opw-2738529 Forward-Port-Of: odoo/enterprise#23671