Friday, February 11, 2022
28 changes · master
Enhancements to existing features
Accounting test data generation now includes random taxes on journal lines. This helps teams create more realistic datasets for evaluating tax report performance, without changing day-to-day accounting workflows.
Original PR description
It could be useful on testing performance of the Tax Report task-2744273
Odoo's internal Chrome-based test setup can now run on Windows as well as Linux-like systems. This improves development and quality assurance flexibility for teams using Windows workstations or CI environments.
Original PR description
Before this commit there is no support to run chrome js tests on Windows. After this commit there is this support. This is follow up of https://github.com/odoo/odoo/pull/83067 For master I suggest completely rewritten method `_spawn_chrome` comparing to more compact diff for stable branches in https://github.com/odoo/odoo/pull/83067 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website pages now avoid extra background requests when an administrator or publisher is signed in. This reduces page overhead and should make browsing and editing the website feel faster and more efficient.
Original PR description
This improvement remove 12 requests on all page when the user is connected with published access.
Burger menu test coverage has been moved into the community web module where it can run independently. This improves maintainability and helps ensure mobile navigation behavior is validated without relying on enterprise-only test suites.
Original PR description
Follow-up odoo/enterprise@3f78e5ade6b8edddeba5b433bfde98ade560255d Standalone burger menu tests are moved to community, while we leave other enterprise dependent tests in enterprise.
The eSignature app now identifies templates without searching through the large attachment storage area. This should make template lookups more efficient and avoid unnecessary permission checks behind the scenes.
Original PR description
Solution by IEL, explanation from ODO: `sign.template` uses `attachment_id` as its `_rec_name`, which means that searching for a template requires searching through the whole `ir.attachment` table. That's bad for several reasons: - `ir.attachment` is an internal low-level table (as indicated by the `ir.` prefix) and shouldn't be accessed like a first-party business model - `ir.attachment` is a huge table that represents the entire filestore, so searching through it is naturally slow, it's meant to be referenced by `res_model`, `res_id` keys, not searched cross-model - `ir.attachment` has a complicated permission system, so not only is searching expensive, it also requires some costly post-processing for filtering results task-2677771
Burger menu tests that do not depend on Enterprise-only features have been moved to the shared Community codebase. This keeps Enterprise testing focused on Enterprise-specific behavior while improving reuse and maintainability across editions.
Original PR description
Follow-up odoo/enterprise@3f78e5ade6b8edddeba5b433bfde98ade560255d Standalone burger menu tests are moved to community, while we leave other enterprise dependent tests in enterprise.
Resolved issues and error corrections
This update fixes focus handling in Point of Sale screens after an internal change and simplifies how Odoo automatically places the cursor in key input fields. Users should see more reliable typing flow in search, ticket, pager, date picker, and favorite menu areas without any change to business processes.
Miscellaneous changes
fixes the display of boolean fields in the settings form on mobile task 2738716 [Misc] fix settings alignment on mobile Forward-Port-Of: odoo/odoo#83099
Original PR description
fixes the display of boolean fields in the settings form on mobile task 2738716 [Misc] fix settings alignment on mobile Forward-Port-Of: odoo/odoo#83099
This fixes an export error that could occur when users chose the import-compatible export option and selected only the External ID field. The export now completes as expected, preventing a disruptive traceback during report data exports.
Original PR description
Problem occurs when we try to export report data and click 'I want to update data (import-compatible export)'. We might end up exporting data when only field to export is - External ID (id). To reproduce an issue (for example): Go to Time Off/Reporting/by Type; Remove filters from search. Select couple records, then Action/Export. On the wizard, click on 'I want to update data (import-compatible export)'. Click on External ID from 'Available fields' to add it to 'Fields to export'. Click export. It gives traceback - File "/data/build/odoo/addons/web/controllers/main.py", line 710, in write_header self.worksheet.set_column(0, i, 30) # around 220 pixels UnboundLocalError: local variable 'i' referenced before assignment task - 2687370
Images now use default lazy loading only on website pages, not in email marketing content. This prevents email snippets such as cover images from appearing with zero height during editing, making campaign creation more reliable.
Original PR description
The `loading="lazy"` attribute was set by default on all images but this affected the `mass_mailing` module as well while that attribute doesn't work in emails and can cause some issues in edition. One known such issue this addresses is to be reproduced as follows: 1. Create a new mail 2. Drop the "cover" snippet It has height 0 so it won't load until another snippet (with a non-zero height) is dropped. task-2761074 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a visual issue where the chatter area could briefly disappear and reappear when users changed form modes or navigated records. The chatter now stays stable during form updates, making the interface feel smoother and less distracting.
Original PR description
Before this commit, when a form view was re-rendered (e.g. when switching to "edit" or "readonly" modes, when using the pager...), the chatter briefly disappeared and then reappeared, which produced…
Before this commit, when a form view was re-rendered (e.g. when switching to "edit" or "readonly" modes, when using the pager...), the chatter briefly disappeared and then reappeared, which produced a flickering. This has been introduced by the adaptation of the JS codebase to owl 2 [1]: when the form view had to be re-rendered, we reused the DOM element containing the chatter in the new rendering (done in memory), which was thus detached from the DOM. That element was re-inserted into the DOM later on, alongside the rest of the newly rendered elements. This commit fixes the issue by using a specific "hook" element when rendering the form view, and replacing that hook by the actual (unchanged) chatter container element when the rendering is done and the DOM is patched. [1] edd79ff560cf321ebd0488e4917abb7424fea1bb 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
The spreadsheet component was updated to a newer version with fixes for editing edge cases, including merged cells and deleted sheets. This improves reliability for users working with spreadsheets in Documents, while most other changes are internal cleanup and test improvements.
Original PR description
…rsion This commit includes the following changes: [IMP] package: Add demo/*.js files to prettier flow [FIX] edition: check merge cell in the correct sheet [FIX] edition: cancel edition if sheet is deleted [FIX] evaluation: get rid of makeObjectIterator [FIX] demo: fix function makeLargeDataset [REF] env: model is now accessible through the env [REM] components: remove static style declaration [REF] tests: simplify dispatch spyOn [REF] grid: remove model as props [IMP] tests: activate owl dev mode [REF] tests: remove call to __owl__.destroy [REF] spreadsheet: give model as props [REF] model: remove unecessary argument to joinSession [REF] tests: remove Parent component
The Sign document viewer was updated to use the correct icon font file after a platform change moved its location. This prevents signed PDF pages from failing to load properly, helping users continue reviewing and signing documents without interruption.
Original PR description
change the reference of font-awesome.css in the sign.assets_pdf_iframe before this task the location of font-awesome.css is changed in owl2 the sign.assets_pdf_iframe would not be loaded successfully
A modification made by Amazon on October 1st restricts the allowed values for the carrier name. Since it now expects it in a formatted state, this commit will allow Odoo to send the delivery type of the carrier rather than its name, which can be customized by the user. opw-2665099 See also: - https://github.com/odoo/enterprise/pull/23504 Forward-Port-Of: odoo/odoo#84070 Forward-Port-Of: odoo/odoo#82772
Original PR description
A modification made by Amazon on October 1st restricts the allowed values for the carrier name. Since it now expects it in a formatted state, this commit will allow Odoo to send the delivery type of the carrier rather than its name, which can be customized by the user. opw-2665099 See also: - https://github.com/odoo/enterprise/pull/23504 Forward-Port-Of: odoo/odoo#84070 Forward-Port-Of: odoo/odoo#82772
Filtering stock_pickings by selecting the product in the dropdown menu doesn't return anything Steps to reproduce: 1. Install Inventory 2. Go to Inventory > Operations > Transfers 3. In the search field, begin typing the name of a product for which there is a transfer (e.g. Large Cabinet) 4. Click on the small arrow to the left of `Search Product for:` in the dropdown menu 5. Select the product you were typing 6. There is no result to the search even though there are transfers containin
Original PR description
Filtering stock_pickings by selecting the product in the dropdown menu doesn't return anything Steps to reproduce: 1. Install Inventory 2. Go to Inventory > Operations > Transfers 3. In the search…
Filtering stock_pickings by selecting the product in the dropdown menu doesn't return anything
Steps to reproduce:
1. Install Inventory
2. Go to Inventory > Operations > Transfers
3. In the search field, begin typing the name of a product for which there is a transfer (e.g. Large Cabinet)
4. Click on the small arrow to the left of `Search Product for:` in the dropdown menu
5. Select the product you were typing
6. There is no result to the search even though there are transfers containing the product
Solution:
Remove `filter_domain`
The filter will be handled in the backend by `_name_search` of `product.product`, which already covers the same criteria (`default_code`, `name` and `barcode`)
Problem:
The display name (e.g. "[E-COM07] Large Cabinet") wasn't matched by the `filter_domain` because the domain sent in the RPC was:
```
"domain": [
"|",
"|",
[
"product_id.default_code",
"ilike",
"[E-COM07] Large Cabinet"
],
[
"product_id.name",
"ilike",
"[E-COM07] Large Cabinet"
],
[
"product_id.barcode",
"ilike",
"[E-COM07] Large Cabinet"
]
]
```
OPW-2732804
Forward-Port-Of: odoo/odoo#84200Starting january 2022, grid 61 is removed from mod 303. Making the tag inactive ensures we don't show it anymore. Doc: https://sede.agenciatributaria.gob.es/Sede/ayuda/disenos-registro/modelos-300-399.html Forward-Port-Of: odoo/odoo#84171 Forward-Port-Of: odoo/odoo#83736
Original PR description
Starting january 2022, grid 61 is removed from mod 303. Making the tag inactive ensures we don't show it anymore. Doc: https://sede.agenciatributaria.gob.es/Sede/ayuda/disenos-registro/modelos-300-399.html Forward-Port-Of: odoo/odoo#84171 Forward-Port-Of: odoo/odoo#83736
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#84235
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#84235
To reproduce the issue: 1. Produce a SN product P with lot L 2. Unbuild it 3. Produce 1xP with lot L Error: When setting the lot, an error is displayed. When marking the MO as done, a second error is displayed Both domains in `_onchange_lot_producing` and in the beginning of `_check_sn_uniqueness` are incorrect. We should centralize the uniqueness checking thanks to all existing computations in `_check_sn_uniqueness`. This way, unbuilt/scrapped moves will be considered OPW-27212
Original PR description
To reproduce the issue: 1. Produce a SN product P with lot L 2. Unbuild it 3. Produce 1xP with lot L Error: When setting the lot, an error is displayed. When marking the MO as done, a second error is displayed Both domains in `_onchange_lot_producing` and in the beginning of `_check_sn_uniqueness` are incorrect. We should centralize the uniqueness checking thanks to all existing computations in `_check_sn_uniqueness`. This way, unbuilt/scrapped moves will be considered OPW-2721205 Forward-Port-Of: odoo/odoo#84343 Forward-Port-Of: odoo/odoo#83345
Forward-Port-Of: odoo/odoo#84272
Original PR description
Forward-Port-Of: odoo/odoo#84272
[FIX] survey: Don't load answer from other user if a cookie exists To reproduce the issue: 1) Create a survey requiring user login, with multiple pages 2) Create portal user A and B 3) With user A, go to URL /survey/start/****, where **** is the access token of your test survey. Fill in the first pages of the survey, but don't finish your submission (so: the answer has to stay 'in progress'). 4) Logout from user A. 5) From the same browser window (or without cleaning cookies,
Original PR description
[FIX] survey: Don't load answer from other user if a cookie exists To reproduce the issue: 1) Create a survey requiring user login, with multiple pages 2) Create portal user A and B 3) With user A,…
[FIX] survey: Don't load answer from other user if a cookie exists To reproduce the issue: 1) Create a survey requiring user login, with multiple pages 2) Create portal user A and B 3) With user A, go to URL /survey/start/****, where **** is the access token of your test survey. Fill in the first pages of the survey, but don't finish your submission (so: the answer has to stay 'in progress'). 4) Logout from user A. 5) From the same browser window (or without cleaning cookies, at least), directly login with user B, and go to the same /survey/start/**** link ====> The 'in progress' answer from A is loaded, even though we are connected with B and should hence not have access to it. Instead, we should have created a new blank answer for B. This is due to our cookie management. When a cookie is kept in the browser with the token of a previously entered answer, we reload it without checking its owner. [FIX] survey: Avoid forbidding access to survey when the answer cookie corresponds to no actual answer To reproduce: 1) Create a survey and open it with a portal user with its /survey/start/*** link 2) In a private window, connect as the admin and remove the answer in 'Not started yet' state that step 1 created. 3) Go back to your portal user window and re-enter the same /survey/start/*** URL. ==> The portal user is brought back to the home page. He has no way to access the survey anymore, the link will always redirect him there. This is because of cookies. The first time the user opens the survey, it creates a cookie in his browser allowing him to reload the answer he was working on. In our example, this answer has been deleted for some reason (maybe some cleaning of too old 'not started' or 'in progress' stuff); so the token stored in the cookie does not correspond to anything anymore. Instead of crashing and redirecting to home page, this commit makes it so that we now ignore the cookie in that case, so that the user directly has access to the survey to build a new answer. Task-2729738 Forward-Port-Of: odoo/odoo#82041
Before this commit, on Chrome browser, the page url input and the visiblity password input were autocompleted with the user's login and password in the page properties options. After this commit, they are no longer. Regarding the url input page, it seems to be because Chrome considers that the first text input located before a password input in the DOM is a login input. task-2502747 Description of the issue/feature this PR addresses: Current behavior before PR: Desired beha
Original PR description
Before this commit, on Chrome browser, the page url input and the visiblity password input were autocompleted with the user's login and password in the page properties options. After this commit, they are no longer. Regarding the url input page, it seems to be because Chrome considers that the first text input located before a password input in the DOM is a login input. task-2502747 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#84372
Description of the issue/feature this PR addresses: The function `_compute_amount` on `account.tax` returns None if the value of `amount_type` is not a standard Odoo value. During normal use, this will never be the case, and if the value is modified by a custom module the method is overridden in its code to account for that case. During an upgrade, however, custom modules are not available. During the tests, if a field needs to be computed using that function, it will break with `Typ
Original PR description
Description of the issue/feature this PR addresses: The function `_compute_amount` on `account.tax` returns None if the value of `amount_type` is not a standard Odoo value. During normal use, this will never be the case, and if the value is modified by a custom module the method is overridden in its code to account for that case. During an upgrade, however, custom modules are not available. During the tests, if a field needs to be computed using that function, it will break with `TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'` Adding a default return to the function in case the `amount_type` is not recognised will help prevent this. Current behavior before PR: Desired behavior after PR is merged: Behavior should be the same since this is a corner case for upgrades. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#84367
The shadow option needs to create a div on the fly to be able to retrieve the default shadow value. This commit makes sure these divs are also removed when no longer needed. Forward-Port-Of: odoo/odoo#84292 Forward-Port-Of: odoo/odoo#82223
Original PR description
The shadow option needs to create a div on the fly to be able to retrieve the default shadow value. This commit makes sure these divs are also removed when no longer needed. Forward-Port-Of: odoo/odoo#84292 Forward-Port-Of: odoo/odoo#82223
Steps to reproduce the bug: - Go to any Contact > Sales and Purchase tab - Edit > Change the barcode, and click Save - Then click Edit, and try to erase (empty) the barcode > save Problem: A validation error is triggered, the constraint will check if other partners do not have the same barcode but as it is empty there will be several other partners Solution: When the barcode is empty, no need to check if other partners have the same opw-2753291 -- I confirm I have signed
Original PR description
Steps to reproduce the bug: - Go to any Contact > Sales and Purchase tab - Edit > Change the barcode, and click Save - Then click Edit, and try to erase (empty) the barcode > save Problem: A validation error is triggered, the constraint will check if other partners do not have the same barcode but as it is empty there will be several other partners Solution: When the barcode is empty, no need to check if other partners have the same opw-2753291 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#84411
Check https://github.com/odoo/odoo/pull/78269 Forward-Port-Of: odoo/enterprise#23490 Forward-Port-Of: odoo/enterprise#21662
Original PR description
Check https://github.com/odoo/odoo/pull/78269 Forward-Port-Of: odoo/enterprise#23490 Forward-Port-Of: odoo/enterprise#21662
Before this commit, if the Enter key is pressed without having selected an application, a traceback is displayed. Forward-Port-Of: odoo/enterprise#24242
Original PR description
Before this commit, if the Enter key is pressed without having selected an application, a traceback is displayed. Forward-Port-Of: odoo/enterprise#24242
- Grid 61, which was unused since a few months, is now removed - A reserved space is removed from the BOE. It used to serve for a field that got removed months ago. - There are now more reserved spaces at the end of the file. Once this fix is deployed, updating the module will hide grid 61 in the report (also for reports of previous periods; as it's a limitation of our engine). The BOE will however still support grid 61 in periods prior to 2022-01-01, in case some export needs to be re-gene
Original PR description
- Grid 61, which was unused since a few months, is now removed - A reserved space is removed from the BOE. It used to serve for a field that got removed months ago. - There are now more reserved spaces at the end of the file. Once this fix is deployed, updating the module will hide grid 61 in the report (also for reports of previous periods; as it's a limitation of our engine). The BOE will however still support grid 61 in periods prior to 2022-01-01, in case some export needs to be re-generated. Source: https://sede.agenciatributaria.gob.es/Sede/ayuda/disenos-registro/modelos-300-399.html Forward-Port-Of: odoo/enterprise#24148 Forward-Port-Of: odoo/enterprise#23879
A modification made by Amazon on October 1st restricts the allowed values for the carrier name. Since it now expects it in a formatted state, this commit will allow Odoo to send the delivery type of the carrier rather than its name, which can be customized by the user. opw-2665099 See also: - https://github.com/odoo/odoo/pull/82772 Forward-Port-Of: odoo/enterprise#24065 Forward-Port-Of: odoo/enterprise#23504
Original PR description
A modification made by Amazon on October 1st restricts the allowed values for the carrier name. Since it now expects it in a formatted state, this commit will allow Odoo to send the delivery type of the carrier rather than its name, which can be customized by the user. opw-2665099 See also: - https://github.com/odoo/odoo/pull/82772 Forward-Port-Of: odoo/enterprise#24065 Forward-Port-Of: odoo/enterprise#23504