Daily updates from Odoo
Thursday, July 11, 2024
16 changes
4 changes
Resolved issues and error corrections
Fixes a broken guided tour in Website Slides so users can complete the walkthrough as expected. The update corrects timing and button-targeting issues caused by earlier library and design changes.
Original PR description
**Issue** From v17.2, the website_slides tour is not working because of some changes in the tour library. Commit from where I think the bug is coming https://github.com/odoo/odoo/commit/b334055c82c4350b4122e620ae76179a9fc4eaa2 and later due to the website design change another step was also failing and that should be coming this commit https://github.com/odoo/odoo/commit/80e3f53550b7ed74ac18bb09ea542c9e77c9a61d **Technical** The "Add to content" is loading before our frame is ready due to this the position of the pointer was wrong. Due to the design change tour was not able to point the publish btn **After this PR** Now the tour is working properly. Task-3960962
This update refreshes the spreadsheet engine with fixes that make charts easier to read, improve formula matching behavior, and reduce unnecessary recalculations. Users should see more reliable spreadsheet results and smoother performance, especially in larger sheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9f2068549 [REL] 17.2.16 Task: 0 https://github.com/odoo/o-spreadsheet/commit/86adb37bf [FIX] charts: truncate labels…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9f2068549 [REL] 17.2.16 Task: 0 https://github.com/odoo/o-spreadsheet/commit/86adb37bf [FIX] charts: truncate labels by default Task: 3958962 https://github.com/odoo/o-spreadsheet/commit/de8b6b1a3 [PERF] evaluation: don't evaluate needlessly Task: 4036899 https://github.com/odoo/o-spreadsheet/commit/565dbdc9d [PERF] evaluation: invalidate spreading in batch Task: 4036899 https://github.com/odoo/o-spreadsheet/commit/d164e4215 [IMP] demo: add large demo data set for array formulas Task: 4036899 https://github.com/odoo/o-spreadsheet/commit/dd9f5a386 [FIX] functions: "*" doesn't match empty string Task: 4023057 https://github.com/odoo/o-spreadsheet/commit/62f4af81a [FIX] functions: match empty cells Task: 4023057 https://github.com/odoo/o-spreadsheet/commit/81381a425 [REV] chart: avoid useless chart updates Task: 4029016 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: 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 a display issue where popups or overlays inside embedded livechat could fail to appear when they were already queued before the chat area finished loading. Visitors should now see the right livechat interface elements consistently without duplicate overlays elsewhere on the page.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/154349 PR above allowed to define shadow DOM-specific overlays, which is desirable for apps that need to work in a shadow DOM like livechat from…
Follow-up of https://github.com/odoo/odoo/pull/154349 PR above allowed to define shadow DOM-specific overlays, which is desirable for apps that need to work in a shadow DOM like livechat from visitor's perspective. The reason for shadow DOM is to use exactly same style and behaviour of livechat like in Discuss as internal users. The shadow DOM has to sustain its good working by itself, so it also needs to deploy some required main components like overlay container. In website, there's also an overlay container, and since they share the same stateful service (overlay_service), we do not want to display the overlay twice. So PR above solved the issue by allowing to make overlay with a provided `rootId`, which when set it contains the `id` attribute of the root node of the overlay that has to manage the overlay. This allows to clearly determine which overlay container is responsible to display the appropriate overlay. Code above was however buggy: it relies on `isVisible(overlay)`, whose computation requires `rootRef.el`. Refs' el are not determined on the 1st rendering of the overlay service. This is not a problem when the overlay container is 1st mounted without any overlay, but if it's being registered with some overlays, mounting the overlay container afterwards results in the non-showing of the overlay. The `rootRef` is important to find out the "global" root node id, i.e. the shadow DOM root id. This commit fixes the issue by rendering again overlay container after mount when there are some pre-registered overlays.
Users who cannot edit projects or lunch products can once again mark them as favorites. This restores a convenient personalization option that was unintentionally blocked by a recent access-rights change.
Original PR description
## [FIX] project: let project user to set a project as favorite Before this commit, since the project user cannot edit a project and a recent fix (https://github.com/odoo/odoo/pull/168464) ensures…
## [FIX] project: let project user to set a project as favorite Before this commit, since the project user cannot edit a project and a recent fix (https://github.com/odoo/odoo/pull/168464) ensures the boolean_favorite widget is readonly is the field is readonly or if the record is readonly then the project user can no longer mark a project in favorite. This commit overrides the standard widget `boolean_favorite` for project to make sure the widget is always editable if the field is not in readonly. task-4041969 ## [FIX] lunch: allow employee to save as favorite a product in lunch Before this commit, the current user could have no access to lunch app to add/edit product, etc. Since the user cannot edit `lunch.product` model, he can no longer save as favorite a product since a recent bug fix (https://github.com/odoo/odoo/pull/168464) to ensure the button is in readonly when the field or the record is in readonly. This commit makes sure the user can always save as favorite even if the record is readonly for the user since the user just has to choose what he would like to eat during lunch break and so he just needs to select and save as favorite. task-4041969
3 changes
Resolved issues and error corrections
The Work Orders list in Manufacturing now opens normally again. A leftover setting that pointed to a removed interface component was removed, preventing a crash when users access work orders.
Original PR description
**To reproduce:** Open manufacturing -> Operations -> Work Orders **Root cause:** Since the introduction of the Shop Floor in [1], a JS class was deleted from the workorders list view, but we forgot to remove the attribute on the view itself. Since the changes in [2], this will now result in a hard crash when trying to load the view (as there no longer is a null check). This commit fixes this by removing the JS class attribute from the WO list view. [1] https://github.com/odoo/enterprise/pull/43610 [2] https://github.com/odoo/odoo/pull/171073
Moving a task in the Gantt view now preserves existing many-to-many assignments when the new target is already among them. This prevents unintended removal of related values, while still replacing assignments when the task is moved to a genuinely different value.
Original PR description
Before this commit: Consider a many2many field value = [A, B, C] From the gantt view: - move the pill to value A => value = [A]. B and C are removed. After this commit: - move the pill to value A => value still [A, B, C] as A is part of it - move the pull to value D => value = [D]. A, B and C removed. task-3852999
This update keeps several country-specific localization features working reliably on Ubuntu 24.04 by replacing deprecated software library usage. It helps avoid failures in electronic invoicing, tax reports, certificate handling, and spreadsheet exports as underlying system packages evolve.
Original PR description
As the DEFAULT_CIPHERS hardcoded list of was removed in recent versions of urllib3, let's use the system default one instead.
9 changes
Resolved issues and error corrections
This fix corrects the Quick Create feature in the Calendar Studio editor, which was incorrectly disabled and couldn't be toggled. The issue was caused by reading the wrong property name and not properly saving the disabled state. Users can now correctly enable and disable Quick Create functionality when customizing calendar views.
Original PR description
Steps to reproduce ================== - Install web_studio,calendar - Go to calendar - Open studio => In the sidebar, Quick Create is disabled but should be enabled Toggling it does nothing Cause of the issue ================== The value was incorrectly read from `archInfo.hasQuickCreate` Solution ======== `hasQuickCreate` -> `quickCreate` This shows a second issue: Now that it's enabled, we can't disable it. This is because we remove the attribute instead of setting it to false If we don't pass the attribute, it will keep it's default value (true) https://github.com/odoo/odoo/blob/2afce223268c4ee1ac3c98a6108b1390be82716b/addons/web/static/src/views/calendar/calendar_arch_parser.js#L34 opw-4023026
This fix resolves an issue where decimal quantities were being incorrectly rounded to whole numbers when adjusting inventory in the barcode app for products with package contents. The system now properly preserves decimal precision based on the configured decimal settings, ensuring accurate inventory adjustments for fractional quantities.
Original PR description
## Issue: - When adjusting inventory for a product with packages from the barcode app, quantities that are not whole numbers will be rounded to the nearest whole number. ## Steps To Reproduce: -…
## Issue: - When adjusting inventory for a product with packages from the barcode app, quantities that are not whole numbers will be rounded to the nearest whole number. ## Steps To Reproduce: - Create a product and include two other products in its packaging, specifying a non-whole number for the contained quantity. - In the barcode app, adjust the inventory by adding the created product and then save the changes. - Click on the small pen icon to modify the product's details. - Observe that when adding the quantities with decimal values, they get rounded up to the nearest whole number. ## Solution: - In the `_increment` function, when the initial `value` is not a decimal (it does not contain a '.'), the fraction variable is not set, and the rounding defaults to 0. It's important to note that this issue does not occur when the `value` is a decimal, as the split function operates correctly. - To resolve this issue, instead of relying on the number of digits after the '.' in the `value`, we set the precision based on what is defined in the 'decimal.precision' model. This approach not only addresses the current issue but also resolves the underlying problem initially discussed in this PR https://github.com/odoo/enterprise/pull/53378 opw-3896929 Forward-Port-Of: odoo/enterprise#65619 Forward-Port-Of: odoo/enterprise#62505
This fix resolves an issue where clicking the general ledger action button didn't properly expand parent account lines when the hierarchy view was enabled. Previously, the action would open but leave parent accounts collapsed, making it difficult for users to see the full account structure they needed. Now the parent lines automatically unfold when the action is triggered, making the feature work as intended.
Original PR description
Before this commit, when clicking on the action with the hierarchy enabled, the parent line were not unfolded which cause the purpose of the action to be useless. task-3839845
This fix resolves an intermittent error that occurred in the French accounting dashboard when the tax journal was temporarily removed during nightly tests. The issue caused the system to crash with a key error. This update ensures the dashboard remains stable and functional even when journal data changes unexpectedly.
Original PR description
If you run the nightly builds of TestAccountJournalDashboard, sometimes the tax journal is withdrew from the dashboard -> key error initial pr: https://github.com/odoo/enterprise/pull/66346 opw-4004375
This fix addresses an issue where bank transactions without identifiers were being incorrectly filtered during import. Previously, when providers returned transactions without IDs, only the first transaction would import while others with empty identifiers were skipped. The system now properly handles these edge cases by ignoring transactions with empty identifiers in the filtering logic.
Original PR description
The aim of this commit is fixing the filtering of transactions when transactions have an empty identifier. Even if it's shouldn't be the case, it happens that providers return transactions without an identifier. In this case, it will always importe the first transaction and not the others as they have a similar id (an empty string). Now, we ignore in the filter these transactions. opw-4014171
This fix corrects how percentage-based reconciliation models distribute amounts across multiple lines. Previously, the system was incorrectly calculating percentages based on remaining balances after each line, resulting in incorrect distributions. Now percentages are correctly applied to the original statement line amount, ensuring accurate financial reconciliation.
Original PR description
The current code is taking the residual amount instead of the statement line amount. When doing a reco model 'percentage_st_line' on 1000: Line 1 - 74% Line 2 - 24% Line 3 - 2% We get: 1000 * 0.74 = 740 (1000 - 740) * 0.24 = 62.4 (1000 - 740 - 62.4) * 0.02 = 3.95 Instead of: 1000 * 0.74 = 740 1000 * 0.24 = 240 1000 * 0.02 = 20 task_id: 3940370 Forward-Port-Of: odoo/enterprise#62884
Fixed an issue where the settle due accounts button was not always displayed on the partner details screen in the Point of Sale. The button is now always shown, with the label changing to "Deposit Money" when there's no amount due and "Settle Due Accounts" when there is an outstanding balance. This provides a better user experience and clearer guidance for staff handling customer payments.
Original PR description
The settle due accounts was not always shown on the partner screen. Now it's always shown, and when the user doesn't have any amount due the text changes to "Deposit Money" instead of "Settle Due Accounts" Steps to reproduce: ------------------- * Install pos_settle_due module * Open PoS session * Open partner list * Click on details for any partner with no due > Observation: The "Settle Due Accounts" button is missing Why the fix: ------------ We always show the button, but change the text to better match the behavior. If there is no amount due the text says "Deposit Money" and when the user has some amount due it says "Settle Due Accounts" opw-3925397 Forward-Port-Of: odoo/enterprise#65762
This fix resolves an issue where partner commissions were not being calculated when a quotation template was added to a commission plan's rules. The system now properly checks the sale order's quotation template when determining which commission rules apply, ensuring commissions are correctly generated even when using templates.
Original PR description
Steps to reproduce ------------------- - create a commission plan with: product category: "All" rate: R capped: True max commission: >>> - create a partner level with the created commission plan -…
Steps to reproduce
-------------------
- create a commission plan with:
product category: "All"
rate: R capped: True
max commission: >>>
- create a partner level with the created commission plan
- create a partner with the created partner level
- create a product in the correct category with price P
- create a quotation template with the created product
- create a sale order with the partner as referrer
- add the quotation template (the product is added automatically)
- confirm
- create the invoice, confirm it and register the payment
At this moment, a purchase order is created (the commission) If we repeat these steps with a new sale order,
the amount of the purchase order will increase as expected.
- add a quotation template on the commission plan (in the rules)
- repeat the creation of a sale order.
No commission is added (purchase order line).
Cause:
------
We have no template when calling `_match_rules`.
However, our plan has a default template.
The result is that no rules are found.
Solution:
---------
Fallback on the sale order's template
if it is not a subscription.
opw-3933323This fix corrects a critical issue in the disallowed expenses fleet report where transaction lines were being incorrectly grouped together when account IDs and vehicle IDs happened to match numerically. The fix ensures that expenses are properly separated by vehicle and account, preventing data misrepresentation and system crashes in the report display.
Original PR description
## [FIX] account_disallowed_expenses_fleet: query is mixing apple and pear The aim of this commit is to make the report behaves correctly when facing a DB with a lot of vehicles and a lot of accounts…
## [FIX] account_disallowed_expenses_fleet: query is mixing apple and pear The aim of this commit is to make the report behaves correctly when facing a DB with a lot of vehicles and a lot of accounts by making the query `group by` and `order by` more robust. Context: - 1 account and 1 vehicle share the same number for the id - the account is tagged with disallowed expense tag - 1 `account.move.line` without vehicle in that account - 1 `account.move.line` with a vehicle (with a dna rate) in the same account Before the commit: - The computation is giving wrong result in the report: 2 `account.move.line` were aggregated together under the hierarchy of the account without vehicle and the vehicle doesn't appear in the report at all. cause: the `CASE WHEN` could return, for example `92` as a `vehicle_id` and then `92` as an `account_id` and thus have them regrouped together. - 2 lines of the report were sharing the same "line_id" (the id given by report framework id, see method `_build_line_id`) which are used in a t-key property in an OWL loop resulting in a crash for the front-end. After the commit: - The 2 lines are aggregated seperatly: The line without `vehicle_id` is under the hierarchy of the account and the line with `vehicle_id` is under the hierachy of the concerned vehicle. - The line doesn't share any line_id anymore task-id: None (issue discovered in our own prod) ## [IMP] account_reports: ensure line_id is uniq in tests Moved to https://github.com/odoo/enterprise/pull/66216 Forward-Port-Of: odoo/enterprise#64166