Friday, January 20, 2023
65 changes · master
Enhancements to existing features
Clicking records in embedded list fields now behaves more consistently: editable lists enter inline editing, while read-only lists no longer unexpectedly open a pop-up form. This reduces confusion for users and keeps pop-up opening available only where it is explicitly configured, while kanban-style embedded views keep their existing behavior.
Original PR description
This commit disable by default the opening of the form view when clicking on a record in a x2many list field. Before when clicking on a record in a x2many list field: - sometimes it goes into inline edition mode - sometimes it opens the record in a modal form - sometimes it does nothing With this commit, we remove the "popup" option and the behavior becomes more logical: it goes into inline edition if the field is editable, otherwise nothing happens. For specific cases, it is possible to activate this behaviour in the tree arch with the `open_on_click="0"` attribute. This option was previously named `no_open` but the double negation needed to open a record (`no_open="0"`) is not clear enough. If the x2many field renders a kanban, it stills open the records in a modal by default because unlike the list, the kanban does not contain all/most of the required information of the record. task-id: 2964320
This update removes an obsolete reference to a previously removed web dashboard component from an internal configuration file. It helps keep development tooling clean and reduces confusion for future maintenance, with no expected impact on business users.
Original PR description
before this commit, the web_dashboard module was refferenced in _eslintignore file web_dashboard module was removed by this commit: https://github.com/odoo/enterprise/commit/658606bd870041da8a7c969c3ffe63f762e5daf5 after this commit, the refferenced web_dashboard module will be removed from _eslintignore file. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update standardizes avatar display sizes across several Odoo apps, helping profile images and user icons look more consistent throughout the product. It also renames older avatar styling to prevent conflicts with the new shared sizing approach.
Original PR description
In order to keep consistency between common avatar sizes, this commit introduces new utility classes to handle them. Requires: - https://github.com/odoo/enterprise/pull/31065 task-2973409 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The payment interface now uses the clearer label "Payment Method" instead of "Payment Icon". This helps users better understand that they are selecting or managing available ways to pay, reducing confusion across payment setup and checkout screens.
Original PR description
Payment Icon sounds confusing comparing to what it really is, payment method name makes it clearer for user to understand what it is. task-2882564 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: See also: https://github.com/odoo/enterprise/pull/33908 See also: https://github.com/odoo/upgrade/pull/4029 See also: https://github.com/odoo/documentation/pull/2955 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The test exception form now shows a simple Close button instead of Save and Discard options. This makes the screen clearer for users because the form is intended for viewing rather than editing.
Original PR description
before this commit, when opening the test exception form from Tests -> Test exceptions -> Test exceptions, in the bottom of the form it currently shows Save and Discard button. after this commit, on opening the same form, instead of save and discard, it will show Close button to close the opened form. Before:  After:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Accounting users can now create bank statements and miscellaneous operations directly from the Documents app when the journal is already known. This streamlines importing files such as CODA and SODA by matching the behavior available from the accounting dashboard.
Original PR description
Add 2 document.workflow.action so that bank statement (e.g. CODA) and misc operation (e.g. SODA) can be imported from the document app. The behavior is similar to the one found in the accounting dashboard. Note: the no_document context is irrelevant in the account.move scope as it does not inherit from 'documents.mixin' task-id: 3116350 [enterprise](https://github.com/odoo/enterprise/pull/35486) [community](https://github.com/odoo/odoo/pull/109617)
Survey result pages now handle long single-line answers more cleanly, keep answer tables visually stable when switching pages, and show a clearer message when there are no answers. This makes reviewing survey responses easier and less distracting for users.
Original PR description
Purpose ======= Give users a better experience when using the survey result page. Specifications ============== Handle long chars display for single-line question answers by showing them on multiple lines. Prevent answer tables from flickering when having multiple pages with different answers count by fixing their height. Display a no answers helper instead of the empty table and the alert message. Task-2957775
CRM forecasting and related sales pipeline views were updated to use newer internal tools for date handling and screen behavior. This helps keep the forecasting experience reliable and easier to maintain without changing day-to-day CRM workflows.
Original PR description
owl improvements Applies minor fixups to improve owl usage in CRM, following the JS team advice: https://github.com/odoo/odoo/pull/104975 * remove unused export * use orm service from model * remove redundancy for component call stop using moment Replace moment calls by their equivalent with the luxon library in CRM, and make use of date utils from the l10n module. Task-3056665
The email template preview screen was updated to use Odoo’s standard form layout instead of a custom Bootstrap layout. This makes the screen more consistent with the rest of Odoo and easier to maintain, with only a minor label wording change for the test record field.
Original PR description
Small refactor of the template preview form to use regular group and field tags instead of custom layout using bootstrap. Technical note: the label resource_ref has no "for" attribute because when adding it, the label content is replaced by the standard field label (here "Record"). We cannot use also the "string" attribute as the label is dynamic. Task-3098782 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The referral reporting screen now shows a clean, purpose-built record view instead of a generic automatically generated layout. This makes individual referral report records easier to read when users drill down from reporting charts or lists.
Original PR description
before this commit, no form view was defined for the model hr.referral.report and thus on clicking the tree view and opening the record, currently it shows the odoo generated form view. Referrals -> Reporting, switch to graph view and click on any record, from the opening tree, click and open any record to get form view. after this commit, on opening the form view, clean form view will be displayed.
The SEPA Direct Debit payment setup now uses the clearer label “Payment Method” instead of “Payment Icon.” This makes the interface easier to understand by describing what the field actually represents.
Original PR description
Changing Payment Icon to Payment Method in order to reflect what it really is and for more clearance. task-2882564
This update modernizes how social media comment dates are read and displayed when creating CRM leads from social posts. It improves long-term reliability by replacing an older date-handling library with the current standard used across supported social networks.
Original PR description
social_crm: stop using moment
Replace moment calls by their equivalent with the luxon library in SOCIAL,
and make use of date utils from the l10n module.
For reference, here are all the `created_time` formats for supported social
streams comments and the respective luxon parser:
-> facebook: created_time: '2017-06-06T18:04:10+0000'
luxon: fromISO
-> instagram: timestamp: '2017-05-19T23:27:28+0000'
luxon: fromISO
-> linkedin: created[time]: 1582160678569
luxon: fromMillis
-> twitter: created_at: 'Wed Oct 10 20:19:24 +0000 2018'
API v1.1 luxon: fromFormat({format:'EEE MMM d HH:mm:ss ZZZ yyyy'})
-> youtube: publishedAt: '2017-11-13T06:06:22Z'
luxon: fromISO
Task-3056665Customers who try to close a subscription now receive a suggested solution based on their selected reason. The subscription is only cancelled if they decline the proposed solution, helping businesses reduce avoidable churn while making the closure flow clearer.
Original PR description
When a customer wants to close a subscription, a solution is now proposed based on the close reason. The subscription is only closed if the customer does not accept the solution. Also, subscription close flow text is reworded. task-2723891
This update standardizes avatar image sizes across multiple Odoo Enterprise apps. It helps provide a more consistent and polished user experience in portals, dashboards, social feeds, planning views, documents, and related screens.
Original PR description
In order to keep consistency between common avatar sizes, this commit introduces new utility classes to handle them. Requires: - https://github.com/odoo/odoo/pull/99573 task-2973409
Resolved issues and error corrections
The email marketing campaign board was slowed down by recalculating recipient totals for campaigns with complex filters. This fix reduces that delay so teams with many campaigns can open the overview more quickly.
Original PR description
Description of the issue/feature this PR addresses: On large database with lot of mailing.mailing with complexe domain, the kanban view take lot of time to load (10 seconds with 56 mailings). Because the field total is a computed field with domain made by user (not the most optimized domain :-) ). Note 1 : I don't know if it is the best solution Note 2 : This issue exist in V14 (but I make the PR in master). @tde-banana-odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This change moves a website template loading test and its test-only data into the dedicated test website module. It keeps the main website module cleaner by separating internal test assets from production module content, with no expected impact on users.
Original PR description
When the QWeb `<template>` loading test was introduced at [1], the `test_website` module did not exist yet, see [2]. This commit moves that test and its related data file to `test_website` to remove the `fake data` noise from the `website` module. That's one of the two purpose of this `test_website` module: - Avoid noising the website module with test only data & code - Encapsulate in a lighter module the module operations tests, but it's not really the case anymore as those tests are now standalone tests. See manifest for more details. [1]: https://github.com/odoo/odoo/commit/9cd982bcc811cacb42f5c08db139043d2734b891 [2]: https://github.com/odoo/odoo/commit/ef03db9edd9472201cb2c08a32d20ff0f33a5fdf
Miscellaneous changes
1 - fix `create_name_field` option of many2one field component - The `create_name_field` option of many2one fields in form views does not work: when setting it, the value entered in the many2one field is copied in the default `name` field, instead of in the field set, when clicking on the "Create and Edit" button. This is because an incorrect prop is used: the many2one component uses a prop named `createNameField` for that purpose, but passes a prop called `nameCreateField` to the Ma
Event emails that include Google static maps now use signed links so the required Google API key is not exposed or misused. Event settings also make it easier to configure the Maps API key, and email cleanup was adjusted so these signed map links remain valid.
Original PR description
Google now requires an API key for the static maps API. As API calls cost money, and we cannot restrict the domain of the caller with the API key in emails, as the domain may vary vastly, the signing of static API URLs is implemented in the existing 'google_map_img' of partners. This in turn can be used to get a url for an existing location. While preventing anyone from stealing the API key for their own purposes task - 3079113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes the sales order screen so staff can still send a quotation for website orders even when a recovery email option is also available. It helps back-office teams complete customer orders more easily after an online cart has been started.
Original PR description
**Description of the issue/feature this PR addresses:** - A customer start an order on website - A few days later the back office call the customer to finalize the order. And try to send the quotation. --> Issue the button "Send Quotation" is remplaced by "Send a Recovery Email" **Desired behavior after PR is merged:** With this PR both button are show. It is more user friendly. @JKE-be -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The CRM forecast view now handles the Upcoming Closings filter consistently when combined with related filters. This prevents future filtering mismatches and helps keep sales forecast results aligned with what users see on screen.
Original PR description
The `forecast_filter` facet (aka Upcoming Closings) would have been combined with other filters from the same group with a logical 'AND' while displaying an 'OR' combination. Fortunately it is currently the only item of its group so it does not cause a problem. This commit fix the inconsistency so that `forecast_filter` using the forecast_search_model won't have this issue in the future. Task-2657578
This change adjusts an internal performance test threshold for subscriptions so routine test runs are less likely to fail unpredictably. It helps maintain reliable development and release checks without changing customer-facing subscription features.
Original PR description
Before this commit, the query counter of performance test in subscription reached easily the limit in undeterministic occasions.
The Peru electronic stock invoicing settings were updated so they work with the latest settings layout. This ensures users can find these settings through search, reducing confusion during configuration.
Original PR description
Change the arch to use the new tags for the settings. If the new tags are not used, the search cannot be performed on these settings. See: 02f7835aade005484ca49a8ba4c5c5feea249aae
Spreadsheet dashboards now use a clearer internal name for the stored spreadsheet data instead of the vague legacy name. This makes the feature easier to maintain and integrate without changing the dashboard experience for users.
Original PR description
Up until now, the collaborative expected a field named `raw` containing the serialized json data. This is historic and appeared because the field containing the existing field `raw` on `document.document` contained this data. The name `raw` is meaningless. Now the collaborative expects and will call a method called `get_spreadsheet_data` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The spreadsheet collaboration code now uses a clearer name for stored spreadsheet data instead of the vague legacy "raw" field. This is an internal cleanup that makes the feature easier to maintain while preserving the existing spreadsheet dashboard behavior for users.
Original PR description
Up until now, the collaborative expected a field named `raw` containing the serialized json data. This is historic and appeared because the field containing the existing field `raw` on `document.document` contained this data. The name `raw` is meaningless. Now the collaborative expects and will call a method called `get_spreadsheet_data`
Original PR description
1 - fix `create_name_field` option of many2one field component - The `create_name_field` option of many2one fields in form views does not work: when setting it, the value entered in the many2one…
1 - fix `create_name_field` option of many2one field component - The `create_name_field` option of many2one fields in form views does not work: when setting it, the value entered in the many2one field is copied in the default `name` field, instead of in the field set, when clicking on the "Create and Edit" button. This is because an incorrect prop is used: the many2one component uses a prop named `createNameField` for that purpose, but passes a prop called `nameCreateField` to the Many2XAutocomplete component. This commit renames the `createNameField` prop of the many2one field to `nameCreateField`, to match the prop used in many2many_tags_field and in Many2XAutocomplete. 2 - fix utm campaigns quick creation - Since the introduction of the required "title" field in the utm_campaign model in commit [1], quick creation of campaigns from many2ones is not possible anymore (the slow creation modal is opened when clicking on "Create"), and the name value entered is not copied into the name field of the creation form. This is because the model now has a field "name", and a field "title", which are both required. The creation using the many2one widget tries to create a record using the entered value as title and no name, which fails. This commit makes sure that if a title but no name is given when creating a new campaign record, the name will be computed using the given title. It also makes sure that the value entered before clicking on the "create and edit" button is copied in the form, by adding the "create_name_field" option on the many2one fields (the form uses the title field, not the name). [1]: https://github.com/odoo/odoo/commit/4dbcefb5e5b1878e81fe9be9fe48a785f813334f Task-3113954 Forward-Port-Of: odoo/odoo#109743
Steps to reproduce: - create a coupon program with a discount type reward on specific product; - "reward_point_mode" has to be "per unit paid"; - create a sale order; - add a product several times; - click on the "PROMOTIONS" button to apply promotion program. Issue: We calculate the amount of the discount on the total price of the product. Expected behavior: - If you buy 1 product at 100, you can consume 1 point, each of which is worth 10% of the remaining amount to be paid, so
Original PR description
Steps to reproduce: - create a coupon program with a discount type reward on specific product; - "reward_point_mode" has to be "per unit paid"; - create a sale order; - add a product several times; -…
Steps to reproduce: - create a coupon program with a discount type reward on specific product; - "reward_point_mode" has to be "per unit paid"; - create a sale order; - add a product several times; - click on the "PROMOTIONS" button to apply promotion program. Issue: We calculate the amount of the discount on the total price of the product. Expected behavior: - If you buy 1 product at 100, you can consume 1 point, each of which is worth 10% of the remaining amount to be paid, so you have to pay 100 * 0.9 = 90 - If you buy 2 products at 100, you can consume 2 points, each of which is worth 10% of the remaining amount to pay, so you have to pay 200 * 0.9 * 0.9 = 162 - If you buy 3 products at 100, you can consume 3 points, each of which is worth 10% of the remaining amount to be paid, so you have to pay 300 * 0.9 * 0.9 * 0.9 = 218.7 - If you buy 4 products at 100, you can consume 4 points, each of which is worth 10% of the remaining amount to pay, so you have to pay 400 * 0.9 * 0.9 * 0.9 * 0.9 = 262.44 - If you buy 5 products at 100, you can consume 5 points, each of which is worth 10% of the remaining amount to be paid, so you have to pay 500 * 0.9 * 0.9 * 0.9 * 0.9 * 0.9 = 295.24 opw-3112925 Forward-Port-Of: odoo/odoo#110285
The PR https://github.com/odoo/odoo/pull/109461 fixed the size of the dragging row but it did not care about cells with colspan. Since this PR, another one (https://github.com/odoo/odoo/pull/110349) has been opened to manage the colspan in the section_and_note widget but the issue also exists in other subclass of list. This commit moves the fix from the section_and_note widget in the base list. Forward-Port-Of: odoo/odoo#110404
Original PR description
The PR https://github.com/odoo/odoo/pull/109461 fixed the size of the dragging row but it did not care about cells with colspan. Since this PR, another one (https://github.com/odoo/odoo/pull/110349) has been opened to manage the colspan in the section_and_note widget but the issue also exists in other subclass of list. This commit moves the fix from the section_and_note widget in the base list. Forward-Port-Of: odoo/odoo#110404
before this commit, in the tree view of restaurant.printer model the field product_categories_ids is showing the value in tree as 1 records, 2 records based on the no of records added in the m2m field. after this commit, when the widget many2many_tags is given, the selected field values will be shown in the tree view, so the end users can see the selected categories without going into the form view. Before:  After:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#109872
Steps to reproduce: - Go to Employee - Open the Employee profile and click on Work information. - In the Organization Chart Below the hierarchy See All button is visible. - Click on the 'See All' button. Currently, when we click on the ``see all'' button of the organization chart, the traceback comes. Fixed it in this commit. task-3133047 Forward-Port-Of: odoo/odoo#110069
Original PR description
Steps to reproduce: - Go to Employee - Open the Employee profile and click on Work information. - In the Organization Chart Below the hierarchy See All button is visible. - Click on the 'See All' button. Currently, when we click on the ``see all'' button of the organization chart, the traceback comes. Fixed it in this commit. task-3133047 Forward-Port-Of: odoo/odoo#110069
Steps to reproduce the bug: - Create a storable product “P1”: - Go to product category → set the inventory valuation to “Automated” - Create a BoM: - Add a component with the cost set to 10$ - Add an analytic account - Create a MO to produce one unit of “P1”: - Confirm the MO: - an analytic account line is created with the amount of $10 - Mark as done the MO: - The amount is updated to $0 Problem: In the case where the inventory
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Go to product category → set the inventory valuation to “Automated”
- Create a BoM:
- Add a component with the cost set to 10$
- Add an analytic account
- Create a MO to produce one unit of “P1”:
- Confirm the MO:
- an analytic account line is created with the amount of $10
- Mark as done the MO:
- The amount is updated to $0
Problem:
In the case where the inventory valuation is set to “automated” we use the analytical distribution since this commit: https://github.com/odoo/odoo/blob/7e3403068fc3fbc40182b3cfeb80e97a9300e8ff/addons/account/models/account_move_line.py#L2326
but in the case of MO it shouldn't use it
Solution:
If we are in MO, ignore the type of inventory valuation
opw-3081877
opw-3086626
Forward-Port-Of: odoo/odoo#109910Description 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#110386
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#110386
On January first, the test test_so_and_multicurrency fails because it creates a new currency rate on EUR. There is already a currency rate created in the demo data (base/data/res_currency_rate_demo.xml) for the 01-01. This commit search the existence of this currency rate before creating it to avoid duplicates 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
Original PR description
On January first, the test test_so_and_multicurrency fails because it creates a new currency rate on EUR. There is already a currency rate created in the demo data (base/data/res_currency_rate_demo.xml) for the 01-01. This commit search the existence of this currency rate before creating it to avoid duplicates 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#109063
The function that adds the missing url root on documentation links uses a regex in startsWith, which is not supported. startsWith is replaced with ``regex.test`` which will succeed if the regex has any match. Which is fine because we use a '^' to ensure it *starts* with https task-3079113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110403
Original PR description
The function that adds the missing url root on documentation links uses a regex in startsWith, which is not supported. startsWith is replaced with ``regex.test`` which will succeed if the regex has any match. Which is fine because we use a '^' to ensure it *starts* with https task-3079113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110403
In the web editor when the placeholder using the class `oe-hint` is shown the insertion caret color is almost invisible in dark-mode. This commits reset the caret to its default behavior by removing the `caret-color` property from the class `oe-hint`. Therefore making the caret dark in white mode and white in dark mode even when the placeholder is shown. It makes it consistent with all the other inputs w/ a placeholder. task-3099628 [Before]  [After fix]  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110176
Before this commit, if you create a sale order for partner who is not is not a salesman on the res.partner, you become the salesman of the sale.order. No matter if you are salesman or even employee. After this commit, the customer or public user will be not assigned as a salesman on sale.order when creating without forcing the user_id = False. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110451
Original PR description
Before this commit, if you create a sale order for partner who is not is not a salesman on the res.partner, you become the salesman of the sale.order. No matter if you are salesman or even employee. After this commit, the customer or public user will be not assigned as a salesman on sale.order when creating without forcing the user_id = False. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110451
Before this commit, it was possible to edit void element if they were branded. It does not make sense to edit a void element. task-3096813 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110266 Forward-Port-Of: odoo/odoo#108471
Original PR description
Before this commit, it was possible to edit void element if they were branded. It does not make sense to edit a void element. task-3096813 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110266 Forward-Port-Of: odoo/odoo#108471
**Current behavior before PR:** When entering edit mode on the website and discarding directly, the editor considers that there are changes in the DOM and displays a modal with "Are you sure you want to discard because there are pending changes". **Desired behavior after PR is merged:** Now, when entering edit mode on the website and discarding it directly will not display a confirmation modal. Task-3056463 Forward-Port-Of: odoo/odoo#105846
Original PR description
**Current behavior before PR:** When entering edit mode on the website and discarding directly, the editor considers that there are changes in the DOM and displays a modal with "Are you sure you want to discard because there are pending changes". **Desired behavior after PR is merged:** Now, when entering edit mode on the website and discarding it directly will not display a confirmation modal. Task-3056463 Forward-Port-Of: odoo/odoo#105846
Before this commit, the form view in dark mode had some coloring issue. This commit fixes that issue. task-3138224 Forward-Port-Of: odoo/odoo#110175
Original PR description
Before this commit, the form view in dark mode had some coloring issue. This commit fixes that issue. task-3138224 Forward-Port-Of: odoo/odoo#110175
When the only change in a form was made in the html editor, if the user did not blur the editor, the content was not saved. The reason is because the `urgentSave` in `basic_relational_model.js` check if the record is dirty before the HtmlField had the time to update the value to make it dirty since the commitChange in the HtmlField could run promises before calling `update`. To solve it, in case of urgent save, we update the value before any asynchronous modification and re-update it after
Original PR description
When the only change in a form was made in the html editor, if the user did not blur the editor, the content was not saved.
The reason is because the `urgentSave` in `basic_relational_model.js` check if the record is dirty before the HtmlField had the time to update the value to make it dirty since the commitChange in the HtmlField could run promises before calling `update`.
To solve it, in case of urgent save, we update the value before any asynchronous modification and re-update it after those modifications.
In order to have this strategy only on urgentSave and not on the blur of the editor, the params `{urgent: true}` has been removed in `_onWysiwygBlur` as it seems to not be useful. Another params will need to be added if we want to keep that behavior on blur.
task-3140763
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#110244Change the arch to use the new tags for the settings. If the new tags are not used, the search cannot be performed on these settings. See: 02f7835aade005484ca49a8ba4c5c5feea249aae Forward-Port-Of: odoo/odoo#110433
Original PR description
Change the arch to use the new tags for the settings. If the new tags are not used, the search cannot be performed on these settings. See: 02f7835aade005484ca49a8ba4c5c5feea249aae Forward-Port-Of: odoo/odoo#110433
Before this PR, this flow was broken: - Install website - Create a new website of your own (not using the one created automatically from XML data) - Choose another color palette for that website - Uninstall the website app - Reinstall the website app - Try to choose another color palette for any website => It does not work Indeed, after the uninstallation, the DB is left in an invalid state: the SCSS customizations attachments of the website that was created by the user are not
Original PR description
Before this PR, this flow was broken: - Install website - Create a new website of your own (not using the one created automatically from XML data) - Choose another color palette for that website -…
Before this PR, this flow was broken: - Install website - Create a new website of your own (not using the one created automatically from XML data) - Choose another color palette for that website - Uninstall the website app - Reinstall the website app - Try to choose another color palette for any website => It does not work Indeed, after the uninstallation, the DB is left in an invalid state: the SCSS customizations attachments of the website that was created by the user are not removed, they just have their website_id field emptied. Some code made at [1] was already there to remove those attachments. The problem is that it only worked for websites which were created by XML data (at website installation), not by the user. Indeed, the `unlink` method is not called during uninstallation to remove records that were created by the user, thus the `unlink` override was not called either. See [2] for some details. This fixes the issues by moving this attachment cleaning code in a dedicated method, called in `unlink` but also in the `uninstall_hook` of the website app. [1]: https://github.com/odoo/odoo/commit/2f361bec36dff09181b96d140d62c477cdf013a1 [2]: https://github.com/odoo/odoo/pull/97852#pullrequestreview-1067851656 opw-3127531 Forward-Port-Of: odoo/odoo#110214 Forward-Port-Of: odoo/odoo#109785
Steps: - Install project app. - Active Sub-tasks feature in config settings - Create task with parent task - Green the kanban state - Modify the parent task 1. Issue: The kanban state changes when we change the parent task in the task. 2. Fix: We avoid the recomputing kanban state. 3. Why issue occurred: When we change the parent task _compute_project_id is called and sets the project. the _compute_kanban_state method depends on the project. So reset
Original PR description
Steps:
- Install project app.
- Active Sub-tasks feature in config settings
- Create task with parent task
- Green the kanban state
- Modify the parent task
1. Issue:
The kanban state changes when we change the parent task in the task.
2. Fix:
We avoid the recomputing kanban state.
3. Why issue occurred:
When we change the parent task _compute_project_id is called and sets the project.
the _compute_kanban_state method depends on the project. So reset the kanban state.
task-3141855
Forward-Port-Of: odoo/odoo#110359Before this commit, clicking on a SendSMSButton in a FormViewDialog could change the record of the main form view. Problem: When closing the dialog opened by the SendSMSButton, the model is reloaded with the record id associated with the button. This has the effect of replacing the root with this record. This will replace the record used in the main form view by the one in the FormViewDialog. How to reproduce: - Go to a form view with an x2m field that has the same model as the form view
Original PR description
Before this commit, clicking on a SendSMSButton in a FormViewDialog could change the record of the main form view. Problem: When closing the dialog opened by the SendSMSButton, the model is reloaded…
Before this commit, clicking on a SendSMSButton in a FormViewDialog could change the record of the main form view. Problem: When closing the dialog opened by the SendSMSButton, the model is reloaded with the record id associated with the button. This has the effect of replacing the root with this record. This will replace the record used in the main form view by the one in the FormViewDialog. How to reproduce: - Go to a form view with an x2m field that has the same model as the form view - Add a record in the x2m in order to open a FormViewDialog with at least one field using the "phone" widget - Complete the field with the "phone" widget - Click on the "SMS" button - Click on "Discard" button Before this commit: The dialog opened by SendSMSButton is closed and the main form view record is replaced by the FormViewDialog record. After this commit: The dialog opened by SendSMSButton is closed and the record of the main form view has not changed. TaskID: 3107429 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#110199
Have a char field with trim option set to True (this is the default). Open a form view where the value of this field has leading or trailing spaces. Press F5 (or close the tab/browser). Before this commit, a write was done before leaving, with the trimmed value of the char field. This isn't the expected behavior: as the field hasn't been manually edited, we don't want to write on it. This could be reproduced on project.task form views, on tasks with a name with leading/trailing spaces (e.g
Original PR description
Have a char field with trim option set to True (this is the default). Open a form view where the value of this field has leading or trailing spaces. Press F5 (or close the tab/browser). Before this…
Have a char field with trim option set to True (this is the default). Open a form view where the value of this field has leading or trailing spaces. Press F5 (or close the tab/browser). Before this commit, a write was done before leaving, with the trimmed value of the char field. This isn't the expected behavior: as the field hasn't been manually edited, we don't want to write on it. This could be reproduced on project.task form views, on tasks with a name with leading/trailing spaces (e.g. tasks created by mails sent to feedback@odoo.com). The issue occurred when we saved a record "urgently" (before unload) because we parsed the value of each input field, and we sent it if it was different from the initial (or last set) value. In our case, parsing the value trimmed it, and it was thus different from the initial value. Bug reported after the migration of odoo.com to 16.0. 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#110434
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#110499
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#110499
This commit is a follow-up of odoo/odoo@bb819f6a5c8f6e85eab865efd2c4d017a6258c33. Even if the fix above worked around having the settinggs header's content out of screen on smaller screen, the solution was ugly and was meant to be improved later on. This commit reworks the HeaderSetting's template and simplifies it to properly fix this issue. Forward-Port-Of: odoo/odoo#110253
Original PR description
This commit is a follow-up of odoo/odoo@bb819f6a5c8f6e85eab865efd2c4d017a6258c33. Even if the fix above worked around having the settinggs header's content out of screen on smaller screen, the solution was ugly and was meant to be improved later on. This commit reworks the HeaderSetting's template and simplifies it to properly fix this issue. Forward-Port-Of: odoo/odoo#110253
This commit add the missing `o_action_delegate_scroll` on the activity view controller on small screen device to scroll the activity view content only instead of the whole controller (i.e. control panel included). Steps to reproduce: 1. Open Project on small screen device like a smartphone 2. Open a Project like 'Office Design' 3. Switch to the Activity view and try to scroll horizontally => The whole activity controller currently scroll => bug Forward-Port-Of: odoo/odoo#110465 Forward-
Original PR description
This commit add the missing `o_action_delegate_scroll` on the activity view controller on small screen device to scroll the activity view content only instead of the whole controller (i.e. control panel included). Steps to reproduce: 1. Open Project on small screen device like a smartphone 2. Open a Project like 'Office Design' 3. Switch to the Activity view and try to scroll horizontally => The whole activity controller currently scroll => bug Forward-Port-Of: odoo/odoo#110465 Forward-Port-Of: odoo/odoo#110395
Here is a way to reproduce the problematic situation: with CRM installed, go to Contacts, open one, clicks on its Opportunities stat button, open one in form view, click on the "Customer" field internal link to open again the contact in form view, delete the record, and finally click on the first occurence of the contact in the breadcrumbs. Before this commit, it crashed because we ended up in an error handler (formSaveErrorHandler) that doesn't deal with the fact that originalError co
Original PR description
Here is a way to reproduce the problematic situation: with CRM installed, go to Contacts, open one, clicks on its Opportunities stat button, open one in form view, click on the "Customer" field internal link to open again the contact in form view, delete the record, and finally click on the first occurence of the contact in the breadcrumbs. Before this commit, it crashed because we ended up in an error handler (formSaveErrorHandler) that doesn't deal with the fact that originalError could be falsy. This is handled by the legacyRejectPromiseHandler, but due to the low sequence of the faulty handler, this one was executed after. Same error would occur if you tried to open an url of a record that doesn't exist. This commit fixes the error handler sequences s.t. the crash no longer occurs. Issue reported in the feedback pad after migrating odoo.com to 16.0. Forward-Port-Of: odoo/odoo#109931
Add a test to ensure the price of an event ticket is correctly converted on a Sale Order. Forward-Port-Of: odoo/odoo#110473 Forward-Port-Of: odoo/odoo#109006
Original PR description
Add a test to ensure the price of an event ticket is correctly converted on a Sale Order. Forward-Port-Of: odoo/odoo#110473 Forward-Port-Of: odoo/odoo#109006
**Current behavior before PR:** Text style and text size drop-up were not fully visible due to overflow. **Desired behavior after PR is merged:** Added a scroll property to give accessibility to the items. Task-3100123 Forward-Port-Of: odoo/odoo#109320
Original PR description
**Current behavior before PR:** Text style and text size drop-up were not fully visible due to overflow. **Desired behavior after PR is merged:** Added a scroll property to give accessibility to the items. Task-3100123 Forward-Port-Of: odoo/odoo#109320
To Reproduce ============ on POS go to customer, on the customers list we only display a short address. which gives bad experience to the user. Solution ======== The address information displayed was reduced in early 15 because it was often too long and caused rendering issues, on both desktop and mobile. On 16 we have more space, so we bring back the full address. opw-3123832 Forward-Port-Of: odoo/odoo#110459 Forward-Port-Of: odoo/odoo#109790
Original PR description
To Reproduce ============ on POS go to customer, on the customers list we only display a short address. which gives bad experience to the user. Solution ======== The address information displayed was reduced in early 15 because it was often too long and caused rendering issues, on both desktop and mobile. On 16 we have more space, so we bring back the full address. opw-3123832 Forward-Port-Of: odoo/odoo#110459 Forward-Port-Of: odoo/odoo#109790
In the current state of the code, pricelist are always recalculated according to the partner id of the user. In the case of a custom pricelist applying to anyone with a code, Odoo will bring back the default pricelist, forcing us to retype the code once or twice during the checkout process. opw-3101158 Forward-Port-Of: odoo/odoo#108728
Original PR description
In the current state of the code, pricelist are always recalculated according to the partner id of the user. In the case of a custom pricelist applying to anyone with a code, Odoo will bring back the default pricelist, forcing us to retype the code once or twice during the checkout process. opw-3101158 Forward-Port-Of: odoo/odoo#108728
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110380
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110380
[FIX] web: invert position (start/end) when using rtl Before this commit, when using a rtl language, the position of the popper elements using the 'usePosition' hook weren't inverted. --- [FIX] web: align text to the end in RTL languages Bootstrap forces some input types ("tel", "url", "email", "number") to be LTR even if in an RTL languages, before the last update of bootstrap this was done in [1] and [2]. The issue of forcing some input types to LTR, is that the alignment was
Original PR description
[FIX] web: invert position (start/end) when using rtl
Before this commit, when using a rtl language, the position of the
popper elements using the 'usePosition' hook weren't inverted.
---
[FIX] web: align text to the end in RTL languages
Bootstrap forces some input types ("tel", "url", "email", "number") to
be LTR even if in an RTL languages, before the last update of bootstrap
this was done in [1] and [2].
The issue of forcing some input types to LTR, is that the alignment was
wrong. Now, the for the same types when using an RTL language we force
the align to the end.
[1] : https://github.com/odoo/odoo/commit/90ab752c5fc9b27a6a40006abfe49483e7ca847d
[2] : https://github.com/odoo/odoo/commit/0d650c3b19c847181fa50c88eb945792528f01cc
Forward-Port-Of: odoo/odoo#110288replacing text-right with text-end in bs5 Before:  After:  Related EE: https://github.com/odoo/enterprise/pull/35498 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com
Original PR description
replacing text-right with text-end in bs5 Before:  After:  Related EE: https://github.com/odoo/enterprise/pull/35498 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#109272
To reproduce the issue: 1. Ensure you have an orderpoint in automatic that will be processed by the scheduler 2. Allow a worker to run the scheduler with use_new_cursor=True 3. After orderpoints are searched in procurement.group._run_scheduler_tasks and before the orderpoint is processed in stock.warehouse.orderpoint._procure_orderpoint_confirm, delete the orderpoint through another worker Error: A CacheMiss error will be raised due to the access to orderpoint.qty_to_order in _pro
Original PR description
To reproduce the issue: 1. Ensure you have an orderpoint in automatic that will be processed by the scheduler 2. Allow a worker to run the scheduler with use_new_cursor=True 3. After orderpoints are searched in procurement.group._run_scheduler_tasks and before the orderpoint is processed in stock.warehouse.orderpoint._procure_orderpoint_confirm, delete the orderpoint through another worker Error: A CacheMiss error will be raised due to the access to orderpoint.qty_to_order in _procure_orderpoint_confirm, what will leave open the transaction from the new cursor declared in the same function. After a while HTTP workers will become unavailable as their own transactions will wait for the lock of the open transaction to be lifted, what won't happen before said transaction is closed. OPW-3121598 Forward-Port-Of: odoo/odoo#110543 Forward-Port-Of: odoo/odoo#109251
[FIX] purchase_stock: stock valuation foreign currency Journal Entry Steps to reproduce: - Setup product ( cost 10$ Storeable Product Standard Price Accounting automated valuation add account for price difference ) - Purchase product in foreign currency (set a different price) - Receive the product - Create and validate Bill Bug: The reception JE is for the cost amount set on the product ($10) debit and credit value are correct but the amount in currency
Original PR description
[FIX] purchase_stock: stock valuation foreign currency Journal Entry
Steps to reproduce:
- Setup product (
cost 10$
Storeable Product
Standard Price Accounting
automated valuation
add account for price difference
)
- Purchase product in foreign currency (set a different price)
- Receive the product
- Create and validate Bill
Bug:
The reception JE is for the cost amount set on the product ($10)
debit and credit value are correct but the amount in currency
is wrong (purchase cost)
After creating the bill the Journal items are not correctly matched
since reconciliation is done on currency amount in the case fo foreign
currency transaction
Fix:
Set the correct amount (cost configured on product page)
in currency amount if costing method is standard
opw-2822366
opw-2892637
Forward-Port-Of: odoo/odoo#106954
Forward-Port-Of: odoo/odoo#101809This commit fixes the view switcher display for views using the legacy control_panel (e.g. the activity view). To fix this behavior, we use the `usePosition` hook like in the Dropdown component. Note: As this bug only occurs in legacy views and they won't be present in next release, there is no test (also it's an edge case and not a blocking bug). Steps to reproduce: 1. Open Project on small screen device like a smartphone 2. Open a Project like 'Office Design' 3. Switch to the Ac
Original PR description
This commit fixes the view switcher display for views using the legacy control_panel (e.g. the activity view). To fix this behavior, we use the `usePosition` hook like in the Dropdown component. Note: As this bug only occurs in legacy views and they won't be present in next release, there is no test (also it's an edge case and not a blocking bug). Steps to reproduce: 1. Open Project on small screen device like a smartphone 2. Open a Project like 'Office Design' 3. Switch to the Activity view and try to switch the view again => a part of the dropdown menu is displayed outside the screen => bug Forward-Port-Of: odoo/enterprise#36056
replacing text-left with text-start and text-right with text-end in bs5 Forward-Port-Of: odoo/enterprise#35498
Original PR description
replacing text-left with text-start and text-right with text-end in bs5 Forward-Port-Of: odoo/enterprise#35498
When creating an invoice with a customer which country isn't Mexico, the CFDI validation fails with error : "La clave del campo RegimenFiscalR debe corresponder con el tipo de persona (física o moral).". Indeed, the documentation states that when the RFC is 'XEXX010101000', the fiscal regime should be '616'. In 16.0, a default value (601) for the fiscal regime has been added (see https://github.com/odoo/enterprise/commit/8e65041f99f4e687887bd57d59860b76f138052f). As a consequence, since the
Original PR description
When creating an invoice with a customer which country isn't Mexico, the CFDI validation fails with error : "La clave del campo RegimenFiscalR debe corresponder con el tipo de persona (física o moral).". Indeed, the documentation states that when the RFC is 'XEXX010101000', the fiscal regime should be '616'. In 16.0, a default value (601) for the fiscal regime has been added (see https://github.com/odoo/enterprise/commit/8e65041f99f4e687887bd57d59860b76f138052f). As a consequence, since the fiscal regime is not falsy, the `_l10n_mx_edi_get_40_values` doesn't reassign the fiscal regime as 616 when the country is different from Mexico, and the CFDI validation fails. To fix the issue, we allow to reassign the fiscal regime even if it is already set. Forward-Port-Of: odoo/enterprise#35977
Most currency providers were using today's date for the retrieved currency rates. This might cause some issues as the providers often update the rate late in the afternoon. After this PR: The date used is the one specified in the endpoint response where available The following rate dates apply for the providers FTA: The first validity date in endpoint response (typically last provider update date + 1 day) ECB: date in endpoint response (unchanged) CBUAE: date in endpoint response [also
Original PR description
Most currency providers were using today's date for the retrieved currency rates. This might cause some issues as the providers often update the rate late in the afternoon. After this PR: The date used is the one specified in the endpoint response where available The following rate dates apply for the providers FTA: The first validity date in endpoint response (typically last provider update date + 1 day) ECB: date in endpoint response (unchanged) CBUAE: date in endpoint response [also change to english API and added missing currencies] CBEGY: date in endpoint response BOC: date in endpoint response Banxico: date in endpoint response (unchanged) XE.com: date in endpoint response BNR: date in endpoint + 1 day (unchanged) BCRP: date in endpoint response (unchanged) Mindicador: date in endpoint (unchanged) NBP: date in endpoint response + 1 day (unchanged) Task-3132935 Forward-Port-Of: odoo/enterprise#36028 Forward-Port-Of: odoo/enterprise#35794
Since 972c32d0bbf0725c23b62ba3d51d2e9af842fd96, when testing with --no-database-list, the test test_database_list still ends up in the wrong condition, regardless of the patches applied in the test. Since it makes no sense to test a multi db setup when --no-database-list is added, we simply skip it. Forward-Port-Of: odoo/enterprise#35972
Original PR description
Since 972c32d0bbf0725c23b62ba3d51d2e9af842fd96, when testing with --no-database-list, the test test_database_list still ends up in the wrong condition, regardless of the patches applied in the test. Since it makes no sense to test a multi db setup when --no-database-list is added, we simply skip it. Forward-Port-Of: odoo/enterprise#35972
In German localization for Fiskaly, length of the field buyer should not be more than 50 characters. It has previously been forced in the template, however if this field has special characters that are escaped, some extra characters are added for formatting; sometimes causing it to go over the limit and give an error. This commit fixes the issue by slicing the escaped string to make sure it is not more than 50 characters in length. opw-3125592 Forward-Port-Of: odoo/enterprise#35961
Original PR description
In German localization for Fiskaly, length of the field buyer should not be more than 50 characters. It has previously been forced in the template, however if this field has special characters that are escaped, some extra characters are added for formatting; sometimes causing it to go over the limit and give an error. This commit fixes the issue by slicing the escaped string to make sure it is not more than 50 characters in length. opw-3125592 Forward-Port-Of: odoo/enterprise#35961
Before this commit, the width of the appraisal templates on the department view form were narrow. After this commit, both the employee and manager templates take the full dedicated width task-3133181 Forward-Port-Of: odoo/enterprise#35772
Original PR description
Before this commit, the width of the appraisal templates on the department view form were narrow. After this commit, both the employee and manager templates take the full dedicated width task-3133181 Forward-Port-Of: odoo/enterprise#35772
Steps: - Go to CRM for example and select any record - Open studio in the form view - Add an approval rule on the `won` button with `admin` user - Close studio - Try to click on the `won` button with `demo` user - Approval is working - Try now with `admin` user to add a rule condition (for example `('display_name', 'is', 'Private')`) - Try again with `demo` - Approval is not working since the rule condition addition, even if the `display_name` is `Private` Before th
Original PR description
Steps: - Go to CRM for example and select any record - Open studio in the form view - Add an approval rule on the `won` button with `admin` user - Close studio - Try to click on the `won` button with…
Steps:
- Go to CRM for example and select any record
- Open studio in the form view
- Add an approval rule on the `won` button with `admin` user
- Close studio
- Try to click on the `won` button with `demo` user
- Approval is working
- Try now with `admin` user to add a rule condition (for example `('display_name', 'is', 'Private')`)
- Try again with `demo`
- Approval is not working since the rule condition addition, even if the `display_name` is `Private`
Before this fix, approvals were updated like this
```js
patch(ViewButton.prototype, "web_studio.ViewButtonApproval", {
setup() {
this._super(...arguments);
if (this.props.studioApproval) {
//...
useApproval({})
//...
}
}
})
```
But overriding setup method is not enough since it will not be updated if we change records via the pager buttons, nor in the case of a new record.
Using `owl.onWIllUpdateProps` we can detect the change of record ids and update the props in order to always be on the right record`.
opw-3098478
Forward-Port-Of: odoo/enterprise#35760Currently, there are three transitive many2one relationships between records in `consolidation.journal.line` and `consolidation.chart`: 1) `journal_id.chart_id` 2) `journal_id.period_id.chart_id` 3) `period_id.chart_id` The first chain restricts deletions of `consolidation.chart` records whenever there are still associated journal lines. However, the second chain triggers cascading deletions of the associated journal lines, and the third chain triggers a set null on the `period_id` field
Original PR description
Currently, there are three transitive many2one relationships between records in `consolidation.journal.line` and `consolidation.chart`: 1) `journal_id.chart_id` 2) `journal_id.period_id.chart_id` 3)…
Currently, there are three transitive many2one relationships between records in `consolidation.journal.line` and `consolidation.chart`: 1) `journal_id.chart_id` 2) `journal_id.period_id.chart_id` 3) `period_id.chart_id` The first chain restricts deletions of `consolidation.chart` records whenever there are still associated journal lines. However, the second chain triggers cascading deletions of the associated journal lines, and the third chain triggers a set null on the `period_id` field of the journal lines (while the associated `consolidation.period` records are cascade deleted). Indeed, the `period_id` in the third chain is a related field, but since it is stored it also has an associated `ondelete` trigger. Since all three chains specify a different behavior, the overall behavior is undefined, or at the very least highly unclear (I couldn't find any postgres specific docs on the question, while some other rdbms will use the first trigger). This commit resolves the problem by specifying matching cascading `ondelete` triggers for all three chains. Note: This postgres [thread] discusses the problem at hand. [thread]: https://postgrespro.com/list/thread-id/1209744 Forward-Port-Of: odoo/enterprise#32401