Daily updates from Odoo
Tuesday, February 25, 2025
57 changes · 18.0
New functionality added to Odoo
Uruguayan electronic invoicing now supports invoice-wide discounts and down payments. This helps companies issue compliant invoices that correctly reflect adjusted totals required by DGI.
Original PR description
This PR introduces two key features in Uruguayan electronic invoicing: Global Discounts: - Implemented the ability to apply global discounts across invoices. - Discounts are calculated and reflected in the final invoice total, ensuring compliance with DGI requirements. Down Payments: - Support for down payments was added to the invoicing process to ensure compliance with DGI requirements. ------------------------------- latam-task: 1284 adhoc-task-side: 45612
Enhancements to existing features
This update reorganizes shared email testing tools so other areas can use a lighter test foundation without loading unnecessary sample data. It helps keep automated tests easier to maintain and reduces avoidable dependencies across related modules.
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
Point of Sale customer displays connected through an IoT Box are now configured directly when selecting the display, removing extra settings steps. The customer display can also open automatically on the IoT Box when Point of Sale starts, while the separate customer display setting remains available for using an additional window.
Original PR description
To configure the RPI display as customer display we needed: **Before this commit:** - Go to configuration, - Check "IoT Box" checkbox, - Select a display, - Go to "Configuration -> Settings", - Scroll until "Customer Display" then select "An IoT-connected system. **After this commit:** - Go to configuration, - Check "IoT Box" checkbox, - Select a display. **Note:** the "Customer Display" setting is now only used for a second display. That means that customer display can now be opened on both an IoT Display and a new window. The Customer Display now also opens automatically on the IoT Box display while opening PoS. Task: 4585446
Resolved issues and error corrections
This fixes an issue where some account records were missing from search results when their companies were not among the user's accessible companies, even with elevated access. Searches now keep those accounts visible where appropriate, reducing the risk of incomplete account lists and related reporting gaps.
Original PR description
Bug: At the moment, searching on `account.account` does not return accounts whose `company_ids` does not contain any of the companies accessible to the current user, even in sudo mode. Diagnosis: The default `_order` on `account.account` includes `placeholder_code`. When we call `_field_to_sql` for `placeholder_code`, we do a JOIN, which excludes any accounts for which a value could not be computed on `placeholder_code`. These are the accounts that are not accessible to the current user. Solution: We change `_field_to_sql` for `placeholder_code` to perform a LEFT JOIN rather than a JOIN on the first account company accessible to the user. If none of the account's companies are accessible to the user, `placeholder_code` will simply be NULL. We add tests that check this behaviour and ensure that no accounts are excluded from a `search` in `sudo` mode. opw-4393854
Odoo now includes the required authentication header when returning a 401 response for bearer-token protected routes. This improves standards compliance and helps integrations handle authentication failures more reliably.
Original PR description
There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the response which is only defined for http auth schemes (basic, digest, bearer, ...), but we don't use thoses schemes with Odoo. One place where we are correctly using the 401-Unauthorized response is with `@route(auth='bearer')`, but it lacked the `WWW-Authenticate` header to be fully compliant with the http. > The server generating a 401 response MUST send a WWW-Authenticate > header field containing at least one challenge applicable to the > target resource. https://httpwg.org/specs/rfc9110.html#status.401 https://httpwg.org/specs/rfc9110.html#field.www-authenticate https://github.com/odoo/odoo/pull/199063
Updating account translations can encounter tags that were added after a release. This change prevents the process from crashing in that situation and records an error instead, helping language updates continue more reliably.
Original PR description
Sometimes, a tag is added after the release (e.g. f221381fbdf8) and this lead to an error when load_account_translations is executed (e.g. when updating a language translations). Do not crash but log an error instead.
This fixes an issue where Point of Sale managers could not see margin and cost information in the product information pop-up, even when they had the expected advanced access rights. After the change, authorized managers can access the same profitability details as intended, improving visibility during sales operations.
Original PR description
Description of the issue/feature this PR addresses: - Create POS, set login with employees, assign an employee as advanced user (manager) - Disable margin & costs configuration - Open POS, click the information icon in Product Screen - Margin & costs is not visible Current behavior before PR: - In POS the margin & costs is not visible with advanced access rights (manager) Desired behavior after PR is merged: - Show the margin & costs information in product information pop up --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures Odoo returns the proper authentication instruction when bearer-token access is denied. It improves standards compliance for API integrations and helps external systems handle authentication failures more reliably.
Original PR description
There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the…
There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the response which is only defined for http auth schemes (basic, digest, bearer, ...), but we don't use thoses schemes with Odoo. One place where we are correctly using the 401-Unauthorized response is with `@route(auth='bearer')`, but it lacked the `WWW-Authenticate` header to be fully compliant with the http. > The server generating a 401 response MUST send a WWW-Authenticate > header field containing at least one challenge applicable to the > target resource. https://httpwg.org/specs/rfc9110.html#status.401 https://httpwg.org/specs/rfc9110.html#field.www-authenticate 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
Invoice PDFs with multi-line legal notes now render those notes without covering the payment total section when the notes start on a new page. This improves readability and prevents confusion in customer invoice documents.
Original PR description
Behaviour Before the Commit: When an invoice pdf has more than 1 page and legal notes(multiline notes) section is the first thing on next page, wkhtmltopdf fails to handle page-break for legal notes…
Behaviour Before the Commit: When an invoice pdf has more than 1 page and legal notes(multiline notes) section is the first thing on next page, wkhtmltopdf fails to handle page-break for legal notes text. First line of legal notes overwrites on the total amount section resulting in overflow of contents. It works fine if legal notes are not the first thing on page. Behaviour After the Commit: Legal notes(multiline notes) text does not overwrite on total payment summary anymore. Fix: Add 'overflow-auto' class to div with id='payment-term' and has clearfix class to ensure it handles overflow. Steps to reproduce: 1. Create a multiline legal notes for any tax. 2. Open Customer-Invoices, create an invoice by adding multiple products with the tax which has multiline legal notes. 3. Make sure to add specific number of products/sections so that invoice expands to 2 pages. 4. Legal notes section must be the first thing on second page, otherwise it will not overwrite text. Feel free to look at the ticket number 4416845 for detailed understanding of the bug. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix helps Odoo recover when inventory records and reservation details become out of sync. It prevents invalid negative reserved quantities and adds automated cleanup so users are less likely to be blocked by stock reservation inconsistencies.
Original PR description
It happens due to many reasons that the `stock.quant` object and `stock.move.line` loose their synchronisation and it could have a difference between the sum of `stock.move.line` and the…
It happens due to many reasons that the `stock.quant` object and `stock.move.line` loose their synchronisation and it could have a difference between the sum of `stock.move.line` and the quantity/reserved quantity on the `stock.quant` It's important to keep tracking why the desycnh happens and to fix all the root causes of it. However, it's hard for the user to clean the data himself or even worst to lock him when it happens (as before 18.0). For quantity: It's not a big deal to have a huge difference between the quantity and all the long time history. As in real life, the inventory adjustement can help to clean the data. For reserved quantity: It's a bigger problem since the user can't edit it. A first step would be to never write it to a negative value (since it should never happen). That way when the user empty the stock, it will also probably clean the reserved quantity. But in case where there is more reservation than on `stock.move.line`. We should also clean it to be able to reserve them. Currently, we will try in the scheduler for that part A last step, could be to create a constraint during test that ensure the synch is never broken and it could raise directly if the developer made a mistake 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
Section lines in generated PDF reports now show the expected gray background again instead of appearing only in bold. This restores the previous visual distinction for grouped sections in sales quotations and other reports, making documents easier to read and consistent with earlier versions.
Original PR description
### Steps to reproduce: - Go to Sale, create a quotation with section lines - Confirm and send - The generated PDF have section lines that are only bold (no background color) - In v17.0 sections…
### Steps to reproduce: - Go to Sale, create a quotation with section lines - Confirm and send - The generated PDF have section lines that are only bold (no background color) - In v17.0 sections lines were gray ### Cause: It was removed during a refactoring. Section lines with the "boxed" template were still supposed to be gray, but the code was `&.o_line_section td` inside of a `tbody` element, so the `&` referenced `tbody` and not `tr` on which the class `o_line_section` is added: https://github.com/odoo/odoo/blob/ddb03a55ac94b9fd48ae6ce138e70c0070bedd36/addons/account/views/report_invoice.xml#L131 ### Solution: Replace `&` by `tr` and move the change of background color to all tables, so affecting all reports. ###Before / After: "Light" template   "DIN5008" template   opw-4572732
This fix prevents recruitment database upgrades from failing when the SMS app has been uninstalled. It moves SMS-specific recruitment actions into a dedicated bridge module so customers can upgrade reliably without needing unused SMS features installed.
Original PR description
Backport of odoo#194647 Basically, starting from `saas~16.4` we have action window in `hr_recruitment` which is pointing at `sms` module. If client does this steps: 1. Install `hr_recruitment` in…
Backport of odoo#194647
Basically, starting from `saas~16.4` we have action window in `hr_recruitment` which is pointing at `sms` module.
If client does this steps:
1. Install `hr_recruitment` in version 18.0
2. Uninstall the module `sms`
3. Try to upgrade db to `saas~18.1`
We will have the issue similar to this:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-18.1/odoo/service/server.py", line 1295, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/src/odoo/saas-18.1/odoo/tools/func.py", line 98, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-18.1/odoo/orm/registry.py", line 143, in new
load_modules(registry, force_demo, update_module=update_module)
File "/home/odoo/src/odoo/saas-18.1/odoo/modules/loading.py", line 528, in load_modules
processed_modules += load_marked_modules(
File "/home/odoo/src/odoo/saas-18.1/odoo/modules/loading.py", line 405, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/saas-18.1/odoo/modules/loading.py", line 251, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/saas-18.1/odoo/modules/loading.py", line 84, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/saas-18.1/odoo/tools/convert.py", line 622, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/saas-18.1/odoo/tools/convert.py", line 694, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/saas-18.1/odoo/tools/convert.py", line 608, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/saas-18.1/odoo/tools/convert.py", line 562, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_recruitment/views/hr_candidate_views.xml:220
Invalid model name “sms.composer” in action definition.
View error context:
'-no context-'
```
Th bridge module was intrdocued in odoo#194647 targeting to version `saas~18.2`, but we need it for `17.0, 18.0, saas~18.1` as you see in the example above. This PR will only target to `18.0` and `saas~18.1`.
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-prFixes an issue that prevented users from filtering account placeholder codes from the interface. Searches such as "starts with" and "ends with" now work correctly, avoiding invalid filter errors.
Original PR description
Current behavior before PR: - After this [fix](https://github.com/odoo/odoo/commit/56d5c9f4861b3509043660c97a702bfe0e636e3f) , any type searching is not possible for `placeholder_code` field. - For every filter applied, it just return `invalid domain error`. - this is because ` _search_placeholder_code` uses `=like` operator, but this makes it, unsearchable from frontend, as filters supports `ilike` and its related operators.  Desired behavior after PR is merged: - This PR fixes this issue, by changing the operator from `=like` -> `=ilike` - `placeholder_code` field can now be searched for filters like `starts with` and `ends with` .  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The IAP module now handles connection failures more cleanly when external Odoo services cannot be reached. This prevents low-level connection errors from surfacing and helps keep error handling consistent for users and support teams.
Original PR description
This error occurs when the `IAP` service is `unreachable` when calling the JSON-RPC in IAP. ConnectionError: HTTPSConnectionPool(host='extract.api.odoo.com', port=443) At [1] `ValueError` is now raised and handled connection errors separately because this can also be raised from `requests.post` This commit will raise a `ValueError` instead of the `ConnectionError` Link [1] : https://github.com/odoo/odoo/blob/62ca36f5a347a230eda3cec2d31797fef0c7a13d/addons/iap/tools/iap_tools.py#L140 Sentry - 6280660773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers can now use their eWallet in the Point of Sale after their barcode is scanned. This fixes a checkout issue where the customer was recognized but available loyalty or eWallet rewards were not refreshed, preventing eWallet payment use.
Original PR description
Description of the issue/feature this PR addresses: Steps to reproduce: - Create a POS - Enable discount, promo & loyalty - Create a customer, set the PoS barcode information - Create an eWallet for a customer - Scan the barcode in POS - Partner is set but then no eWallet could be applied Current behavior before PR: Cannot use eWallet payment after scanning partner barcode Desired behavior after PR is merged: Will be able to use eWallet payment after scanning partner barcode task: opw-4572313 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes several automated guided tests more reliable by adding waits and timing adjustments where pages or editors were not ready yet. It also modernizes barcode test coverage, helping reduce false failures and improve confidence in future changes without changing customer-facing features.
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
Delivery reports now show the shipping weight based only on products that are actually set to ship, even before the delivery is completed. This prevents overstated package weights when some items on an order have zero quantity to deliver.
Original PR description
Steps to reproduce the bug:
- Create two storable products:
- P1, weight: 1KG
- P2, weight: 2KG
- Create a delivery order:
- 1 unit of P1 and P2
- Mark it as "To Do"
- Set the quantity to 1 for P1 and 0 for P2
- Print the operation type
Problem:
Only product P1 appears in the report, but the total weight is 3KG instead of 1KG.
opw-4547704This fixes an unreliable automated test in the inventory batch picking area by ensuring the test updates the intended single-line picking. It helps keep validation builds stable and reduces false failures during development, with no expected impact on end users.
Original PR description
This commit avoids random error in test_group_by_country_and_product For more information: - https://runbot.odoo.com/odoo/action-573/114881 - https://runbot.odoo.com/odoo/runbot.build.error/116798 The error is caused because there are two pickings: one with a single move and the other with two moves. In the test, we should modify the move line that is alone. Since the order was not checked, the action done for the wave could return a wizard to create a backorder because we modified the quantity of a move line to 0 in a picking that has multiple move lines.
This fixes Norway VAT reporting so purchases from abroad include both outgoing and incoming VAT where required. It also standardizes VAT tag and code names and uses the correct receivable VAT account, helping businesses produce more accurate Norwegian tax reports.
Original PR description
This PR fixes errors in VAT for Norway. VAT for purchase from abroad: code 81, 83, 86, 88, 91 needs both outgoing and incoming VAT. All VAT codes and tags have got names with "base", "out" or "in" instead of "base" and "tax". - Tags: number **+** Base / VAT Out / VAT In - Codes: BASE / OUT / IN **_** number Outgoing VAT for purchases is reported with positive number by having opposite +/-. Receivable VAT account is 1640. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when users reload Point of Sale store sample data after archiving or deleting a previously created store. It clears old combo product links before recreating the sample products, making the setup flow more reliable for Point of Sale and restaurant scenarios.
Original PR description
*=point_of_sale,pos_restaurant Currently an exception was generated when the user clicked on "Furnitures" in the Choose Your Store section after following the below steps: - Created database without…
*=point_of_sale,pos_restaurant Currently an exception was generated when the user clicked on "Furnitures" in the Choose Your Store section after following the below steps: - Created database without demo and install 'Point of Sale' - Open 'Point of Sale' > Click on "Furnitures" in the Choose Your Store - Archive "Furniture Shop" POS - Click on "Furnitures" in the Choose Your Store - Delete "Furniture Shop" POS - Again, click on "Furnitures" in the Choose Your Store » error generated This is because [1] tries to create a combo product, but it was already created the first time when we loaded data by clicking "furniture", so it generates a validation error from [2] because we cannot link the same product in a combo. This commit solves the above issue by using 'Command.clear()' at [1], which is clear linked combo product before creating it, so it always sets product from data when user loads data. [1] - https://github.com/odoo/odoo/blob/64515f56b3987ffdea6618eb14b6062f95542ac6/addons/product/data/product_demo.xml#L619-L638 [2] - https://github.com/odoo/odoo/blob/64515f56b3987ffdea6618eb14b6062f95542ac6/addons/product/models/product_combo.py#L73 sentry-6101630952
This update brings the embedded spreadsheet engine up to its latest version, improving reliability in collaborative editing, sheet duplication, pivots, tables, and charts. Users should see fewer crashes or inconsistent spreadsheet results, plus a new LOG calculation function and better chart behavior.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/2ee4347c0 [REL] 18.0.17 Task: 0 https://github.com/odoo/o-spreadsheet/commit/6f7a9b8cc [FIX] uuid: remove black magic…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/2ee4347c0 [REL] 18.0.17 Task: 0 https://github.com/odoo/o-spreadsheet/commit/6f7a9b8cc [FIX] uuid: remove black magic to generate uuid Task: 4574102 https://github.com/odoo/o-spreadsheet/commit/5f4172ddf [IMP] monkey party: add a command to run monkey party test Task: 0 https://github.com/odoo/o-spreadsheet/commit/d49bdc409 [FIX] tests: remove mock uuid Task: 0 https://github.com/odoo/o-spreadsheet/commit/2bd8a6c50 [FIX] data: migration 14.5 never run Task: 0 https://github.com/odoo/o-spreadsheet/commit/9466887a1 [IMP] functions: add LOG function Task: 4547230 https://github.com/odoo/o-spreadsheet/commit/5ee8d30f0 [FIX] Charts: Hide datasets instead of filtering them Task: 4577744 https://github.com/odoo/o-spreadsheet/commit/0e2ec1186 [IMP] tests: improve toHaveSynchronizedExportedData perf Task: 0 https://github.com/odoo/o-spreadsheet/commit/271263608 [FIX] tables: duplicate table in deterministic order Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/800b49183 [FIX] pivot: deep copy pivot data Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/8a3df400e [FIX] table: reject cmd with range on invalid sheet Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/355119795 [FIX] pivot: reject command with invalid pivot id Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/8e5c69d19 [FIX] evaluation: re-trigger evaluation after DUPLICATE_SHEET Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/14df1301f [FIX] evaluation: invalidate on concurrent dropped command Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/fb7f1e4ce [FIX] header_position: compute only existing sheets Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/691b98d03 [IMP] jest: add toHaveSynchronizedEvaluation matcher Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/622bf5ad5 [FIX] charts: duplicate chart in deterministic order Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/847087f88 [FIX] header_positions: compute positions for concurrent new sheets Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/4d89445c8 [FIX] data_validation: don't crash `allowDispatch` Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/46f067621 [FIX] collaborative: rebase pending concurrently with undo Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/4fc85398d [FIX] sheet: concurrently create sheet with the same id Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/d55daeb27 [FIX] sheet: prevent duplicating with the same id Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/be0a36dad [FIX] cell: delete cells on sheet deletion Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/42ab04fb8 [FIX] CF: reject invalid range sheet Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/2b7e74ea7 [IMP] tests: collaborative monkey party Task: 4567308 https://github.com/odoo/o-spreadsheet/commit/0938e4d81 [FIX] pie_chart: use chart background for border color Task: 4570603 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fixes how Odoo handles server actions that run several steps together. It helps ensure these automated actions use the correct processing approach, reducing the risk of errors or incomplete business workflows.
Original PR description
la la la
Spreadsheet pivot tables now use the correct day of the week when users work in languages or locales where the week does not start on Sunday. This prevents mismatches between the day shown in the spreadsheet and the records opened from that pivot value.
Original PR description
Steps to reproduce: - change your language to French (or any language which doesn't the week on Sundays) - insert a pivot into a spreadsheet - insert the dynamic version with =PIVOT(1) - change the row groups to "Day of week" - right click on any pivot value and "See records" => the day of week displayed in spreadsheet doesn't match the records. Task: 4591993 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
This pull request mainly streamlines internal test setup across several Odoo Enterprise apps, reducing unnecessary mail-related test data and making tests easier to maintain. It also prevents marketing automation processes from committing database changes during test mode, improving reliability and supporting future scalability work.
Manufacturing planning cells now stay on one line unless their contents would overflow, making the view cleaner while still readable. The update also improves demand cell colors for dark mode and preserves spacing around separators.
Original PR description
Due to input cell overflow, a stopgap solution was to always display demand and replenish cells on 2 lines when actual and forecasted/replenish were both activated. This is considered sub-optimal and this fix was made. When the view is loaded or reloaded due to manual changes, the DOM is updated depending on if overflow is detected in input cells. task 4420441
This update makes an automated test for Ecuador electronic delivery guides use a fixed date. That prevents date-related failures and helps ensure future checks remain reliable without changing user-facing behavior.
Original PR description
In 33509a095 we introduced a check on the data sent to the SRI. The data depends on the current date, but the test didn't execute in a `freeze_time` block. We now fix this. task-none
Spreadsheet pivot tables now match day-of-week values correctly for users in languages where weeks do not start on Sunday. This prevents users from opening the wrong underlying records when reviewing pivot results.
Original PR description
See community PR Steps to reproduce: - change your language to French (or any language which doesn't the week on Sundays) - insert a pivot into a spreadsheet - insert the dynamic version with =PIVOT(1) - change the row groups to "Day of week" - right click on any pivot value and "See records" => the day of week displayed in spreadsheet doesn't match the records. Task: 4591993
Miscellaneous changes
config['demo'] is always set at runtime, there is no point in saving it as it is basically ignored from the config file. Forward-Port-Of: odoo/odoo#198387 Forward-Port-Of: odoo/odoo#189032
Original PR description
config['demo'] is always set at runtime, there is no point in saving it as it is basically ignored from the config file. Forward-Port-Of: odoo/odoo#198387 Forward-Port-Of: odoo/odoo#189032
The Wi-Fi disconnection method was still unlinking an old configuration file, which is now replaced by the `odoo.conf` file. This fix replaces the file unlinking by a coniguration file update. Task: 4592796 Forward-Port-Of: odoo/odoo#198962
Original PR description
The Wi-Fi disconnection method was still unlinking an old configuration file, which is now replaced by the `odoo.conf` file. This fix replaces the file unlinking by a coniguration file update. Task: 4592796 Forward-Port-Of: odoo/odoo#198962
Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back who the recipients were. In this work we also log the (redacted) From and To headers. We decided to redact the headers out of excessive caution regarding the GDPR. The new `email_anonymize` function must balance disambiguation and redaction. Disambiguation so it is easy to tell two different emai
Original PR description
Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back…
Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back who the recipients were. In this work we also log the (redacted) From and To headers. We decided to redact the headers out of excessive caution regarding the GDPR. The new `email_anonymize` function must balance disambiguation and redaction. Disambiguation so it is easy to tell two different email addresses appart (for debugging). Redaction so it hard to find the original email address back (for privacy). It must also be simple. We conducted several experiments using a dataset of 600ish email address (95% of which have a local part that is at least 6 characters long) to determine a nice function. The final function keep the first character for shorter inputs (length of local part < 6) and the first plus two lasts chars for longer inputs (>=6). Using that function we achieve a 99% disambiguation of emails in the dataset (with or without redacting the domain) while retaining minimal info (3 chars at most). Redacting the domain isn't that useful as most addresses use gmail, hotmail, outlook, yahoo. Task-4361561 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#194507 Forward-Port-Of: odoo/odoo#188697
Indonesia officially added new provinces in 2022. - Papua Barat Daya was forgotten in an old PR. - Papua Pengunungan was assigned ISO code PE, not PP. In 16.0, we just change the ISO code. The XMLID will be corrected in master. Codes: https://www.geonames.org/ID/administrative-division-indonesia.html Official Document: https://peraturan.bpk.go.id/Details/232726/uu-no-29-tahun-2022 Wikipedia in English: https://en.wikipedia.org/wiki/Provinces_of_Indonesia Original PR: odoo/
Original PR description
Indonesia officially added new provinces in 2022. - Papua Barat Daya was forgotten in an old PR. - Papua Pengunungan was assigned ISO code PE, not PP. In 16.0, we just change the ISO code. The XMLID will be corrected in master. Codes: https://www.geonames.org/ID/administrative-division-indonesia.html Official Document: https://peraturan.bpk.go.id/Details/232726/uu-no-29-tahun-2022 Wikipedia in English: https://en.wikipedia.org/wiki/Provinces_of_Indonesia Original PR: odoo/odoo#193103 Forward-Port-Of: odoo/odoo#199035
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field
Original PR description
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given…
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field `team_id` is added. This field is a computed-stored field with a callable set as default. Because the default attr is defined, the ORM skips the call to the compute method and calls the default function instead when the team_id param is not given upon creation. That means that for each account.move, `_get_default_team_id` is called. Since the purpose of a compute function is already to give default values to record, removing the default callable allows to benefit from the batching of compute functions. #### speedup Test database with account_accountant and sale. Trying to create batches of account.moves | Batch size | Before PR | After PR | |:----------:|:---------:|:--------:| | 1 | 70ms | 58ms | | 50 | 150ms | 100ms | | 100 | 275ms | 188ms | | 250 | 660ms | 450ms | | 1000 | 2.43s | 1.75s | | 3000 | 7.55s | 5.33s | Average speedup: 68%. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160313 Forward-Port-Of: odoo/odoo#157887
- In calendar, when only one employee (different from the user) was selected as an attendeed in the calendar sidebar, the working location of this employee was not displayed. To work around this, switch to `multiCalendar` in that case. - When the current user was not selected as an attendee, it was possible to add a working location for the user on a day even if there was already an exisiting one. To avoid this, always fetch the user's working location to check if one already exists for a giv
Original PR description
- In calendar, when only one employee (different from the user) was selected as an attendeed in the calendar sidebar, the working location of this employee was not displayed. To work around this, switch to `multiCalendar` in that case. - When the current user was not selected as an attendee, it was possible to add a working location for the user on a day even if there was already an exisiting one. To avoid this, always fetch the user's working location to check if one already exists for a given day, but only display them if the user's filter is active. - Work locations were not displayed when "Everybody's calendar" was selected because the elements of `attendeeIds` had the wrong type. opw-4373391 Forward-Port-Of: odoo/odoo#192023
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the corresponding stock.move.line still retains the old product (Product A). This leads to inconsistent data between stock.move and stock.move.line, which can cause inaccurate inventory reports and accounting records. **Steps to Reproduce** 1. Create a BoM (Bill of Materials) that includes Product A
Original PR description
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the…
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the corresponding stock.move.line still retains the old product (Product A). This leads to inconsistent data between stock.move and stock.move.line, which can cause inaccurate inventory reports and accounting records. **Steps to Reproduce** 1. Create a BoM (Bill of Materials) that includes Product A as a by-product with a quantity of 1. 2. Create a Manufacturing Order (MO) from this BoM. 3. Confirm the MO and set it to In Progress. 4. In the MO interface: Change the by-product from Product A to Product B. 5. Complete the MO. https://github.com/user-attachments/assets/811e181d-894d-4605-aeb9-027ff379d40d **Current Behavior** The product in the stock.move is updated to Product B. However, the product in the related stock.move.line remains as Product A. **Expected Behavior** The byproduct's product_id shouldn't even be editable in the first place when the MO has already been confirmed (as it is for components). It would be worth to add the same kind of readonly condition on the byproduct side as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198522 Forward-Port-Of: odoo/odoo#194972
The CRON has to search for documents that are not in error because they are filtered out in _process_jobs. Without that, the documents are retrieved, not processed but the cron is triggered again and again endlessly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198973
Original PR description
The CRON has to search for documents that are not in error because they are filtered out in _process_jobs. Without that, the documents are retrieved, not processed but the cron is triggered again and again endlessly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198973
This commit fills in the missing prop of the ShortcutsFooterComponent which was forgotten in https://github.com/odoo/odoo/commit/dd583fd670e0ee03b04711780bad2429b18a0788 Forward-Port-Of: odoo/odoo#199057
Original PR description
This commit fills in the missing prop of the ShortcutsFooterComponent which was forgotten in https://github.com/odoo/odoo/commit/dd583fd670e0ee03b04711780bad2429b18a0788 Forward-Port-Of: odoo/odoo#199057
Issue: ======== In `SplitBillScreenTour2`, navigating back and forth between **FloorScreen** and **ProductScreen** triggered a `SyncAllOrders` call. Immediately after, another `SyncAllOrders` call was sent from `createSplittedOrder`. Since the first request was still in progress, the second request sometimes sent only one order to the backend. This caused the original order to be filtered out from `syncingOrders`, leading to inconsistencies. Fix: ======= Step were added to check tha
Original PR description
Issue: ======== In `SplitBillScreenTour2`, navigating back and forth between **FloorScreen** and **ProductScreen** triggered a `SyncAllOrders` call. Immediately after, another `SyncAllOrders` call was sent from `createSplittedOrder`. Since the first request was still in progress, the second request sometimes sent only one order to the backend. This caused the original order to be filtered out from `syncingOrders`, leading to inconsistencies. Fix: ======= Step were added to check that the request is processed. **Runbot Error**: 114938 Forward-Port-Of: odoo/odoo#198326
The Romanian SPV servers are slow. When sending a request to them, we previously set a hard timeout limit at 10 seconds and mark the request as failed if it exceeds it. However, recently we have found a critical issue where some users found that their invoice has been sent twice (or more) to the Romanian SPV. After investigating, we found that what's likely to happen is that the SPV takes more than 10 seconds to send the response back when we're making a request, and since in our side we c
Original PR description
The Romanian SPV servers are slow. When sending a request to them, we previously set a hard timeout limit at 10 seconds and mark the request as failed if it exceeds it. However, recently we have…
The Romanian SPV servers are slow. When sending a request to them, we previously set a hard timeout limit at 10 seconds and mark the request as failed if it exceeds it. However, recently we have found a critical issue where some users found that their invoice has been sent twice (or more) to the Romanian SPV. After investigating, we found that what's likely to happen is that the SPV takes more than 10 seconds to send the response back when we're making a request, and since in our side we consider the request as failed and requires the user to send a new request again, we make the user send a second request on the same invoice, where the SPV actually acknowledges all of the received invoices. After discussing with the PO, a temporary workaround for now is to increase the timeout limit to 60 seconds (1 full minute) to reduce the likelihood of this issue happening, and log error messages on the chatter if the request (either for send/fetch/download) failed, so that the user are aware when it is timeout and be more wary not to send another request right away, in case the new timeout limit are still not enough. Other small changes in this PR: - Handle response code 401, (which is a JSON object, invalid access token) - Remove the "Error when sending the document to the SPV:" template in error documents (because not all error documents are for sending, some are from fetch/download) opw-4571713 Forward-Port-Of: odoo/odoo#198876 Forward-Port-Of: odoo/odoo#198604
**[FIX] account: fix empty string and False/None inconsistencies** When empty, the `name` field of `account.move.line` could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as `label->not set` and `label == ""` yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is an empty string, standa
Original PR description
**[FIX] account: fix empty string and False/None inconsistencies** When empty, the `name` field of `account.move.line` could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as `label->not set` and `label == ""` yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is an empty string, standardizing search behavior. opw-4167139 [Enterprise PR](https://github.com/odoo/enterprise/pull/73256) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189099 Forward-Port-Of: odoo/odoo#186079
Before this patch, if a billing user (without any administration settings level) tried to cancel a posted invoice and clicked on the "Process now" button, they got an exception. In particular, it happened because those users shouldn't have access to stuff such as the certificate, its password or the contents of the sent EDI attachment. However, they should be able to post the documents using whatever configuration the sysadmin saved. Thus, I use some `sudo()` calls and add a test to assert
Original PR description
Before this patch, if a billing user (without any administration settings level) tried to cancel a posted invoice and clicked on the "Process now" button, they got an exception. In particular, it…
Before this patch, if a billing user (without any administration settings level) tried to cancel a posted invoice and clicked on the "Process now" button, they got an exception. In particular, it happened because those users shouldn't have access to stuff such as the certificate, its password or the contents of the sent EDI attachment. However, they should be able to post the documents using whatever configuration the sysadmin saved. Thus, I use some `sudo()` calls and add a test to assert it won't break anymore. **How to test functionally:** 1. Configure a Spanish company. 2. Install `l10n_es_edi_tbai` and configure it. 3. Switch to a user that only has "Invoicing / Billing" permissions. 4. Post an invoice. 5. Send it to tbai. 6. Request EDI cancellation. 7. Send it to tbai. 8. It should work now. @moduon MT-8894 OPW-4535149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196086 Forward-Port-Of: odoo/odoo#195981
The module base_vat add a div around the vat field and so the xpath place the field in the div which is not what we want. By putting it after the address we are sure that those field are rightly placed task: 4543204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196598
Original PR description
The module base_vat add a div around the vat field and so the xpath place the field in the div which is not what we want. By putting it after the address we are sure that those field are rightly placed task: 4543204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196598
Steps to reproduce: - Set up the editor with a link at the end of a line. - Refresh to start with fresh content. - Place the cursor at the end of the line with the link. - Notice that the cursor defaults inside the link, displaying the green overlay. - Attempt to type after the link—this requires pressing right arrow key to exit. Description of the issue/feature this PR addresses: - Clicking at the end or start of a line with a link placed the cursor inside the link by default, disp
Original PR description
Steps to reproduce: - Set up the editor with a link at the end of a line. - Refresh to start with fresh content. - Place the cursor at the end of the line with the link. - Notice that the cursor defaults inside the link, displaying the green overlay. - Attempt to type after the link—this requires pressing right arrow key to exit. Description of the issue/feature this PR addresses: - Clicking at the end or start of a line with a link placed the cursor inside the link by default, displaying the green overlay. - Typing outside the link required pressing the arrow key. Current behavior before PR: - Placing the cursor at the start or end of a line with a link now defaults to positioning it outside the link. - Green overlay is no longer shown, enabling direct text entry beside link. - Accessing the link requires an intentional left or right arrow key press. task-4089085 Forward-Port-Of: odoo/odoo#186213
Currently, if an email containing a `.eml` attachment is sent, that attachment won't be able to be downloaded correctly depending on the email client used; the attachment will download, but will have a size zero. ### Steps to reproduce * On any chatter, send a message containing a `.eml` attachment (another email file). * Using Thunderbird, attempt to download that attachment. The downloaded attachment will be empty (0 kB). ### Cause The `.eml` file format, which represents an em
Original PR description
Currently, if an email containing a `.eml` attachment is sent, that attachment won't be able to be downloaded correctly depending on the email client used; the attachment will download, but will have…
Currently, if an email containing a `.eml` attachment is sent, that attachment won't be able to be downloaded correctly depending on the email client used; the attachment will download, but will have a size zero. ### Steps to reproduce * On any chatter, send a message containing a `.eml` attachment (another email file). * Using Thunderbird, attempt to download that attachment. The downloaded attachment will be empty (0 kB). ### Cause The `.eml` file format, which represents an email message, has the MIME type `message/rfc822`. According to [RFC 2046 Section 5.2.1](https://datatracker.ietf.org/doc/html/rfc2046#section-5.2.1:~:text=No%20encoding%20other%20than%20%227bit%22%2C%20%228bit%22%2C%20or%20%22binary%22%20is%20permitted%20for%0A%20%20%20the%20body%20of%20a%20%22message/rfc822%22%20entity.), attachments of this MIME type must be encoded using `7bit`, `8bit`, or `binary`. However, the system currently encodes all attachments using Base64 by default, which is not compliant with the standard for `message/rfc822`. Although some email clients tolerate Base64 encoding for `message/rfc822`, others, such as Thunderbird, Roundcube, and Zimbra, strictly follow the RFC and reject Base64-encoded `message/rfc822` attachments. As a result, these attachments appear invalid and are downloaded as empty files. opw-4126522 Forward-Port-Of: odoo/odoo#198862 Forward-Port-Of: odoo/odoo#194988
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle customer accounts. Steps to reproduce: ------------------- * Install **l10n_es_pos** and switch to the ES Company * Open shop session * Add products to the order, select any customer, pay with customer account * Select **New order** * Select the previous customer and select **Settle due accou
Original PR description
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle…
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle customer accounts. Steps to reproduce: ------------------- * Install **l10n_es_pos** and switch to the ES Company * Open shop session * Add products to the order, select any customer, pay with customer account * Select **New order** * Select the previous customer and select **Settle due accounts** * Select any payment method * Validate order -> Yes > Observation: Cannot invoice empty order Why the fix: ------------ Spain requires to invoice all orders. In Pos, everything is considered as an order but settling customer accounts does not fall under the definition of an order outside of Odoo (no transfer of product, amount=0). Therefore when we settle customer account we skip the automatic invoicing and fallback on the pos bahavior without the localization. opw-4185144 Enterprise PR: https://github.com/odoo/enterprise/pull/71958 Forward-Port-Of: odoo/odoo#185375 Forward-Port-Of: odoo/odoo#183682
Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because the account_group ID is used to browse the account, due to a more specific account_group. Steps to reproduce: 1. Install l10n_mx_reports. 2. Create an account_group with a more specific account, such as 401.01.01 - The 4, 401, and 401.01 groups are created with demo data. 3. Go to trial balance and try exporting with "SAT (XML)". 4. An error will occur (Missing Record) beca
Original PR description
Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because the account_group ID is used to browse the account, due to a more specific account_group. Steps to reproduce: 1. Install l10n_mx_reports. 2. Create an account_group with a more specific account, such as 401.01.01 - The 4, 401, and 401.01 groups are created with demo data. 3. Go to trial balance and try exporting with "SAT (XML)". 4. An error will occur (Missing Record) because the account_group ID is used to browse the account. This fix does two things: 1. It ensures that only account.account lines are considered. 2. It changes the line length condition from `= 4` to `>= 4` to handle more specific grouping. opw-4537859 Forward-Port-Of: odoo/enterprise#80128
The kanban has been reworked with https://github.com/odoo/odoo/pull/167751 and odoo/enterprise@23426182d92198cf977d7eecbfb3d47117d80c59 Before this commit when a field is empty (the record has no value for a field) in the kanban editor -- new version -- that field had no size and was virtually invisible. This was because one little line of code was missing to enable the feature of applying a placeholder in the empty field to make it visible. opw-4526492 Forward-Port-Of: odoo/enterprise
Original PR description
The kanban has been reworked with https://github.com/odoo/odoo/pull/167751 and odoo/enterprise@23426182d92198cf977d7eecbfb3d47117d80c59 Before this commit when a field is empty (the record has no value for a field) in the kanban editor -- new version -- that field had no size and was virtually invisible. This was because one little line of code was missing to enable the feature of applying a placeholder in the empty field to make it visible. opw-4526492 Forward-Port-Of: odoo/enterprise#79812
In the expense app, a button enables to refund an expense directly in the payslip. This button is however not visible for payroll manager, while the action behind is. This commit solves the issue. task-4570975 Forward-Port-Of: odoo/enterprise#79879 Forward-Port-Of: odoo/enterprise#79570
Original PR description
In the expense app, a button enables to refund an expense directly in the payslip. This button is however not visible for payroll manager, while the action behind is. This commit solves the issue. task-4570975 Forward-Port-Of: odoo/enterprise#79879 Forward-Port-Of: odoo/enterprise#79570
In the follow up process, while the wizard's text is displayed correctly, the text in the chatter and in the pdf would contain too many carriage returns. The error is linked to the use of the text widget in the xml, which doesn't seem necessary in this case and is therefore removed. task-4574941 Forward-Port-Of: odoo/enterprise#79925 Forward-Port-Of: odoo/enterprise#79517
Original PR description
In the follow up process, while the wizard's text is displayed correctly, the text in the chatter and in the pdf would contain too many carriage returns. The error is linked to the use of the text widget in the xml, which doesn't seem necessary in this case and is therefore removed. task-4574941 Forward-Port-Of: odoo/enterprise#79925 Forward-Port-Of: odoo/enterprise#79517
Steps to reproduce: - With an MX Company Setup - Issue an invoice with external trade - Print pdf Issue: Partner original RFC is shown, but according to our documentation [1] and official documentation [2] as well, we should display the generic RFC for external partners XEXX010101000 [1] https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/mexico.html#external-trade [2] https://www.sat.gob.mx/articulo/99662/articulo-29-a page 59 "15. ¿Qué datos debe cont
Original PR description
Steps to reproduce: - With an MX Company Setup - Issue an invoice with external trade - Print pdf Issue: Partner original RFC is shown, but according to our documentation [1] and official documentation [2] as well, we should display the generic RFC for external partners XEXX010101000 [1] https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/mexico.html#external-trade [2] https://www.sat.gob.mx/articulo/99662/articulo-29-a page 59 "15. ¿Qué datos debe contener la versión impresa del comprobante fiscal? En la representación impresa se incluirán como mínimo los datos establecidos en la regla 2.7.1.7. de la RMF. Fundamento: Regla 2.7.1.7. de la RMF. " opw-4473180 Forward-Port-Of: odoo/enterprise#79979 Forward-Port-Of: odoo/enterprise#79527
**[FIX] account_asset: fix empty string and False/None inconsistencies** (adapting tests) When empty, the name field of account.move.line could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as label->not set and label == "" yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is
Original PR description
**[FIX] account_asset: fix empty string and False/None inconsistencies** (adapting tests)
When empty, the name field of account.move.line could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as label->not set and label == "" yielded different outcomes. The latter behavior aligns with expected ORM operations.
This fix ensures the name field is set to False whenever the computed result is an empty string, standardizing search behavior. We also adapt some tests to the new behavior in enterprise.
opw-4167139
[community PR](https://github.com/odoo/odoo/pull/186079)
Forward-Port-Of: odoo/enterprise#74855
Forward-Port-Of: odoo/enterprise#73256After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold. Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all. In this commit, we improv
Original PR description
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that…
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold. Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all. In this commit, we improve the styling rules to always disable bold on the deepest line level. That way we can never have a XLSX file with all lines in bold, and it is much easier to read the file. Meanwhile, the style management was refactored a bit to make it simpler. [opw-4501822](https://www.odoo.com/odoo/project.task/4501822) [opw-4458752](https://www.odoo.com/odoo/project.task/4458752) [indentation fix]: https://github.com/odoo/enterprise/commit/9246a864f91e7facd06fa630fa0d23a0323ce497 Forward-Port-Of: odoo/enterprise#79764 Forward-Port-Of: odoo/enterprise#77510
Problem Before this commit, if the customer deletes the rental location they would be blocked from creating a rental order as it is necessary for replenishment rules. The issue becomes critical because, once deleted, the rental location cannot be set to the company functionally given the field is not present in the view. Solution To fix this, this commit adds Rental Settings making the rental_loc_id field visible in the res_company view, allowing customers to select their desired rental
Original PR description
Problem Before this commit, if the customer deletes the rental location they would be blocked from creating a rental order as it is necessary for replenishment rules. The issue becomes critical because, once deleted, the rental location cannot be set to the company functionally given the field is not present in the view. Solution To fix this, this commit adds Rental Settings making the rental_loc_id field visible in the res_company view, allowing customers to select their desired rental location and resolve the issue independently. - opw-3973957 - opw-4488182 - opw-4545985 Forward-Port-Of: odoo/enterprise#79894 Forward-Port-Of: odoo/enterprise#79785
Because of the countries flag set in the module manifest, the module was set to be auto-installed only when there was a company with country 'CZ' existing. Although this can't really be pointed as a mistake, it was causing an error in account_reports TestAllReportsGeneration.test_generate_all_export_files, as we'd be simply installing the module l10n_cz_reports and expect everything to be set and tested. runbot error: 114355 Forward-Port-Of: odoo/enterprise#79524
Original PR description
Because of the countries flag set in the module manifest, the module was set to be auto-installed only when there was a company with country 'CZ' existing. Although this can't really be pointed as a mistake, it was causing an error in account_reports TestAllReportsGeneration.test_generate_all_export_files, as we'd be simply installing the module l10n_cz_reports and expect everything to be set and tested. runbot error: 114355 Forward-Port-Of: odoo/enterprise#79524
This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts. opw-4185144 Community PR: https://github.com/odoo/odoo/pull/183682 Forward-Port-Of: odoo/enterprise#72843 Forward-Port-Of: odoo/enterprise#71958
Original PR description
This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts. opw-4185144 Community PR: https://github.com/odoo/odoo/pull/183682 Forward-Port-Of: odoo/enterprise#72843 Forward-Port-Of: odoo/enterprise#71958
Steps to reproduce the bug: - Create a “quality.point”: - Operations: Manufacturing - Add a Work Order Operation - save - Update the operations to Receipt. Problem: The Work Order Operation field becomes invisible, but it is still filled so the quality point will still be applied. opw-4536136 Forward-Port-Of: odoo/enterprise#79929 Forward-Port-Of: odoo/enterprise#79868
Original PR description
Steps to reproduce the bug:
- Create a “quality.point”:
- Operations: Manufacturing
- Add a Work Order Operation
- save
- Update the operations to Receipt.
Problem:
The Work Order Operation field becomes invisible, but it is still filled so the quality point will still be applied.
opw-4536136
Forward-Port-Of: odoo/enterprise#79929
Forward-Port-Of: odoo/enterprise#79868The appointment addon adds the `@mail/utils/common/format` module to the frontent assets. However, this module depends on another one: `@mail/utils/common/html`, which isn't there. As a consequence there's a red banner displayed in the bottom left corner, indicating that there's an odoo module issue, in all websites when the appointment addon is installed. This is causing a lot of trouble with free trials. This commit adds the missing dependency. Forward-Port-Of: odoo/enterprise#80079
Original PR description
The appointment addon adds the `@mail/utils/common/format` module to the frontent assets. However, this module depends on another one: `@mail/utils/common/html`, which isn't there. As a consequence there's a red banner displayed in the bottom left corner, indicating that there's an odoo module issue, in all websites when the appointment addon is installed. This is causing a lot of trouble with free trials. This commit adds the missing dependency. Forward-Port-Of: odoo/enterprise#80079
Problem --------- Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...) One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default. But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration
Original PR description
Problem --------- Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...) One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default. But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration of the level. This always generates an additional PDF that is often not needed. Objective --------- Do not tick "Print" by default when manually executing a follow-up level, unless "Letter" is ticket in the configuration of the level. Solution --------- Set "Print" default value in the wizard to the "Letter" value of the follow up line instead of leaving it as True (which is the default). task-4574971 Forward-Port-Of: odoo/enterprise#79829