Wednesday, March 13, 2024
26 changes · saas-17.1
Enhancements to existing features
This update enhances the payment term preview in the accounting module by using colors and borders to make the preview more visually distinct. This helps users quickly understand the results of their changes and clearly identifies the editable fields that control the preview. It’s a small improvement that boosts usability.
Original PR description
Emphasize the preview with colors and field borders to: - visually outline the preview result - clarify to the user that there are editable fields which customize the preview task: 3751514 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155367
Resolved issues and error corrections
This update corrects a migration step for the Czech localization that was missed in this branch. It helps ensure tax-related data is updated consistently during upgrades, reducing the risk of issues for Czech accounting users.
Original PR description
This migration script was forward ported from 15.0 to master. From saas-16.2, it should be done differently, it was adapted for all versions except saas-17.1. This PR: https://github.com/odoo/odoo/pull/148410 missed it.
Miscellaneous changes
Issues ------ All manufacturing orders are not having a start date This commit ----------- - Fix not updating start date on manufacturing orders - Migration update data --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143850 Forward-Port-Of: odoo/odoo#128043
Original PR description
Issues ------ All manufacturing orders are not having a start date This commit ----------- - Fix not updating start date on manufacturing orders - Migration update data --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143850 Forward-Port-Of: odoo/odoo#128043
This update fixes a minor issue where the Google and Outlook calendar sync buttons wouldn't automatically update their status after a sync restart. By introducing new states for reactive values, the buttons now correctly reflect the current sync status, improving user experience.
Original PR description
This PR aims to fix an issue with google/outlook sync buttons: The button state doesn't update automatically after restarting the sync. Changes: Introduced new states for the reactive values of the model, which control how the button is displayed. Task: 3731623 Forward-Port-Of: odoo/odoo#155174
This update resolves a technical error that occurred when a user deleted a company within Odoo. The fix ensures that onboarding progress data is properly removed, preventing errors and maintaining data consistency. This improves the stability of the accounting and sales modules.
Original PR description
### Steps to reproduce issue: 1. Download Accounting (or Sales or just Invoices) 2. Open Accounting 3. Create Company 2 and switch to it 4. Open Accounting again 5. Remove Company 2 6. Open…
### Steps to reproduce issue: 1. Download Accounting (or Sales or just Invoices) 2. Open Accounting 3. Create Company 2 and switch to it 4. Open Accounting again 5. Remove Company 2 6. Open Accounting 7. You receive an error: > ValueError: Expected singleton: onboarding.progress(1, 2) ### Explanation: In `_compute_current_progress`, the filter to get `current_progress_id` accepts `onboarding.progress` with both the company in which the user is at the moment or no company at all. https://github.com/odoo/odoo/blob/77f9ff50db3cdb88397d0b1cc7042c772d0d417b/addons/onboarding/models/onboarding_onboarding.py#L55-L69 This is due to the fact that some onboardings are not related to a company while others are. After that, getting the `onboarding_state` will trigger an `ensure_one` check. In the current case, an `onboarding.progress` with a `company_id` is not deleted once the company is deleted. Therefore the value becomes `False`. The `ensure_one` that comes after will throw an error because of it. ### Suggested fix: `ondelete` decorator would require the module to be upgraded. For this issue, it is preferable to have a fix that is automatically applied. The added method simulates the `cascade` effect of `ondelete` and does not require the module upgrade. opw-3762382 Forward-Port-Of: odoo/odoo#155407
This update fixes inconsistent alert margins in Odoo forms, ensuring a cleaner and more professional appearance. By standardizing the margin for alerts above form sheets, the design is now more aligned with the status bar and other key UI elements. This change impacts several modules including account, sales, and CRM.
Original PR description
Since Milk redesign the margin bottom on the alerts displayed above the sheet in a form view should be mb-2 (equivalent of the margin-bottom of the statusbar). Some alerts across Odoo were still inconsistent. This PR introduces a custom property `--alert-margin-bottom` which allows the customization of the alert's margin bottom depending on its context. This ensure that an alert rendered in the form view above the form_sheet will receive the appropriate margin as long as there is no utility class or override on the alert with this property, which is why this PR removes the mb-x classes or inner styling on the impacted alerts. task-3577058 Enterprise PR: https://github.com/odoo/enterprise/pull/52726 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156927 Forward-Port-Of: odoo/odoo#146196
This update corrects a translation error in the German localization of the 'l10n_din5008_sale' module. "Sales Order" now correctly translates to "Auftragsbestätigung" in German, ensuring accurate reporting and user experience. This was a previous fix that was accidentally reverted during a system update.
Original PR description
In the German localization, "Sales Order" MUST be translated as "Auftragsbestätigung". In all other cases it can remain as "Verkaufsauftrag". Term was previously corrected but then overwritten by accident during fw-port that used old translation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157424
This update corrects a visual issue where a tax destination field was incorrectly hidden in the partner view when displayed within a list of related items. The fix utilizes the correct 'column_invisible' attribute to ensure the field is properly visible. This resolves a minor cosmetic problem, improving the overall user experience.
Original PR description
In one2many, for the view, the attribute to hide a field should be column_invisible and not invisible --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157356
This update corrects a visual issue where text within the searchbar was invisible due to a color mismatch with the background. The fix ensures sufficient contrast for readability, particularly when using dark themes. This improves the user experience for all customers.
Original PR description
Steps to reproduce the bug: - Open the homepage and enter edit mode. - Click on the "Theme" tab. - Select the 4th color from the theme options and choose "black". - Drag and drop a "Search" snippet onto the page. - Save the page to exit edit mode. - Enter text in the searchbar input. - Bug: The text is not visible because its color is the same as the background color of the input. This bug appeared since this commit [1] where the "bg-light" class was added to the searchbar input. This caused the text color of the input, which by default is the same as the body color, to become invisible when the background color of the body is dark. To fix this, we now adjust the text color of the input based on the background color of the input. [1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20 task-3751401 Forward-Port-Of: odoo/odoo#156042
This update resolves an issue where margins were not correctly displayed on the form for fixed-price carriers after switching between fixed and variable pricing. The fix ensures that margins are accurately reflected in the system when using fixed-price carriers, improving the accuracy of shipping cost calculations. This change was made to address a reported bug and improve the user experience.
Original PR description
Steps to reproduce: - Create a shiping method based on rule - Set margins and then swith back to fixed price Bug: since this PR https://github.com/odoo/odoo/pull/108794 margins aren't displayed on the form anymore for fixed price but they are still set on the model if we edit the delivery type opw-3759128 Forward-Port-Of: odoo/odoo#155778
This update removes a restriction that prevented users from setting payment terms to negative days. Previously, negative payment terms were blocked, but they functioned correctly. This change allows for flexibility in payment term definitions, particularly for payments due before the end of the month.
Original PR description
Negative days are no longer allowed in the Payment Terms since 16.2, although it was possible before. There is no need to block user behaviour if they require negative days (for example, days before end of the month), as the payment term works as expected with negative days. To fix, we remove the constraint _check_positive. To reproduce the issue: - Go to Accounting -> Configuration -> Payment Terms - Edit/Create a Payment Term with a negative value in the 'After' column - When saving, a Validation error appears task-3751491 Forward-Port-Of: odoo/odoo#154617
This update corrects a minor issue where clicking a tag in the website blog sidebar would trigger an unnecessary redirect. The fix ensures the system uses the tag name directly, eliminating the redundant URL and improving user experience. This change enhances the overall stability and performance of the blog section.
Original PR description
In all cases, we will fetch the record since we display the name, so it has no extra cost to slug the record instead of the id, and it will prevent an extra redirect from /tag/1 to /tag/name-1 on click. opw-3752989 Forward-Port-Of: odoo/odoo#157493 Forward-Port-Of: odoo/odoo#157473
This update fixes a bug where the website event URL matching process failed when an event title was removed. Previously, the URL format relied on a hyphen, but removing the title resulted in a mismatch. The fix now correctly extracts the event ID regardless of the title's presence, ensuring consistent URL generation and functionality.
Original PR description
Issue: When editing with the editor an event and removing the title we get an issue since the url that we usually got is formatted like: '/event/title-3/register' where title is our event title and 3 the id, but when leaving the title blank the url will change to be like: '/event/3/register' in this case the match will no longer find anything since we no longer have a '-' on our url. Steps to reproduce: 1. Install website_event and go to the website view of any event. 2. Edit the event, and leave the title blank. 3. Save, and try to edit again the same title. Solution: We can directly get the id without the preciding '-', in this case we will get the id in both cases without having mismatch error. opw-3783998 Forward-Port-Of: odoo/odoo#157130
This update resolves an issue where a group chat test occasionally failed due to inconsistent member ordering. The change ensures the correct thread name is always displayed by explicitly defining the order of members within the chat, improving reliability and user experience.
Original PR description
The `unnamed group chat should display correct name` test checks that the name of a thread is updated after being invited. Sometimes, the test fails because the order of the members is different. We should maintain the desired order, not rely on what the server sends or how the data are handled internally by the javascript code. This PR adds the `sort` option to the `channelMember` field to ensure the order will always be the same. fixes runbot-58955
This update fixes an issue where the subcontracting Bill of Materials (BoM) overview sometimes displayed incorrect negative values. This change ensures that the overview accurately reflects component availability, leading to more reliable reporting and decision-making for subcontracting operations. The fix addresses a technical detail related to how subcontractor locations are handled.
Original PR description
Task: 3607854 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#144702
Commit https://github.com/odoo/odoo/pull/110550/commits/b347675c36cc5c3f54bf64f2e295d0afe9196be8 merges mo/wo scheduled & effective dates. Later commit https://github.com/odoo/odoo/pull/128043/commits/62590fa7d742267421a42cbf654352cd5b7e048c for 15.0 fixes the mo start date. Unfortunately, forward ports breaks 16.4 & later: starting a workorder unplan the subsequent ones. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/od
Original PR description
Commit https://github.com/odoo/odoo/pull/110550/commits/b347675c36cc5c3f54bf64f2e295d0afe9196be8 merges mo/wo scheduled & effective dates. Later commit https://github.com/odoo/odoo/pull/128043/commits/62590fa7d742267421a42cbf654352cd5b7e048c for 15.0 fixes the mo start date. Unfortunately, forward ports breaks 16.4 & later: starting a workorder unplan the subsequent ones. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157373 Forward-Port-Of: odoo/odoo#157345
The criterium might be evaluated but be an int (e.g 0). In that case the computation is stuck in an eternal loop where the criterium is added to `to_treat`. This commit adds a fix for the criterium_val type check. This happens when using subformulas like `if_other_expr_{above,below}` Forward-Port-Of: odoo/enterprise#58486
Original PR description
The criterium might be evaluated but be an int (e.g 0). In that case the computation is stuck in an eternal loop where the criterium is added to `to_treat`. This commit adds a fix for the criterium_val type check. This happens when using subformulas like `if_other_expr_{above,below}`
Forward-Port-Of: odoo/enterprise#58486__Current behavior before commit:__ The page crashes when a default search filter without group is set on the "Journal Items to reconcile" list __Description of the fix:__ Add optional chaining to check if groups is not `undefined` __Steps to reproduce the issue on runbot:__ 1. Go to Accounting > Accounting > Reconcile 2. Remove the *groupBy* search filter 3. Save current search and check "Default filter" 4. Refresh the page -> crash opw-3759244 Forward-Port-Of: odoo/enterprise#5
Original PR description
__Current behavior before commit:__ The page crashes when a default search filter without group is set on the "Journal Items to reconcile" list __Description of the fix:__ Add optional chaining to check if groups is not `undefined` __Steps to reproduce the issue on runbot:__ 1. Go to Accounting > Accounting > Reconcile 2. Remove the *groupBy* search filter 3. Save current search and check "Default filter" 4. Refresh the page -> crash opw-3759244 Forward-Port-Of: odoo/enterprise#58137
Steps to reproduce: ------------------- - create a subscription with a recurring product (which costs 100); - confirm it and create an invoice; - create an upsell for the subscription; - add the same product with a discount of 30%; - go to Sales report and search the product (product variant); Issue: ------ The report displays 300 for "Untaxed Total" instead 170. Cause: ------ The report takes into account the upsells and when they are validated, the information is put back on th
Original PR description
Steps to reproduce: ------------------- - create a subscription with a recurring product (which costs 100); - confirm it and create an invoice; - create an upsell for the subscription; - add the same product with a discount of 30%; - go to Sales report and search the product (product variant); Issue: ------ The report displays 300 for "Untaxed Total" instead 170. Cause: ------ The report takes into account the upsells and when they are validated, the information is put back on the original subscription. As a result, the information is duplicated. Solution: --------- Do not include upsells in the sales report. Note: ----- With the fix, the value is 200 and not 170, because it is not possible to take upsell discounts into account in the sales report (we have to use the subscriptions report). opw-3646388 Forward-Port-Of: odoo/enterprise#58369 Forward-Port-Of: odoo/enterprise#57568
Versions -------- - 17.0+ Steps ----- 1. Go to Payroll / Configuration / Switzerland / Work Locations; 2. create a new work address; 3. fill in fields & save. Issue ----- Error due to required field `bur_ree_number` being empty. Cause ----- Field is missing from the form. Solution -------- Add `bur_ree_number` to the form. opw-3783244 Forward-Port-Of: odoo/enterprise#58524
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Payroll / Configuration / Switzerland / Work Locations; 2. create a new work address; 3. fill in fields & save. Issue ----- Error due to required field `bur_ree_number` being empty. Cause ----- Field is missing from the form. Solution -------- Add `bur_ree_number` to the form. opw-3783244 Forward-Port-Of: odoo/enterprise#58524
Since Milk redesign the margin bottom on the alerts displayed above the sheet in a form view should be mb-2 (equivalent of the margin-bottom of the statusbar). Some alerts across Odoo were still inconsistent. This PR adapts the alerts from enterprise to remove the margin customizations on the impacted alerts. Letting the CSS variable introduced in the community counterpart PR handling the margin. task-3577058 Community PR: https://github.com/odoo/odoo/pull/146196 Forward-Port-Of: odoo/
Original PR description
Since Milk redesign the margin bottom on the alerts displayed above the sheet in a form view should be mb-2 (equivalent of the margin-bottom of the statusbar). Some alerts across Odoo were still inconsistent. This PR adapts the alerts from enterprise to remove the margin customizations on the impacted alerts. Letting the CSS variable introduced in the community counterpart PR handling the margin. task-3577058 Community PR: https://github.com/odoo/odoo/pull/146196 Forward-Port-Of: odoo/enterprise#58282 Forward-Port-Of: odoo/enterprise#52726
When the barcode application has many lines, it becomes slow and unresponsive, especially on mobile devices, which are widely used with the barcode app. Before this commit: Selecting a line in the barcode application triggers the rendering of the whole view. Each line rendered calls the getter `get selectedLine` multiple times, which is slow as it loops over all lines to find the currently selected line. After this commit: Do not call the getter to check whether the current line is selec
Original PR description
When the barcode application has many lines, it becomes slow and unresponsive, especially on mobile devices, which are widely used with the barcode app. Before this commit: Selecting a line in the barcode application triggers the rendering of the whole view. Each line rendered calls the getter `get selectedLine` multiple times, which is slow as it loops over all lines to find the currently selected line. After this commit: Do not call the getter to check whether the current line is selected or not. This reduces the complexity from O(n^2) to O(n). Benchmark: On a laptop and with 2000 lines, selecting the last line took 7.5s before, and 600ms with this commit. opw-3754849 Forward-Port-Of: odoo/enterprise#58182
The new UPS REST module was not neutralized. This commit makes sure that the credentials of the shipping methods are replaced with dummy values, so that shipping labels are not created by mistake. opw-3799821 Forward-Port-Of: odoo/enterprise#58489
Original PR description
The new UPS REST module was not neutralized. This commit makes sure that the credentials of the shipping methods are replaced with dummy values, so that shipping labels are not created by mistake. opw-3799821 Forward-Port-Of: odoo/enterprise#58489
Since commit [1], the report editor never crashes at loading time. This is intended to ease the migration process, or report recovery in general, where the operator could reset the views, explore the diff of some views, or edit their plain XML. However, commit [1] did not offer a way to actually see the error in the reportEditor itself. This was on purpose as the lambda user would not know what to do anyway with that information. This commit aims at offering that piece of information in ca
Original PR description
Since commit [1], the report editor never crashes at loading time. This is intended to ease the migration process, or report recovery in general, where the operator could reset the views, explore the diff of some views, or edit their plain XML. However, commit [1] did not offer a way to actually see the error in the reportEditor itself. This was on purpose as the lambda user would not know what to do anyway with that information. This commit aims at offering that piece of information in case we are in debug mode. The display of the error allows to open the incriminating views in a dialog, and see some basic information on them, as well as, obviously, the error message and type. opw-3735973 [1]: 62c167f87176674cbabad976d93eeb717f73df7a Forward-Port-Of: odoo/enterprise#58491
When a time off for a few days is taken using a certain allocation but then the number of days of the allocation is changed, there should be a warning on the dashboard of payroll to show the leaves affected. The warning redirects the user to a list of leaves concerned and grouped by employees. Task: 3729563 Forward-Port-Of: odoo/enterprise#56188
Original PR description
When a time off for a few days is taken using a certain allocation but then the number of days of the allocation is changed, there should be a warning on the dashboard of payroll to show the leaves affected. The warning redirects the user to a list of leaves concerned and grouped by employees. Task: 3729563 Forward-Port-Of: odoo/enterprise#56188
-master -saas-17.1 Steps to reproduce: - Open Help Desk app - Open any help-desk team - Click on search bar on the top Issue: - The issue here is that the SLA deadline filter in under properties which is separated and should be under Create Date filter Cause: - The SLA Deadline is added newly into the XML file but the field above i.e, Create Data is used as an Xpath(Field as an Xpath) to add a separator in a inherited record causing the the filter to be displaced Soluti
Original PR description
-master -saas-17.1 Steps to reproduce: - Open Help Desk app - Open any help-desk team - Click on search bar on the top Issue: - The issue here is that the SLA deadline filter in under properties which is separated and should be under Create Date filter Cause: - The SLA Deadline is added newly into the XML file but the field above i.e, Create Data is used as an Xpath(Field as an Xpath) to add a separator in a inherited record causing the the filter to be displaced Solution: - Changing the Xpath(Field as an Xpath) as SLA DeadLine allows the Properties filter to be added and SLA Deadline to be under Create Date Filter task-3707563 Forward-Port-Of: odoo/enterprise#55595