Thursday, May 19, 2022
43 changes · master
Enhancements to existing features
The mail app now manages channel member lists through a dedicated internal view model. This helps make chat and discussion interfaces easier to maintain and more reliable, with limited direct change for end users.
The Archive option is moved out of prominent form buttons and into the Actions menu, where archived records can be restored with a clearer Restore action. This reduces accidental archiving during onboarding and helps users understand where to recover records, with related updates so list and kanban views refresh correctly after archive-related actions.
Original PR description
In an onborading, poeple click on "Archive" -> they don't find the task anymore. Remove "Active" button from the stat bar and move it in the "Action" (only in form). The label is "Archive". When it is Archived, the button become "Restore" 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 update adds a shared way for automated tests to simulate different screen sizes consistently across mail and web components. It reduces the risk of inconsistent test conditions, helping teams validate mobile and desktop behavior more reliably without affecting end users directly.
Original PR description
Until now, when we add to patch the ui size, we would have patched one of the following:
- config.device.{isMobile,size_class}
- env.isSmall / env.services.ui.{isSmall/size}
- browser.innerWidth / window.innerWidth
The issue is that patching one does not affect the others resulting in an incoherent state.
In order to ease ui size patching, the `patchUiSize` method has been introduced. This method
take either a size or a width as parameter (eg. SIZES.SM, 1920) and affect all the properties above.
task-2582313
enterprise: https://github.com/odoo/enterprise/pull/27428Learners can now manually mark eligible course lessons as done or not done, giving them more control over their progress tracking. Quizzes and certifications remain completion-based to preserve assessment integrity, while course pages and fullscreen views behave more consistently.
Original PR description
Purpose ======= Allow the users to themselves mark their course as "done" or "not done" Specifications ============== When the course is a "Training" in fullscreen or in non-fullscreen, or when the course is a "Documentation" in fullscreen mode, allow the user to click on the "done" button in the sidebar. When the course is a "Documentation" in non-fullscreen mode, add a button "Mark Not Done" when the slide is done. The quiz and the certification cannot be marked as done manually, the user has to complete the questions for that. A certification cannot be marked as "Not Done" (but a quiz can). Technical ========= As the fullscreen view and the non-fullscreen view will share a lot of code, make a common class to avoid redundancy. Task-2604792
The mailing list Kanban view has been redesigned to make ungrouped lists easier to scan in a full-width, list-style layout. Users also get faster actions to import contacts or send mailings directly from the list, while grouped views keep the familiar card layout.
Original PR description
Purpose ======= Replace the current "card style" Kanban design by a "list style" design. When the Kanban view is grouped, we use the old "card design". Task-2737782
The online shop now uses smaller product images in grid layouts when they are visually sufficient. This helps pages load faster and reduces bandwidth use without noticeably affecting image quality.
Original PR description
This should improve the page loading time. Now, setting 2 columns per line will use the 1024px picture 3 or more : 512px If the picture is set bigger (2x1 or more, the 1024px version will be used) task-id : 2823110 related : https://github.com/odoo/odoo/pull/86294 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves everyday usability in the Project app with clearer examples, better defaults, cleaner task views, and a new way to find tasks due today. It helps teams create project records faster, keep task accounting aligned, and navigate project information more easily.
Original PR description
Purpose of this commit to improve generic usage of project app. So, in this commit done following changes: -change the placeholder of the name to 'e.g. Monthly review' in project_update_view_form…
Purpose of this commit to improve generic usage of project app. So, in this commit done following changes: -change the placeholder of the name to 'e.g. Monthly review' in project_update_view_form -set the 'analytic account' of the project on the tasks by default -change the placeholder to 'e.g. Product Launch' in project_milestone_view_form -the 'cabinets' milestone should be linked to a milestone service, not a manual one so change data to milestone in demo data -rename the 'rating' stat button into 'last rating' in view_task_form2 -set another employee than Mitchell for the 'customer care (prepaid hours)' SOL field in sale_service_demo_data -display a separator on the right of the stat button so remove unwanted properties in project_rightpanel.scss -add the 'name' field to the 'fields to export' when 'i want to update data' is set to true -remove the 'Getting Things Done (GTD)' example from kanban examples wizard -add a 'tasks due today' filter that should return tasks whose deadline falls on today's date in view_task_search_form task-2809188
The population command now supports profiling and safer rollback options, helping teams inspect performance and repeat data generation without record conflicts. This mainly benefits internal testing and development workflows, especially for smaller datasets where profiling overhead is acceptable.
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A new automated test checks that project cost balances update correctly when timesheets are recorded. This helps ensure project profitability and cost reporting stay reliable when employee time is logged.
Original PR description
This commit adds a unit test to check if the value of
`analytic_account_balance` field in a project is the one expected when a
timesheet is added into this project.
The analytic account balance value expected should be equal to
`timesheet_cost * timesheet_unit_amount * -1`, where:
- `timesheet_cost`: the employee cost or the cost set on an employee mapping
defined in the project.
- `timesheet_unit_amount`: the number of hours/days set on the timesheet.
task-2783686This update makes several Odoo forms easier to understand and edit by adding helpful placeholder text and improving longer text fields. Users working with surveys, activity types, mass emails, and action help text should have a smoother editing experience with less guesswork.
Original PR description
Improves UX by adding placeholders to clarify the purpose of some inputs and changing some field layout to ease the edition (with the use of multi-lined editor). Details: Some placeholders have been added: - description field of survey.question - default_note field of mail.activity.type - summary of mail_activity_type_view_form Some field layouts have been turned into multi-lined editor: - default_note field of mail.activity.type - write a message in mass mail mode (email_compose_message_wizard_form) Added border for field help of edit action (class oe-bordered-editor) Task-2766291 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 update streamlines how some core system messages are translated, avoiding unnecessary translation work when only one message is shown. It also improves reliability by falling back to English text if a translation is incomplete, helping prevent confusing or broken error messages.
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payroll reporting is improved with cleaner country-specific measures, more grouping options, and support for custom measures. Belgian payroll gains new employer tax redistribution rules, CO2 payroll reporting additions, and better collaboration tracking on payslip batches.
This update improves how automated tests simulate different screen sizes in the enterprise mail module. It helps keep test conditions consistent across mobile and desktop scenarios, reducing the risk of interface issues going unnoticed.
Original PR description
Until now, when we add to patch the ui size, we would have patched one of the following:
- config.device.{isMobile,size_class}
- env.isSmall / env.services.ui.{isSmall/size}
- browser.innerWidth / window.innerWidth
The issue is that patching one does not affect the others resulting in an incoherent state.
In order to ease ui size patching, the `patchUiSize` method has been introduced. This method
take either a size or a width as parameter (eg. SIZES.SM, 1920) and affect all the properties above.
task-2582313
community: https://github.com/odoo/odoo/pull/91540Appointment setup screens now show helpful placeholder text for introduction and confirmation message fields. This makes it easier for staff to understand what content to enter, reducing confusion during configuration.
Original PR description
Add placeholders to clarify the purpose of some inputs Details: Placeholders have been added in appointment_type_view_form for fields: - message_intro - message_confirmation Task-2766291
This update adds and improves automated checks for Field Service, sales, stock, reporting, worksheets, and timesheet timer behavior. It helps reduce the risk of regressions in common service workflows such as creating field service projects, preparing service reports, pricing materials, managing stock deliveries, and rounding timer entries.
Original PR description
Before these changes: - Many cases were not tested After these changes: ** industry_fsm: - Testing task_timer_min_duration_and_rounding - Testing auto_create_fsm_task when new company created ** industry_fsm_report: - Testing worksheet_without_studio_installed - Testing project_worksheet_template_propagation ** industry_fsm_sale: - Improve fsm_flow - Improve fsm_sale_pricelist - Add analytic_account_balance ** industry_fsm_sale_report: - Testing service_worksheet_template_propagation ** industry_fsm_stock: - Testing modify_quantity_for_tracked_product_by_lot_and_sn ** timesheet_grid: - Moving test_fsm_task_timer_min_duration_and_rounding to timesheet_grid Related PRs: community: https://github.com/odoo/odoo/pull/87405 Task-2783686
Odoo Studio now handles removed view elements more safely by hiding standard elements instead of deleting them outright. This makes it easier to preserve core view structure and avoid difficult-to-reverse customizations, while still allowing Studio-created elements to be removed.
Original PR description
[IMP] web_studio: hide non-studio elements instead of removing them When removing elements from views through Studio, the behavior was to create an xpath node with the attribute `position` set to `replace`. Removing elements this way can be problematic for non-custom, basic elements and the removed elements can't be reset easily, only by resetting the whole view. After this commit, the elements will be differentiated: - if they were previously created through Studio, they can be removed - if they are non-studio elements, they should be hidden
New spreadsheet pivot and list tables now include useful context in their names, such as the first grouping or sorting field. This helps users distinguish similar tables more easily and reduces confusion when several reports are inserted from the same menu.
Original PR description
### Description When inserting a new pivot/list in a spreadsheet, the name of the new table is only build according to the menu the table in included from, leading us to multiple list/pivot with the same name. The idea of this commit is to add some more information in the name, leading us to this kind of structure : 1. PIVOT VIEW: `<action name>` -> `<action name> by <first grouping>`, where 'first grouping' is the field label of the first group, giving priority to column over row 2. LIST VIEW: `<action name>` -> `<action name by <first sorting>`, where 'first sorting' is the field label of the first sorting ### Related Task - task-2832690
Resolved issues and error corrections
Technical hint text in settings pages now follows the same search filtering behavior as other settings content. This prevents irrelevant guidance from staying visible when users search settings, making results clearer and less confusing.
Original PR description
In the settings view, we need to display the technical tip below the setting header (h2 tag). For example, we display such tip under the 'Developer Accounts' header in social media settings. However,…
In the settings view, we need to display the technical tip below the setting header (h2 tag). For example, we display such tip under the 'Developer Accounts' header in social media settings. However, when we search something in the settings, this tip is not hidden. It happens because the hiding and showing parts of the settings page are managed with js using some special classes or tags (like h2 tag, `.o_setting_box` class etc). This commit fixes the issue by introducing a new class `.o_setting_tip` specific for such technical tips, and with help of that we now hide or show the tips based on the user search. Note: We could have used `.o_setting_box` without any side-effect, but rules linked to this class can be changed in the future and can mess with layout of the technical tips. enterprise PR - https://github.com/odoo/enterprise/pull/25907 task-2810617 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
The privacy feature has been renamed to Privacy Lookup to avoid conflicts with an existing community application using the same name. This reduces deployment confusion and compatibility issues for organizations using both Odoo and OCA modules.
Original PR description
Purpose ======= The newly introduced privacy module at https://github.com/odoo/odoo/pull/89312 is actually conflicting with an already existing OCA application. See: https://github.com/OCA/data-protection/tree/14.0/privacy As the application is only present in master and as I like the OCA (especially Pedro), let's rename the application to avoid deployment issues on their side. TaskID: 2857904
Miscellaneous changes
The boolean_toggle should only be disabled when there is a readonly modifier, not when the view is in readonly mode. **Cause of the issue** The input was disabled but the `_onClick` was registered on the widget root node. **Solution** - Listen for clicks on the input element - Override the render method to set the disabled prop according to the readonly modifier. opw-2739468 Forward-Port-Of: odoo/odoo#91501 Forward-Port-Of: odoo/odoo#86542
Original PR description
The boolean_toggle should only be disabled when there is a readonly
modifier, not when the view is in readonly mode.
**Cause of the issue**
The input was disabled but the `_onClick` was registered on the
widget root node.
**Solution**
- Listen for clicks on the input element
- Override the render method to set the disabled prop according to the
readonly modifier.
opw-2739468
Forward-Port-Of: odoo/odoo#91501
Forward-Port-Of: odoo/odoo#86542This update adjusts terminology in the accounting dashboard to use clearer US English wording. It helps users better understand labels or messages without changing accounting features or workflows.
Original PR description
en_US police 👮
A technical hint in Social app settings could appear in the wrong place when users searched settings. This fix ensures the hint is hidden when appropriate and only appears in its intended location, reducing confusion for administrators.
Original PR description
Before this commit, a technical tip of social was displayed any where as 'o_hidden' class is not applied as the tool tip is defined in h3 tag. As 'o_hidden' class is not added in h3 element. With this commit we add 'o_setting_box' class in h3 element so that 'o_hidden' class is added whenever it is required. As we are adding 'o_hidden' class on 'o_setting_box' in base. Now, we will not get the technical tip anywhere else then it's original place. Community PR: https://github.com/odoo/odoo/pull/88117 TaskId-2810617
This is an attempt at fixing a runbot "race" condition. A first attempt was done in [1] but the selector introduced to make sure the page was reloaded after the assets were changed was wrong. This commit fixes that selector. During the investigation of the problem, it was also discovered that the SCSS change could take quite a long time on a busy server becasue it triggers the SCSS compilation each time. To reproduce that problem locally, run the `stress` command while executing th
Original PR description
This is an attempt at fixing a runbot "race" condition. A first attempt was done in [1] but the selector introduced to make sure the page was reloaded after the assets were changed was wrong. This…
This is an attempt at fixing a runbot "race" condition. A first attempt was done in [1] but the selector introduced to make sure the page was reloaded after the assets were changed was wrong. This commit fixes that selector. During the investigation of the problem, it was also discovered that the SCSS change could take quite a long time on a busy server becasue it triggers the SCSS compilation each time. To reproduce that problem locally, run the `stress` command while executing the `test_html_editor_scss` test. E.g.: ```sh $ stress --cpu 32 --timeout 120 ``` The error that shows up in that case is misleading because it makes it look like the confirmation popup was not clicked on. What is actually happening is the following: - the Reset button is clicked on => the confirmation popup is shown - the confirmation is clicked => the popup is closed and the RPC call is made - the RPC does not respond within the tour step's timeout => the last step is not shown as succesful and the screenshot shows the non-reset state since the server response did not arrive yet To be safe on busy servers this commit also increases the timeouts related to steps that follow updates of SCSS files so that they can be recompiled on time. [1]: https://github.com/odoo/odoo/commit/b35f127c86c1d271a76dae7186a96190e8558c73 runbot-3744 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#90771
If applied, this commit will fix the following bug by fixing the url used to ping the server Steps to reproduce: 1- open apps with debug mode 2- click on updates 3- the server is read as if it is offline Bug: in ecfe85db84fb5649aaeb48ba3b221386e61a57bc all links are changed static/src/(img|fonts) => static/(img|fonts) however in this specific case the server is remote (https://apps.odoo.com) and it still needs /src/ Fix: add /src to the url opw-2791531 Forward-Port-Of:
Original PR description
If applied, this commit will fix the following bug by fixing the url used to ping the server Steps to reproduce: 1- open apps with debug mode 2- click on updates 3- the server is read as if it is offline Bug: in ecfe85db84fb5649aaeb48ba3b221386e61a57bc all links are changed static/src/(img|fonts) => static/(img|fonts) however in this specific case the server is remote (https://apps.odoo.com) and it still needs /src/ Fix: add /src to the url opw-2791531 Forward-Port-Of: odoo/odoo#89982
How to reproduce: Have 2 different tabs open on the same draft invoice Tab 1: add a new invoice line Tab 2: change the partner Tab 1: save Tab 2: save Before the fix: The new invoice line from tab 1 has the partner from before the change, but the other lines have been updated to the new partner. Expected: All invoice lines have the same partner as the invoice itself This use case can be reproduced like this manually, but it can happen easily even on one tab because the OCR acts
Original PR description
How to reproduce: Have 2 different tabs open on the same draft invoice Tab 1: add a new invoice line Tab 2: change the partner Tab 1: save Tab 2: save Before the fix: The new invoice line from tab 1 has the partner from before the change, but the other lines have been updated to the new partner. Expected: All invoice lines have the same partner as the invoice itself This use case can be reproduced like this manually, but it can happen easily even on one tab because the OCR acts like the second tab if users start to edit the invoice before it is scanned. Note that in a perfect world, a warning would be raised to prevent any loss/mischief due to concurrent editions of the same record but that's beyond the scope of a bugfix made on a stable version. opw-2777390 opw-2762347 opw-2741859 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#91638
### Current behavior Cookie bar is slightly shifted during mobile browsing, which complicates the acceptation and prevents navigation through the site (which is not the case during a "desktop" browsing) ### Steps - Install Website - Enable cookie bar in the Settings - Go on the Website with a mobile screen width OPW-2784233 Forward-Port-Of: odoo/odoo#88905
Original PR description
### Current behavior Cookie bar is slightly shifted during mobile browsing, which complicates the acceptation and prevents navigation through the site (which is not the case during a "desktop" browsing) ### Steps - Install Website - Enable cookie bar in the Settings - Go on the Website with a mobile screen width OPW-2784233 Forward-Port-Of: odoo/odoo#88905
Before this commit, iframes DOM mutations were not taken into account to update the tour manager. So in the context of mass_mailing, displaying the web editor in an iframe, the tours were updated at the right moment by chance (no mutations for 750ms in the global document and in the iframe document). This commit adds an o_iframe class, used to define an iframe that will render a part of Odoo. An observer is added in the tour service to monitor the addition of such iframe, and sets an ob
Original PR description
Before this commit, iframes DOM mutations were not taken into account to update the tour manager. So in the context of mass_mailing, displaying the web editor in an iframe, the tours were updated at…
Before this commit, iframes DOM mutations were not taken into account to update the tour manager. So in the context of mass_mailing, displaying the web editor in an iframe, the tours were updated at the right moment by chance (no mutations for 750ms in the global document and in the iframe document). This commit adds an o_iframe class, used to define an iframe that will render a part of Odoo. An observer is added in the tour service to monitor the addition of such iframe, and sets an observer on that iframe to correctly update the tour manager, counting the iframe DOM mutations for the 750ms delay. In addition to this observer, the iframe's HTML content is added to the final document HTML log when a tour crashes (directly between the <iframe></iframe> for convenience, copy/pasting it in a browser just ignores what's in between). Also, when the tour_service is initialized in an o_iframe, it will not run the tours. This fix targets the saas-15.3 as it is needed to avoid a race condition introduced with [1] (introducing a tour which relies on DOM updates inside the mass mailing iframe). This could be backported if the need ever rise (it should really have been the case since [2]). [1]: https://github.com/odoo/odoo/commit/52d32e26c34bef10823582ef5c1f840492b73d7a [2]: https://github.com/odoo/odoo/commit/971629b9fe40911c3a9765c9fb746ea1c55d3560 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#89578
This fix will try to write a new amount value on the tax when an invoice is created from POS, that will raise a user error preventing the creation of the order. This reverts commit e9262bfc8c775953ebe150f36ce0ab8dcb04d4bd. OPW-2855694 Forward-Port-Of: odoo/odoo#91684 Forward-Port-Of: odoo/odoo#91626
Original PR description
This fix will try to write a new amount value on the tax when an invoice is created from POS, that will raise a user error preventing the creation of the order. This reverts commit e9262bfc8c775953ebe150f36ce0ab8dcb04d4bd. OPW-2855694 Forward-Port-Of: odoo/odoo#91684 Forward-Port-Of: odoo/odoo#91626
Revert the possibility to install languages from the form views of opportunity/lead and partner task-2839020 Forward-Port-Of: odoo/odoo#90730
Original PR description
Revert the possibility to install languages from the form views of opportunity/lead and partner task-2839020 Forward-Port-Of: odoo/odoo#90730
Steps to reproduce: - Have two companies set up - In settings, check for company 2 the Files Centralization - For a Product, upload a document Issue: The document will not appear in Documents. It will only appear if the option is checked for company 1 Cause: The company_id is not fetched correctly throughout the process. There is a similar solution for the specific `documents` upload route: https://github.com/odoo/enterprise/blob/13.0/documents/controllers/main.py#L147-L149 Solu
Original PR description
Steps to reproduce: - Have two companies set up - In settings, check for company 2 the Files Centralization - For a Product, upload a document Issue: The document will not appear in Documents. It will only appear if the option is checked for company 1 Cause: The company_id is not fetched correctly throughout the process. There is a similar solution for the specific `documents` upload route: https://github.com/odoo/enterprise/blob/13.0/documents/controllers/main.py#L147-L149 Solution: Get the id directly from the cookies opw-2774365 Forward-Port-Of: odoo/odoo#91524 Forward-Port-Of: odoo/odoo#88745
Prior to this commit an user could try to add a product to cart that does not exist anymore because it was deleted while the user /shop page wasn't refreshed. This commit avoids this (rare) use case to happen. TaskId-2835736 Forward-Port-Of: odoo/odoo#91726 Forward-Port-Of: odoo/odoo#91351
Original PR description
Prior to this commit an user could try to add a product to cart that does not exist anymore because it was deleted while the user /shop page wasn't refreshed. This commit avoids this (rare) use case to happen. TaskId-2835736 Forward-Port-Of: odoo/odoo#91726 Forward-Port-Of: odoo/odoo#91351
Task ID: 2717840 Currently: - Generic_coa has the country_id US, which is not valid for non-supported localizations. This creates a bug as the country on taxes and account_fiscal_country_id becomes different. - Users who only have Invoicing installed can't change the fiscal country setting as it's only available in Accounting. Desired: - Set account_fiscal_country_id the same as country_id - Remove base.us from l10n_generic_coa - Adjust the error message to make the issue clearer for
Original PR description
Task ID: 2717840 Currently: - Generic_coa has the country_id US, which is not valid for non-supported localizations. This creates a bug as the country on taxes and account_fiscal_country_id becomes different. - Users who only have Invoicing installed can't change the fiscal country setting as it's only available in Accounting. Desired: - Set account_fiscal_country_id the same as country_id - Remove base.us from l10n_generic_coa - Adjust the error message to make the issue clearer for users - Allow changing fiscal country in Invoicing -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#91354
When creating a quiz, the answers were not displayed in the many2many_tags and void tags were displayed. This commit ensures that the answers is always displayed even if the record is not yet created. task-2849896 Forward-Port-Of: odoo/odoo#90995
Original PR description
When creating a quiz, the answers were not displayed in the many2many_tags and void tags were displayed. This commit ensures that the answers is always displayed even if the record is not yet created. task-2849896 Forward-Port-Of: odoo/odoo#90995
When moving some products between two warehouses thanks to an internal transfer, the forecasted inventory becomes incorrect To reproduce the issue: 1. In Settings, enable "Multi-Warehouses" 2. Let WH01 be the existing warehouse. Create a second one WH02 3. Create a storable product P 4. Update the quantity of P: - 3 in WH01/Stock 5. Create a planned and internal transfer T: - Source: WH01/Stock - Destination: WH02/Stock - Ignore the warning - Operations:
Original PR description
When moving some products between two warehouses thanks to an internal transfer, the forecasted inventory becomes incorrect To reproduce the issue: 1. In Settings, enable "Multi-Warehouses" 2. Let…
When moving some products between two warehouses thanks to an internal
transfer, the forecasted inventory becomes incorrect
To reproduce the issue:
1. In Settings, enable "Multi-Warehouses"
2. Let WH01 be the existing warehouse. Create a second one WH02
3. Create a storable product P
4. Update the quantity of P:
- 3 in WH01/Stock
5. Create a planned and internal transfer T:
- Source: WH01/Stock
- Destination: WH02/Stock
- Ignore the warning
- Operations:
- 1 x P
6. Mark T as todo
7. Open the Forecasted Inventory:
- Filters:
- Forecasted Stock
- Product: P
- Group By: Warehouse
Error: The report is incorrect, it says there are 3 P in WH01 and 0 in
WH02 (should be 2 and 1). It becomes worst if T is done (the quantities
in the past become incorrect)
We should be able to move a product between two warehouses thanks to an
internal transfer (so the warning of the step 5 should be removed).
Moreover, the `report.stock.quantity` should consider that use case.
When processing a stock move, the SQL view translates it as an in-move
or out-move for a specific warehouse. For instance, if the SM comes from
a warehouse and goes to a location without any warehouse (e.g., customer
location), the SM is considered as an out-move. But here is the issue:
in case of an inter-warehouse SM, both source and destination have a
defined warehouse.
Therefore, we need to:
- Duplicate the inter-warehouses SM (so we have one in and one out)
- Fake the values (no destination warehouse for the out move, no source
warehouse for the in move)
Also, before duplicating all SM, we filter out some useless SM:
- Draft and cancelled ones
- SM done more than 3 months ago (because the report only works for [-3
months; +3 months])
Considering some tests:
(SM are confirmed. Each test has been repeated 5 times to get an
average)
| | |
|:-------------------------------------:|:--------:|
| 5000 SM, 0% inter-wh, without the fix | ~715 ms |
| 5000 SM, 0% inter-wh, with the fix | ~710 ms |
| Impact | 0.99x |
| | |
| 6666 SM, 0% inter-wh, without the fix | ~911 ms |
| 5000 SM, 33% inter-wh, with the fix | ~999 ms |
| Impact | 1.10x |
| | |
| 7500 SM, 0% inter-wh, without the fix | ~1004 ms |
| 5000 SM, 50% inter-wh, with the fix | ~1097 ms |
| Impact | 1.09x |
The impact is not that significant
OPW-2752017
task-2822157
Forward-Port-Of: odoo/odoo#91480
Forward-Port-Of: odoo/odoo#90362Field `website.visitor::page_ids` was storable initially [1], but then it was refactored [2] and hence the search by "Visited Pages" [3] became broken. Fix it by adding `search=` attribute [1]: https://github.com/odoo/odoo/commit/6bec0e4d29e6b33b74962b2893a7a405667ef58c [2]: https://github.com/odoo/odoo/commit/e33172e83210a5e0044a6fb92e315b84deefc440 [3]: https://github.com/odoo/odoo/blob/c6c7605cdae803aca4f441ef4e622a1b79f17019/addons/website/views/website_visitor_views.xml#L248-L257
Original PR description
Field `website.visitor::page_ids` was storable initially [1], but then it was refactored [2] and hence the search by "Visited Pages" [3] became broken. Fix it by adding `search=` attribute [1]: https://github.com/odoo/odoo/commit/6bec0e4d29e6b33b74962b2893a7a405667ef58c [2]: https://github.com/odoo/odoo/commit/e33172e83210a5e0044a6fb92e315b84deefc440 [3]: https://github.com/odoo/odoo/blob/c6c7605cdae803aca4f441ef4e622a1b79f17019/addons/website/views/website_visitor_views.xml#L248-L257 opw-2622141 Forward-Port-Of: odoo/odoo#91647 Forward-Port-Of: odoo/odoo#76160
Since Chromium 97, folded `<details>` content has non-zero computed width and height which returns false-positive QUnit `assert.isNotVisible()` calls. In a nutshell, this was introduced in https://bugs.chromium.org/p/chromium/issues/detail?id=1185950 when Chromium implemented the ability for "Find in page" to search in folded `<details>`. To do so, the `content-visibility` rule was used instead of `display: none` which, even if functionally similar, has an impact on the values returned
Original PR description
Since Chromium 97, folded `<details>` content has non-zero computed width and height which returns false-positive QUnit `assert.isNotVisible()` calls. In a nutshell, this was introduced in…
Since Chromium 97, folded `<details>` content has non-zero computed width and height which returns false-positive QUnit `assert.isNotVisible()` calls. In a nutshell, this was introduced in https://bugs.chromium.org/p/chromium/issues/detail?id=1185950 when Chromium implemented the ability for "Find in page" to search in folded `<details>`. To do so, the `content-visibility` rule was used instead of `display: none` which, even if functionally similar, has an impact on the values returned by `getBoundingClientRect()` (i.e. used in `assert.isNotVisible()`. A regression report was filled in https://bugs.chromium.org/p/chromium/issues/detail?id=1276028 to highlight this change of behavior. What emerged from this report's discussion is that Chromium has no intent to revert this change and instead put the emphasis on avoiding to use `getBoundingClientRect()` and similar methods for visibility check (even pushing a proposal for a `Element.isVisible()` API; cf. https://github.com/w3c/csswg-drafts/issues/6850). This commit works around this issue by forcing the content to `display: none`, like in the previous Chromium versions. Forward-Port-Of: odoo/odoo#91790 Forward-Port-Of: odoo/odoo#91568
Add move_reverse_cancel=cancel back to context when reconciling moves with reverse moves. Bug introduced in commit https://github.com/odoo/odoo/commit/6481eb720f36f3e81c2ec8371cccdd893a5e8ddf Database : Reproducible in v14, v15 On a Mexican company (with l10n_mx) with multi currencies enabled. - Set rates for USD to be different at invoice and at payment date - Create an invoice at date 1 in USD - Create a payment at date 2 in USD for invoice generating a difference exchange move - Tr
Original PR description
Add move_reverse_cancel=cancel back to context when reconciling moves with reverse moves. Bug introduced in commit https://github.com/odoo/odoo/commit/6481eb720f36f3e81c2ec8371cccdd893a5e8ddf Database : Reproducible in v14, v15 On a Mexican company (with l10n_mx) with multi currencies enabled. - Set rates for USD to be different at invoice and at payment date - Create an invoice at date 1 in USD - Create a payment at date 2 in USD for invoice generating a difference exchange move - Try to reset the payment to draft -The traceback (ZeroDivisionError: float division by zero) will appear. Tickets : 2857549, 2856162, 2855038, 2852663, 2852859, 2857381 Forward-Port-Of: odoo/odoo#91738
Description of the issue/feature this PR addresses: Updates sprintit.fi CLA contributor list -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#90871
Original PR description
Description of the issue/feature this PR addresses: Updates sprintit.fi CLA contributor list -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#90871
The pa index should only be XXXXXXX when the foreign partner is not identified. In this commit we change the condition on the template such that if the pa index is defined, we always utilise it. If the pa index is not defined but the partner is italian, we use '0000000', and when it is not defined and the partner is not italian, we use 'XXXXXXX'. task-id: 2858092 Forward-Port-Of: odoo/odoo#91737
Original PR description
The pa index should only be XXXXXXX when the foreign partner is not identified. In this commit we change the condition on the template such that if the pa index is defined, we always utilise it. If the pa index is not defined but the partner is italian, we use '0000000', and when it is not defined and the partner is not italian, we use 'XXXXXXX'. task-id: 2858092 Forward-Port-Of: odoo/odoo#91737
To reproduce the issue: Create an asset with the prorata option checked and a value of 1000 and 3 depreciations, then modify the asset with the same values (3 depreciations). An additional entry (4/3) is created while it shouldn't. To correct the issue: We need to use the context information that we should ignore the prorata in the board computation. Forward-Port-Of: odoo/enterprise#27426
Original PR description
To reproduce the issue: Create an asset with the prorata option checked and a value of 1000 and 3 depreciations, then modify the asset with the same values (3 depreciations). An additional entry (4/3) is created while it shouldn't. To correct the issue: We need to use the context information that we should ignore the prorata in the board computation. Forward-Port-Of: odoo/enterprise#27426
[This commit] broke the CH_290 report line and also introduced the CH_R_BS line that is unnecessary [This commit]:https://github.com/odoo/enterprise/commit/ceb15650f38774 opw-2823852 Forward-Port-Of: odoo/enterprise#27522 Forward-Port-Of: odoo/enterprise#26969
Original PR description
[This commit] broke the CH_290 report line and also introduced the CH_R_BS line that is unnecessary [This commit]:https://github.com/odoo/enterprise/commit/ceb15650f38774 opw-2823852 Forward-Port-Of: odoo/enterprise#27522 Forward-Port-Of: odoo/enterprise#26969
Improves the matching algorithm for the supplier selection. The previous version was making a lot of mistakes due to the matching heuristic being naive. This version is more careful with its prediction, i.e. it only predicts when there is a low chance of error. Forward-Port-Of: odoo/enterprise#27441 Forward-Port-Of: odoo/enterprise#27375
Original PR description
Improves the matching algorithm for the supplier selection. The previous version was making a lot of mistakes due to the matching heuristic being naive. This version is more careful with its prediction, i.e. it only predicts when there is a low chance of error. Forward-Port-Of: odoo/enterprise#27441 Forward-Port-Of: odoo/enterprise#27375
We must check that no value has been manually entered by the user before writing the values found by the OCR. Forward-Port-Of: odoo/enterprise#27442 Forward-Port-Of: odoo/enterprise#26910
Original PR description
We must check that no value has been manually entered by the user before writing the values found by the OCR. Forward-Port-Of: odoo/enterprise#27442 Forward-Port-Of: odoo/enterprise#26910