Monday, April 17, 2023
75 changes · master
Enhancements to existing features
This change updates Odoo's command-line helper so it generates a current TypeScript configuration file. It keeps developer tooling aligned with the latest web tooling setup, reducing maintenance issues and improving consistency behind the scenes.
Original PR description
tsconfig generate an outdate file. This PR update the file according to web/tooling/_jsconfig.json.
This update brings Odoo's spreadsheet component up to a newer version with improvements to menus, icons, sizing, and read-only behavior. It also fixes issues that could affect spreadsheet display and interaction, making reports and dashboards more reliable for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6824b8a1 [REL] 16.3.0-alpha.4 https://github.com/odoo/o-spreadsheet/commit/9b911f61 [FIX] tests: fix indeterministic…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6824b8a1 [REL] 16.3.0-alpha.4 https://github.com/odoo/o-spreadsheet/commit/9b911f61 [FIX] tests: fix indeterministic ui sheet https://github.com/odoo/o-spreadsheet/commit/f20b7be5 [FIX] demo: Align font family with Odoo Task: 3269724 https://github.com/odoo/o-spreadsheet/commit/49a5ee0e [FIX] ColorPicker: Fix checkmark symbol Task: 3269724 https://github.com/odoo/o-spreadsheet/commit/4f2ecfec [REM] menu: remove icons on menu items https://github.com/odoo/o-spreadsheet/commit/54fca81f [REF] *: rename 'menuItem' files to 'action' files https://github.com/odoo/o-spreadsheet/commit/5c23e084 [REF] *: Change names of type 'MenuItem' to 'Action' https://github.com/odoo/o-spreadsheet/commit/e5007fd1 [REF] replace xml tool bar in the xml top bar by menu item buttons https://github.com/odoo/o-spreadsheet/commit/950abc45 [REF] menu registry: factorize menu registries by menu items https://github.com/odoo/o-spreadsheet/commit/c02a7e96 [IMP] topbar menu: add icons for conditional menu items https://github.com/odoo/o-spreadsheet/commit/a19d9cac [IMP] topbar menu: add icons for static menu items https://github.com/odoo/o-spreadsheet/commit/7825124c [IMP] menu: replace right text icon by left icon https://github.com/odoo/o-spreadsheet/commit/be3c3d6f [FIX] viewport: infinite loop with hidden headers https://github.com/odoo/o-spreadsheet/commit/c05be1de [FIX] github: update release-action to latest version https://github.com/odoo/o-spreadsheet/commit/9fdbdab2 [FIX] sheetview: correctly auto-size spreadsheet https://github.com/odoo/o-spreadsheet/commit/7d18b589 [IMP] bottom_bar: hide add sheet button in readonly mode https://github.com/odoo/o-spreadsheet/commit/108b89bd [FIX] menus: don't open submenu is not readonly https://github.com/odoo/o-spreadsheet/commit/1edbc157 [FIX] top bar: remove useless "Save" menu item
Odoo now identifies and stores tax-related XSD files more reliably, reducing the risk that files with the same name are mixed up. It also avoids saving unnecessary ZIP archives and adds a manual download option instead of relying on scheduled downloads, making the process cleaner and more controlled.
Original PR description
WIP Currently, saving/fetching XSD attachments is only based on the attachment's name. This means that multiple attachments can share the same name, leading to possible collision. This commit aims at improving the whole process of fetching XSD attachments from DB by: (1) reducing the collision chance (2) handling the case when collision still happens (3) simplifying/generalizing the use of the load_xsd_files_from_url function, which allows: (4) not saving ZIP archives, only saving required XSD files inside These improvements are implemented as follows: (1) fetch based on XSD name, url and type, and enforce a prefix to all file names (2) return only one attachment when multiple match the description (the most recently updated one) (3) rewrite function definition and use a dictionary to provide needed information (4) do just that [Enterprise PR](https://github.com/odoo/enterprise/pull/35456) task id=3010716
The HR Contracts area now includes a dedicated menu for working times. This makes it easier for HR users to find and manage employee work schedule information from the contract workflow.
Original PR description
task: 3254679
The module uninstall wizard now lists documents to delete by the number of records in each model instead of alphabetically. This helps users quickly see where the largest amount of data will be affected before confirming an uninstall.
Original PR description
before this commit, when uninstalling a module, in the "Documents to Delete" field in the uninstall wizard shows the models sorted by the name. after this commit, the models will be sorted based on the number of records in the table. Before:  After:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet dashboard period filters now count the current day in ranges such as "Last 7 Days." This makes dashboard results match business expectations by including today's activity instead of ending at yesterday.
Original PR description
### Description of the issue/feature this PR addresses: This PR includes the ongoing day in the current period filters. ### Current behavior before PR: The periods in dashboard period filters don't include the ongoing day (today). For example, today is May 16th. "Last 7 Days" means May 9th 00:00 - May 15th 23:59. ### Desired behavior after PR is merged: "Last 7 Days" of May 16th refers to May 10th 00:00 - May 16th 23:59. task [3267525](https://www.odoo.com/web#id=3267525&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product searches were adjusted to avoid an expensive translated-name sort when retrieving products. This can make product lists and related operations load much faster, especially in databases using multiple languages.
Original PR description
1. Install and configure a language 2. Run the following sentence: `env['product.product'].search([], limit=10)` 3. Analyze the query executed: ```sql SELECT "product_product".id FROM…
1. Install and configure a language
2. Run the following sentence: `env['product.product'].search([], limit=10)`
3. Analyze the query executed:
```sql
SELECT "product_product".id
FROM "product_product"
LEFT JOIN "product_template" AS "product_product__product_tmpl_id"
ON ( "product_product"."product_tmpl_id" =
"product_product__product_tmpl_id"."id" )
LEFT JOIN (SELECT res_id,
value
FROM "ir_translation"
WHERE type = 'model'
AND name = 'product.template,name'
AND lang = 'es_MX'
AND value != '') AS
"product_product__product_tmpl_id__name"
ON ( "product_product__product_tmpl_id"."id" =
"product_product__product_tmpl_id__name"."res_id" )
WHERE ( "product_product"."active" = true )
ORDER BY "product_product"."default_code",
Coalesce("product_product__product_tmpl_id__name"."value",
"product_product__product_tmpl_id"."name"),
"product_product"."id"
LIMIT 10
```
Planning Time: 1.088 ms
Execution Time: 1027.282 ms
Total Time: 1028.37 ms
It is so slow.
Now, change the `_order = 'default_code'`
Analyze the query executed:
```sql
SELECT "product_product".id
FROM "product_product"
WHERE ( "product_product"."active" = true )
ORDER BY "product_product"."default_code"
LIMIT 10
```
Planning Time: 0.095 ms
Execution Time: 0.529 ms
Total Time: 0.624 ms
It is 1.65k times faster
It is because the field `name` has the parameter `translate=True`
So, It will process the original value to translate it
And it has `_order = 'default_code, name'`
Then, It will order by a column computed on-the-fly
of another table (product.template)
An inner join is required and an order by a non-index column
So, it is so slow.
But the first order is default_code, so most of cases the result
will be same than without use "name" column
# Additional information
Opening `/shop` page of our customer before this patch:
- 7.5s
After this patch:
- 1.2sThe e-invoicing proxy setup has been made less dependent on the older EDI format structure, making it more flexible for future services such as Peppol. Italian e-invoicing keeps the format-specific behavior it still needs today, while the shared proxy layer can now manage users more cleanly per company and mode.
Original PR description
Edi format is going to be removed eventually - `account_edi_proxy_client` should not depend on it and be more flexible in general. This commit: - Removes edi_format field from `account_edi_proxy_client.user` model. We still have to add them in `l10n_it_edi` as it still heavily relies on edi format for now. - Adds a way to have a unique edi user per company, proxy user, edi mode combination. This is a necessary step before adding peppol, which will also depend on the account_edi_proxy_client also see: https://github.com/odoo/iap-apps/pull/580 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Archived mail channels now show a clear banner in detailed and kanban views, helping users quickly recognize channels that are no longer active. The kanban layout also adjusts description space so the archived status remains visible without disrupting the view.
Original PR description
This PR adds a banner on archived channels in detailed view Task-2494469
This update renames an internal mail update function and removes unused code in the messaging area. It helps keep the codebase cleaner and easier to maintain, with no expected change to day-to-day user workflows.
This update changes how electronic reporting validation files are downloaded and found, reducing the chance of using the wrong file. Scheduled automatic downloads are replaced or limited in favor of a manual download option, while missing validation files no longer block XML processing.
Original PR description
WIP This commit follows the commit in community that improves/modifies XSD loading functions. The overall goal is to reduce the collision chance when fetch XSD attachments from DB. The modified functions require stricter parameters to be provided, and this commit implements the required modifications. Also removes the CRON and adds a button that does the same job (i.e. downloads the XSD files). If an XSD file is missing when trying to validate an XML, then the validation is simply skipped. XSD validation should mainly be done during the development process, so we avoid doing it all the time and leave the possibility to the user to still download the XSD files, which will then enable the validation. [Community PR](https://github.com/odoo/odoo/pull/109160) task id=3010716
The spreadsheet components have been updated to a newer library version, bringing improvements across documents, dashboards, lists, pivots, filters, and menus. This helps keep spreadsheet-based workflows more reliable and aligned with the latest capabilities used across Odoo.
Original PR description
…alpha.4
Project and field service task views now show a row for relevant users even when they have no task in the current view. This helps managers spot available team members who recently had planned work or still have open tasks in the selected project.
Original PR description
Display an empty line for each user that: \- has an open task assigned in the project (only applicable when viewing the tasks of a specific project) \- was planned a task in the past 7 days task-3142165
Products can no longer be linked to a workspace template that belongs to a different company. This helps avoid cross-company setup mistakes that could cause document or project workflows to behave incorrectly.
Original PR description
This PR adds a check preventing setting a different company on a product and its workspace template, thus avoiding potential multi-company issues. Task-3186695
Resolved issues and error corrections
The journal settings page no longer shows an empty Electronic Data Interchange section when it is not relevant. This reduces confusion for users by only displaying EDI options when compatible electronic invoicing features are available.
Original PR description
Section "Electronic Data Interchange" should not be displayed for account_edi_ubl_cii since it's empty. In addition, only display the section in account_edi if some EDI are compatibles. related-https://github.com/odoo/upgrade/pull/4525 see also: https://github.com/odoo/odoo/pull/116070
Code cleanup and technical improvements
This update removes outdated and unused styling rules from the Knowledge app after recent widget updates and Bootstrap 5 adoption. It should make the interface code easier to maintain without changing day-to-day user workflows.
Original PR description
Now that the widgets have been reworked and migrated to owl and now that we use Bootstrap 5, many css rules of Knowledge become outdated, unused or unnecessary over time. Changes and justifications:…
Now that the widgets have been reworked and migrated to owl and now that we use Bootstrap 5, many css rules of Knowledge become outdated, unused or unnecessary over time. Changes and justifications: - Since the first release of Knowledge, the `CopyClipboardChar` widget has been updated. The css adjustments we made are now no longer necessary. We can therefore remove them. - There are some leftover from the old emoji picker of Odoo. The related rules no longer apply to any element and can therefore be removed. - Some css rules like `user-select: none`, etc can be replaced with their inline bootstrap class counterpart (i.e: `user-select-none`). - Bootstrap already defines classes like `min-w-0`. There is therefore no need to re-define them in the Knowledge module. - There are some minor css adjustments for the property that are scoped to the editor container. As the property fields are not placed in that container, the rules do not apply and can be removed. - Some css adjustments for the embedded view will be moved to the dedicated file. task-3210683
Miscellaneous changes
*: mass_mailing, website_blog, website_event, website_mail_group, website_mass_mailing, website_payment, website_sale, website_twitter The names of snippet blocks are not translatable because their name is obtained from a their template name which is not a translatable item. For markets that use a non-latin alphabet this is a no go. This commit makes it possible to specify a `string` attribute in the `t-snippet` blocks that makes their name inventoried by the translation process.
The online presence indicator now uses the expected green color in Odoo Community, matching Enterprise and dark theme behavior. This fixes a small visual inconsistency so users can more easily recognize when someone is online.
Original PR description
Before this commit, im status in community was blue instead of green. This commit makes im status green in all version, as it should. Before/after (community)   Before/after (enterprise)   Before/after (dark theme)  
Point of Sale customer search now checks email addresses as well as names when limited customer loading is enabled. This helps cashiers find the right customer more reliably, matching the search behavior used in the backend contacts area.
Original PR description
Before this commit: if the limited partner load option was enabled, when a user tried to load a user by searching, it would only search based on the name. In several cases, it's necessary to search based on the email like when you are searching in the contact in the backend. The solution is to add other fields to the domain of search. opw-2952814 X-original-commit: dba0eca41f2922a9054c5c926b24d7f570382bd7 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
New draft records now consistently round decimal values before they are used in automatic calculations. This helps prevent small pricing or quantity discrepancies when sales order lines and other records are prepared before being saved.
Original PR description
When new records are used to precompute some fields, the computations are expected to use the "right" values for floats, in particular float fields are expected to be rounded.
This fixes the visual border around the message composer when editing an existing message. The change makes the editing area look consistent and easier to distinguish, improving clarity for users working with messages.
Original PR description
Before/after  
Spreadsheet document tests were adjusted to match the latest period filter behavior, including the current day. This helps keep automated checks reliable so future changes can be delivered with confidence.
Original PR description
This PR fixes the failed tests after the changes of period filters (including the ongoing day). task [3267525](https://www.odoo.com/web#id=3267525&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Spreadsheet JSON downloads now use the correct file name. This helps users identify exported files more easily and avoids confusion when saving or sharing them.
Odoo Studio now works correctly when users edit forms inside nested related lists. This prevents a crash and lets users navigate breadcrumbs, add fields, and make edits in deeply nested form views as expected.
Original PR description
In studio, navigate through a first x2many, then through a second. The breadcrumb should now display: Form > SubView Form > SubView Form Before this commit, there was a crash as the subview's xpath was not correctly computed. After this commit, it works as expected, one can add a field, or edit in general, the nested x2many.
Original PR description
*: mass_mailing, website_blog, website_event, website_mail_group, website_mass_mailing, website_payment, website_sale, website_twitter The names of snippet blocks are not translatable because their name is obtained from a their template name which is not a translatable item. For markets that use a non-latin alphabet this is a no go. This commit makes it possible to specify a `string` attribute in the `t-snippet` blocks that makes their name inventoried by the translation process. Forward-Port-Of: odoo/odoo#118467 Forward-Port-Of: odoo/odoo#117098
backport-of: https://github.com/odoo/odoo/commit/745d67cfa864d85ae5a19d5f890d8b5e1f414181 Since [1], [2], [3] and [4], the field API was simplified and specified. Some props were removed (update, type, setDirty and value) and some were now mandatory (record and name). This specification make it difficult to use the fields as a "normal" component (without a record). This was the case with MrpTimer, that was used as a field, but also as a component. To solve this issue, in this commit, we divi
Original PR description
backport-of: https://github.com/odoo/odoo/commit/745d67cfa864d85ae5a19d5f890d8b5e1f414181 Since [1], [2], [3] and [4], the field API was simplified and specified. Some props were removed (update,…
backport-of: https://github.com/odoo/odoo/commit/745d67cfa864d85ae5a19d5f890d8b5e1f414181 Since [1], [2], [3] and [4], the field API was simplified and specified. Some props were removed (update, type, setDirty and value) and some were now mandatory (record and name). This specification make it difficult to use the fields as a "normal" component (without a record). This was the case with MrpTimer, that was used as a field, but also as a component. To solve this issue, in this commit, we divide it in two different components, MrpTimer and MrpTimerField. [1]: https://github.com/odoo/odoo/commit/aed1ba484d0c48a59e166ef01e69967bd618a562 [2]: https://github.com/odoo/odoo/commit/8cde3e84bb70a2bd097921c08c0059bf65bee602 [3]: https://github.com/odoo/odoo/commit/688986f888f2fe2371d58b74ded81315ba6bb353 [4]: https://github.com/odoo/odoo/commit/91303252f413325859a6f1651d056593a8cf6382 closes odoo/odoo#114761 Related: odoo/enterprise#37960 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#116170
Error:'UniqueViolation duplicate key value violates unique constraint account_journal_code_company_uniq.' When we install the 'point_of_sale' module it tries to create account journals with existing id's due to which we face the above error. see - https://tinyurl.com/2d3yk9hj This commit removes the portion of code that creates the account journal with already existing id's. sentry - 4062359900 Forward-Port-Of: odoo/odoo#118031
Original PR description
Error:'UniqueViolation duplicate key value violates unique constraint account_journal_code_company_uniq.' When we install the 'point_of_sale' module it tries to create account journals with existing id's due to which we face the above error. see - https://tinyurl.com/2d3yk9hj This commit removes the portion of code that creates the account journal with already existing id's. sentry - 4062359900 Forward-Port-Of: odoo/odoo#118031
This issue occurs when the user changes the Journal 'journal_id' in this 'report.pos.order' model then traceback will be generated. Stack Trace:-  Step to Produce:- - In POS, Click on Reporting Menu > Order. - Click on graph > Open any One record. - Try To Change the Journal('journal_id'). - Trace-back will be generated. sentry:- 3929247828 --- I confirm I have signed
Original PR description
This issue occurs when the user changes the Journal 'journal_id' in this 'report.pos.order' model then traceback will be generated.
Stack Trace:-
Step to Produce:-
- In POS, Click on Reporting Menu > Order.
- Click on graph > Open any One record.
- Try To Change the Journal('journal_id').
- Trace-back will be generated.
sentry:- 3929247828
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#118582from april 3, the transifex has changed domain from www.transifex.com to app.transifex.com after this commit, the transifex project url in the system parameter will be updated to the new domain  Forward-Port-Of: odoo/odoo#118574
Original PR description
from april 3, the transifex has changed domain from www.transifex.com to app.transifex.com after this commit, the transifex project url in the system parameter will be updated to the new domain  Forward-Port-Of: odoo/odoo#118574
Install only the “purchase” module and run the test, it’ll always fail since the product type is added in the stock module Bug introduced in: https://github.com/odoo/odoo/pull/117956 **Solution:** Use the consumable type instead Forward-Port-Of: odoo/odoo#118598
Original PR description
Install only the “purchase” module and run the test, it’ll always fail since the product type is added in the stock module Bug introduced in: https://github.com/odoo/odoo/pull/117956 **Solution:** Use the consumable type instead Forward-Port-Of: odoo/odoo#118598
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#116294
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#116294
Align images to the right by using an auto left margin. Steps to reproduce: - Drop a "Columns" block. - Select an image. - Resize image to 50%. - Align image to the right. => Image did not get aligned to the right. This PR also makes it possible for icons to be aligned. task-2841127 Forward-Port-Of: odoo/odoo#118657 Forward-Port-Of: odoo/odoo#90410
Original PR description
Align images to the right by using an auto left margin. Steps to reproduce: - Drop a "Columns" block. - Select an image. - Resize image to 50%. - Align image to the right. => Image did not get aligned to the right. This PR also makes it possible for icons to be aligned. task-2841127 Forward-Port-Of: odoo/odoo#118657 Forward-Port-Of: odoo/odoo#90410
This commit is a small fix to avoid reloading several form views (like crm leads or helpdesk tickets) when a message is posted in the chatter. This is linked to an old issue where relational fields like the tags do not keep changes properly in the base model, therefore dropping these changes on reload in this case. Do note that it will still reload (and keep the bug) when a recipient is linked to the message and perform the initial purpose of the reload (like updating the customer field) as it w
Original PR description
This commit is a small fix to avoid reloading several form views (like crm leads or helpdesk tickets) when a message is posted in the chatter. This is linked to an old issue where relational fields like the tags do not keep changes properly in the base model, therefore dropping these changes on reload in this case. Do note that it will still reload (and keep the bug) when a recipient is linked to the message and perform the initial purpose of the reload (like updating the customer field) as it was done before. To reproduce: go to crm and open a lead in form view, add or remove tags, post a message and see if the changes on the tags are reverted or not. opw-3245717 Forward-Port-Of: odoo/odoo#117500
Before this commit when choosing the program rule type "Buy X get Y" an error occured: after adding rewards and trying to save the record the rewards were being resetted to the default value for program rules of type "discount". This ocurred because the program type was not being sent to the `default_get` method of the `loyalty.reward` record. After this commit rewards are correctly preserved. opw - 3240558 --- I confirm I have signed the CLA and read the PR guidelines at www.odo
Original PR description
Before this commit when choosing the program rule type "Buy X get Y" an error occured: after adding rewards and trying to save the record the rewards were being resetted to the default value for program rules of type "discount". This ocurred because the program type was not being sent to the `default_get` method of the `loyalty.reward` record. After this commit rewards are correctly preserved. opw - 3240558 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#116244
If applied, this commit will solve the external id issue of the base admin user. Before this commit: ========================== When we delete the admin user (base.admin_user) and try to login with a new user or try to write in a new user, this error will come. After this commit: =========================== The issue will be resolved after this commit and authorize new users without any errors. sentry - 3973828005 see - https://tinyurl.com/2jm772jm Forward-Port-Of: odoo/odoo#11825
Original PR description
If applied, this commit will solve the external id issue of the base admin user. Before this commit: ========================== When we delete the admin user (base.admin_user) and try to login with a new user or try to write in a new user, this error will come. After this commit: =========================== The issue will be resolved after this commit and authorize new users without any errors. sentry - 3973828005 see - https://tinyurl.com/2jm772jm Forward-Port-Of: odoo/odoo#118259 Forward-Port-Of: odoo/odoo#115527
## Issues - `error_msg` is not set when the template cannot find any record to use as example (16.2) - `resource_ref` is only initialized in default_get. If the preview generates a report, the commit from that action invalidates the cache and that value disappears. (14.0, real issue since 16.2 as it was previously handled another way) - html data using empty nodes `<t></t>` are incorrectly converted to 'self-closing' tags `<t/>` which becomes <t> thanks to standard html parsing. (14.0, real
Original PR description
## Issues - `error_msg` is not set when the template cannot find any record to use as example (16.2) - `resource_ref` is only initialized in default_get. If the preview generates a report, the commit…
## Issues - `error_msg` is not set when the template cannot find any record to use as example (16.2) - `resource_ref` is only initialized in default_get. If the preview generates a report, the commit from that action invalidates the cache and that value disappears. (14.0, real issue since 16.2 as it was previously handled another way) - html data using empty nodes `<t></t>` are incorrectly converted to 'self-closing' tags `<t/>` which becomes <t> thanks to standard html parsing. (14.0, real issue in 16.0 then 16.2)* This last one was not an issue because jquery used to fix these invalid tags for us, until a recent update here: 9c41ee5091ac06ac3ca71aeac607195c70061e4a ## Fixes - Simply add a default value and set that at the end of the compute method - make resource_ref a write-able computed field to keep the same functionality while allowing the ORM to recompute it - use the `method` argument of `lxml.etree.tostring` to tell lxml to print the content of the nodes as valid HTML in the data converter See sub commits for more details. Task-3162320 Forward-Port-Of: odoo/odoo#114632
Since odoo/odoo@04e972660b3f38c8dfa42111b1fe88adbcff4699 The session `modified` flag has been renamed `is_dirty`. However, it has not been renamed correctly in these three different places. The goal to set `modified` at this three places is to force the session to be saved, for instance because a mutable (a list or a dict) contained in the session was modified, but not the dict of the session itself, therefore `modified` is not flagged automatically. As the flag `modified` has not
Original PR description
Since odoo/odoo@04e972660b3f38c8dfa42111b1fe88adbcff4699 The session `modified` flag has been renamed `is_dirty`. However, it has not been renamed correctly in these three different places. The goal to set `modified` at this three places is to force the session to be saved, for instance because a mutable (a list or a dict) contained in the session was modified, but not the dict of the session itself, therefore `modified` is not flagged automatically. As the flag `modified` has not been renamed to `is_dirty`, a key/value `modified: True` was actually assigned to the session dict, and saved in file. The behavior to save the session in these three places was kept, as one key/value of the session has been changed, but by the way to assign a new value in the session file, which is not ideal. It's better to assign the correct flag to avoid setting a new key/value in the session for no reason. Forward-Port-Of: odoo/odoo#118321
Step to reproduce : - create a service product with 'create project & task' - set the invoice policy on either 'invoice on TS', 'invoice on milestone', 'prepaid' - create a new SO with the product and confirm. - update the price of the sol (e.a. from 10 to 20) - go to project_updates The project profitability panel is still showing 10 instead of the updated price of 20 After this fix, the project profitability is correctly showing 20 task-3236240 Description of the issue/feature
Original PR description
Step to reproduce : - create a service product with 'create project & task' - set the invoice policy on either 'invoice on TS', 'invoice on milestone', 'prepaid' - create a new SO with the product and confirm. - update the price of the sol (e.a. from 10 to 20) - go to project_updates The project profitability panel is still showing 10 instead of the updated price of 20 After this fix, the project profitability is correctly showing 20 task-3236240 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#115814
Steps to reproduce ================== - Register two events listener on the same target - Unregister them Only the first one is unregistered Cause of the issue ================== `cbs` is used instead of `listeners`. This means that after any `.off` call, the target is removed from the Map and it is not possible anymore to unregister any events for it Forward-Port-Of: odoo/odoo#118218
Original PR description
Steps to reproduce ================== - Register two events listener on the same target - Unregister them Only the first one is unregistered Cause of the issue ================== `cbs` is used instead of `listeners`. This means that after any `.off` call, the target is removed from the Map and it is not possible anymore to unregister any events for it Forward-Port-Of: odoo/odoo#118218
## Current behaviour When duplicating a project, new milestones are copied for the new project, but none of them are assigned to the copied tasks like in the original project. ## Expected behaviour The new tasks in the new project should have the corresponding copy of the milestone that were assigned in the original project. ## Steps to reproduce - Install Project - Duplicate "Office Design" (it has milestones) - Observe that the tasks in the new project don't have milestones assigned
Original PR description
## Current behaviour When duplicating a project, new milestones are copied for the new project, but none of them are assigned to the copied tasks like in the original project. ## Expected behaviour…
## Current behaviour When duplicating a project, new milestones are copied for the new project, but none of them are assigned to the copied tasks like in the original project. ## Expected behaviour The new tasks in the new project should have the corresponding copy of the milestone that were assigned in the original project. ## Steps to reproduce - Install Project - Duplicate "Office Design" (it has milestones) - Observe that the tasks in the new project don't have milestones assigned to them, like in the original project. ## Reason for the problem When we copy the tasks, they have the milestones of the original project correctly assigned to them, but since the project of the milestone is different from the project of the task (former references the original project, while the latter references the copied project), so in `_compute_milestone_id`, the milestone of the task is set to False. ## Fix Remove `copy=True` from `milestone_ids` on the project, and copy the milestone by hand. This allows us to use an overwrite of `copy()` for `project.milestone`, and we create a mapping between the old milestones and the new ones in the context, similar to how we did with `task_mapping`. With this we can assign the newly created milestones on the copied tasks correctly (while preserving the mapping like in the original project). ## Affected versions - 16.0 - saas-16.1 - saas-16.2 - master --- opw-3254868 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118318
To reproduce the issue: 1. In Settings, enable: - Multi-Step Routes - Storage Categories - Packages 2. Create a Storage Category SC: - Allow New Product: same - Max Weight: 100 kg - Capacity by Package: - 2 x Pallet 3. Create two locations L1, L2: - Parent: WH/Stock - Type: Internal - Storage Category: SC 4. Create a putaway rule: - When in: WH/Stock - Package type: Pallet - Store to: WH/Stock - Having Category: SC 5. Edit the wareho
Original PR description
To reproduce the issue: 1. In Settings, enable: - Multi-Step Routes - Storage Categories - Packages 2. Create a Storage Category SC: - Allow New Product: same - Max Weight: 100 kg - Capacity by…
To reproduce the issue:
1. In Settings, enable:
- Multi-Step Routes
- Storage Categories
- Packages
2. Create a Storage Category SC:
- Allow New Product: same
- Max Weight: 100 kg
- Capacity by Package:
- 2 x Pallet
3. Create two locations L1, L2:
- Parent: WH/Stock
- Type: Internal
- Storage Category: SC
4. Create a putaway rule:
- When in: WH/Stock
- Package type: Pallet
- Store to: WH/Stock
- Having Category: SC
5. Edit the warehouse:
- Incoming Shipments: 2 steps
6. Create a product P:
- Type: Storable
- Weight: 1 kg
7. Update L1:
- There is 1 x P in a pallet
8. Create a planned receipt R:
- To: WH/Input
- Operations:
- 2 x P
9. Mark R as Todo
10. Create two packages:
- 1 x P in PK01 (! PK01 must be a Pallet)
- 1 x P in PK02 (! PK02 must be a Pallet)
11. Validate R
12. Open the related internal transfer T
Error: Both packages are redirected to L2 but one of them should be
redirected to L1
When checking L1, we ensure that the policy 'all same products' is
respected. To do so, we compare the products of the quants of L1
with the given product. Here is the issue: when moving a package, we
don't provide any `product` value to the methods used in the putaway
rules process.
Note: There was also another issue with the 'all same products'
policy. Suppose L1 is empty, and we move a pallet with two different
products, the move line is redirected to L1, which breaks the 'all
same products' condition.
OPW-3204924
Forward-Port-Of: odoo/odoo#118508
Forward-Port-Of: odoo/odoo#118361After this commit https://github.com/odoo/odoo/commit/e534ab41e7b3b71a8286eba849fd4d70f4b27334 the `provider_sudo` has been refactored to `provider`. But in the `saas_payment_stripe`, it still uses `provider_sudo`. So it will cause an error in the saas databases. opw-3271034 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118641
Original PR description
After this commit https://github.com/odoo/odoo/commit/e534ab41e7b3b71a8286eba849fd4d70f4b27334 the `provider_sudo` has been refactored to `provider`. But in the `saas_payment_stripe`, it still uses `provider_sudo`. So it will cause an error in the saas databases. opw-3271034 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118641
Steps to reproduce ================== - With the Chrome devtools, add a network delay of 1 second - Go to Purchase - Create RFQ - Add vendor - Add products and navigate by using the 'TAB' key - Add another product line - Repeat process quickly `this.list.editedRecord is null` Cause of the issue ================== Order of events: - First tab pressed - onchange_1 triggered - Second tab pressed - onchange_2 triggered - onchange_1 resolves - The editedRecord is switched
Original PR description
Steps to reproduce ================== - With the Chrome devtools, add a network delay of 1 second - Go to Purchase - Create RFQ - Add vendor - Add products and navigate by using the 'TAB' key - Add another product line - Repeat process quickly `this.list.editedRecord is null` Cause of the issue ================== Order of events: - First tab pressed - onchange_1 triggered - Second tab pressed - onchange_2 triggered - onchange_1 resolves - The editedRecord is switched to readonly - onchange_2 resolves - There is no more editedRecord opw-3115650 Forward-Port-Of: odoo/odoo#117938
The current profiler will add default value in the user session using disk space without valid reason. This commit makes those parameters optional in the session. Forward-Port-Of: odoo/odoo#118295
Original PR description
The current profiler will add default value in the user session using disk space without valid reason. This commit makes those parameters optional in the session. Forward-Port-Of: odoo/odoo#118295
Steps to reproduce: - Configure incoming mail server and set it to create X record on incoming mails (X can be any model with a chatter) - Create a CSV file and set the encoding to UTF-16 - Send the CSV file through Gmail to the Odoo instance - Go to model X and open the created record - In the chatter, click/download the CSV file - Open the downloaded file with Geany (or any file editor that can show the file encoding) Issue: The file encoding is not the same as the
Original PR description
Steps to reproduce: - Configure incoming mail server and set it to create X record on incoming mails (X can be any model with a chatter) - Create a CSV file and set the encoding to UTF-16 - Send the…
Steps to reproduce:
- Configure incoming mail server and set it to create X record on incoming mails (X can be any model with a chatter)
- Create a CSV file and set the encoding to UTF-16
- Send the CSV file through Gmail to the Odoo instance
- Go to model X and open the created record
- In the chatter, click/download the CSV file
- Open the downloaded file with Geany (or any file editor that can show the file encoding)
Issue:
The file encoding is not the same as the original file (utf-8 instead
of utf-16).
Working with Outlook.
Cause:
The difference between Outlook and Gmail is that Gmail provides the
charset of the file.
The content of the mail is retrieved using `email` python lib.
The lib will try to retrieve the charset of the file and fallback
on `ASCII` if not available, then return the decode content.
```python
def get_text_content(msg, errors='replace'):
content = msg.get_payload(decode=True)
charset = msg.get_param('charset', 'ASCII')
return content.decode(charset, errors=errors)
```
Example:
content = b'd\x00a\x00,\x00,\x00,\......'
Outlook:
charset = 'ASCII'
return => 'd\x00a\x00,\x00,\x00...'
Gmail:
charset = 'UTF-16LE'
return => 'da,,,,,\n,,,,,\....'
In the post process of the attachment, the content is encoded in
'utf-8' (to then encoded in base64) before creating the attachment
record.
Content encoded to 'utf-8':
Outlook: b'd\x00a\x00,\x00,\x00...'
Gmail: b'da,,,,,\n,,,,,\n....'
Therefore, when writing the file on the disk, the encoding is based
on the binary content.
Solution:
When parsing the mail, add the encoding charset to the `info` variable.
Then, when creating the attachment, use the charset in `info` (or
fallback on 'utf-8' if no charset set) to encode the content.
opw-3089009
Forward-Port-Of: odoo/odoo#118480
Forward-Port-Of: odoo/odoo#111298Description of the issue/feature this PR addresses: project.task kanban view > tasks should be sorted by priority > state Task-3254564 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117183
Original PR description
Description of the issue/feature this PR addresses: project.task kanban view > tasks should be sorted by priority > state Task-3254564 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117183
before this commit, the form view of ir.actions.act_window.view was not properly aligned. * open any menu linked with type ir.actions.act_window * click on Edit Action from debugger button * click on Add a line from the View one2many field after this commit, the view will be aligned properly. Before:  After:  After:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117066
This PR contains two commits, respectively for task-3245492 and task-3266632 Forward-Port-Of: odoo/odoo#118398
Original PR description
This PR contains two commits, respectively for task-3245492 and task-3266632 Forward-Port-Of: odoo/odoo#118398
Since the Owl conversion of the partner autocomplete widgets, the search by VAT number on a `Many2one` field of `res.partner` wasn't working anymore. Forward-Port-Of: odoo/odoo#118071
Original PR description
Since the Owl conversion of the partner autocomplete widgets, the search by VAT number on a `Many2one` field of `res.partner` wasn't working anymore. Forward-Port-Of: odoo/odoo#118071
When updating the recipient bank on a posted vendor bill the chnages will not be saved. Steps to reproduce the error: 1-Go to accounting 2-Create a vendor bill and confirm it 3-Change the bank recipient and click manual save 4-Reload and you can see the changes disappeared The error was happening because the recipient bank was not displayed as readonly on a posted state of the account move. opw-3247282 Forward-Port-Of: odoo/odoo#118294
Original PR description
When updating the recipient bank on a posted vendor bill the chnages will not be saved. Steps to reproduce the error: 1-Go to accounting 2-Create a vendor bill and confirm it 3-Change the bank recipient and click manual save 4-Reload and you can see the changes disappeared The error was happening because the recipient bank was not displayed as readonly on a posted state of the account move. opw-3247282 Forward-Port-Of: odoo/odoo#118294
Steps to reproduce ================== - Go to Email Marketing - Open a campaign - Go back to the homepage by using the topleft square button -> `$(...).offset() is undefined` Cause of the issue ================== The ResizeObserver used in MassMailingFullWidthViewController is still triggered, even though it shoudln't. Solution ======== Disconnect the observer when the component is unmounted. opw-3271101 Forward-Port-Of: odoo/odoo#118345
Original PR description
Steps to reproduce ================== - Go to Email Marketing - Open a campaign - Go back to the homepage by using the topleft square button -> `$(...).offset() is undefined` Cause of the issue ================== The ResizeObserver used in MassMailingFullWidthViewController is still triggered, even though it shoudln't. Solution ======== Disconnect the observer when the component is unmounted. opw-3271101 Forward-Port-Of: odoo/odoo#118345
This update contains the following commits: [FIX] components: solve missing update (concurrency issue) [DOC] remove old references to comp for useRef hook [FIX] devtools: Fix build commands for windows users [FIX] devtools: Fix devtools in detached window [IMP] devtools: Add a button to navigate to the doc [IMP] devtools: Add devtools documentation [IMP] Allow app to be mounted in shadow DOM [IMP] playground: allow sharing playground links [IMP] runtime: allow validating object values usi
Original PR description
This update contains the following commits: [FIX] components: solve missing update (concurrency issue) [DOC] remove old references to comp for useRef hook [FIX] devtools: Fix build commands for…
This update contains the following commits: [FIX] components: solve missing update (concurrency issue) [DOC] remove old references to comp for useRef hook [FIX] devtools: Fix build commands for windows users [FIX] devtools: Fix devtools in detached window [IMP] devtools: Add a button to navigate to the doc [IMP] devtools: Add devtools documentation [IMP] Allow app to be mounted in shadow DOM [IMP] playground: allow sharing playground links [IMP] runtime: allow validating object values using a type description [FIX] devtools: Increase vertical padding of the search bar [FIX] devtools: Hide the collapse all button [FIX] devtools: Fix bad computation of highlight boxes on the page [FIX] package: Auto-update package-lock.json Notes: https://github.com/odoo/owl/releases/tag/v2.1.1 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#118722
The 'Generate payment link' action on account move records was only shown to the users of the group 'Show Full Accounting Feature' (and to salesman when sale is installed). This means that if you only have invoicing app (`account` module) installed, you don't see the action. This commit makes sure the action is visible to all accounting users, like the refund wizard. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118
Original PR description
The 'Generate payment link' action on account move records was only shown to the users of the group 'Show Full Accounting Feature' (and to salesman when sale is installed). This means that if you only have invoicing app (`account` module) installed, you don't see the action. This commit makes sure the action is visible to all accounting users, like the refund wizard. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118671 Forward-Port-Of: odoo/odoo#117192
At the moment, XSD files are automatically downloaded at database initialization, which is quite unnecessary. The idea is to change Odoo's use of XSDs from being systematically downloaded and used for validation to simply being available if desired (e.g. for development or for customers who want them). To achieve this, this PR does the following: - remove the XSD download crons; - provide a 'download XSDs' button in the Settings (next to the debug mode button) which is available in debug
Original PR description
At the moment, XSD files are automatically downloaded at database initialization, which is quite unnecessary. The idea is to change Odoo's use of XSDs from being systematically downloaded and used for validation to simply being available if desired (e.g. for development or for customers who want them). To achieve this, this PR does the following: - remove the XSD download crons; - provide a 'download XSDs' button in the Settings (next to the debug mode button) which is available in debug mode; - skip XSD validation if any required XSD file is not present; and - deprecate the 'force_reload' option. Entreprise PR: https://github.com/odoo/enterprise/pull/38350 Task id: 3010716 Forward-Port-Of: odoo/odoo#118677 Forward-Port-Of: odoo/odoo#115720
Previously, the "Other applications" smartbutton was incorrectly matching with the applicants with '' on the fields. We don't want applicants to match if both of them has '' on the matching fields. Moreover, record rules were not correctly applied for application_count calculation, as current record will not match with similar record which has no company defined on it. This commit fixes the above mentioned issues. task - 3266694 Forward-Port-Of: odoo/odoo#118289
Original PR description
Previously, the "Other applications" smartbutton was incorrectly matching with the applicants with '' on the fields. We don't want applicants to match if both of them has '' on the matching fields. Moreover, record rules were not correctly applied for application_count calculation, as current record will not match with similar record which has no company defined on it. This commit fixes the above mentioned issues. task - 3266694 Forward-Port-Of: odoo/odoo#118289
An error is raised when trying to set the date of a note in the activities Steps to reproduce: 1. Install Notes 2. Click on the activities icon (top right of the screen) 3. Click on 'Add new note' 4. Set a date to the note 5. An error is raised Solution: Use the eventDate only if the input is set, get the locale from the getOptions function and set the datepicker warning regardless of where we get the date from Problem: `this.date` can be undefined Forward-Port-Of: odoo/odoo#118
Original PR description
An error is raised when trying to set the date of a note in the activities Steps to reproduce: 1. Install Notes 2. Click on the activities icon (top right of the screen) 3. Click on 'Add new note' 4. Set a date to the note 5. An error is raised Solution: Use the eventDate only if the input is set, get the locale from the getOptions function and set the datepicker warning regardless of where we get the date from Problem: `this.date` can be undefined Forward-Port-Of: odoo/odoo#118630
Issue 1: Before this commit, when the user changes the access rights of another user, he will see a warning message the other access rights will change with his changes. In that warning message, `Other` category could be displayed and that category is only displayed in the user form view if the user is in debug mode since it is a Technical category. This commit hides the `Other` category in the warning message when the us
Original PR description
Issue 1: Before this commit, when the user changes the access rights of another user, he will see a warning message the other access rights will change with his changes. In that warning message,…
Issue 1:
Before this commit, when the user changes the access rights of another
user, he will see a warning message the other access rights will change
with his changes. In that warning message, `Other` category could be
displayed and that category is only displayed in the user form view if
the user is in debug mode since it is a Technical category.
This commit hides the `Other` category in the warning message when the
user is not in debug mode to be consistent with the visibility of that
category in the form view.
Issue 2:
Before this commit, the project onboarding tour: the step to create a new
stage gets validated if the user clicks on the 'add' button without actually
creating a new stage
After this commit, it will point first to the text area for the name, and then
add a tooltip will be highlighted so the tour does not consume without
adding the stage.
task-3049636
Forward-Port-Of: odoo/odoo#104844Steps: - Install helpdesk and timesheet app. - Go to team form view. - Enable timesheet option and click on hours recorded stat button. Issue: - Ticket field is not displaying default on timesheet list view open from team form view Cause: - New invisible ticket field is added to avoid domain error and because of that xpath is not appling on right ticket field in timesheet list view. Fix: - Move invisible ticket field below actual ticket field to apply xpath on right field. tas
Original PR description
Steps: - Install helpdesk and timesheet app. - Go to team form view. - Enable timesheet option and click on hours recorded stat button. Issue: - Ticket field is not displaying default on timesheet list view open from team form view Cause: - New invisible ticket field is added to avoid domain error and because of that xpath is not appling on right ticket field in timesheet list view. Fix: - Move invisible ticket field below actual ticket field to apply xpath on right field. task-3255754 Forward-Port-Of: odoo/enterprise#39300
Issue: It is not possible to send multiple reports in Field Service to a customer. Only the first report will be sent. Cause: In the `_process_state` method in the flow of sending mail: ```py ... mailing_document_based = self.env.context.get('mailing_document_based') ... elif done_emails and mail_to in done_emails and not mailing_document_based: mail_values['state'] = 'cancel' mail_values['failure_type'] = 'mail_dup' ... elif done_emails is not None and not mailing_documen
Original PR description
Issue:
It is not possible to send multiple reports in Field Service to a customer.
Only the first report will be sent.
Cause:
In the `_process_state` method in the flow of sending mail:
```py
...
mailing_document_based = self.env.context.get('mailing_document_based')
...
elif done_emails and mail_to in done_emails and not mailing_document_based:
mail_values['state'] = 'cancel'
mail_values['failure_type'] = 'mail_dup'
...
elif done_emails is not None and not mailing_document_based:
done_emails.append(mail_to)
...
```
If the emails sent are not specified as document based, there will be only one email per recipient.
Solution:
Specify in the context that there will be documents in the emails sent.
opw-3241212
Forward-Port-Of: odoo/enterprise#39860
Forward-Port-Of: odoo/enterprise#39488Steps: - Install timesheet. - Go to All Timesheet. - Open list view. Issue: - TImer should not display in All Timesheet list view. Cause: - JS class was applied on commen list view. Fix: - Remove JS class from All Timesheet list view. task-3255754 Forward-Port-Of: odoo/enterprise#39791
Original PR description
Steps: - Install timesheet. - Go to All Timesheet. - Open list view. Issue: - TImer should not display in All Timesheet list view. Cause: - JS class was applied on commen list view. Fix: - Remove JS class from All Timesheet list view. task-3255754 Forward-Port-Of: odoo/enterprise#39791
Steps to reproduce ================== - Go to documents - In the search panel (sidebar), click on the cog next to Inbox - Click on Edit `Error: View props should have a "resModel" key` Cause of the issue ================== The relation was removed from the activeFields here https://github.com/odoo/odoo/pull/113092 Solution ======== The info is still available in `fields` opw-3268916 Forward-Port-Of: odoo/enterprise#39737
Original PR description
Steps to reproduce ================== - Go to documents - In the search panel (sidebar), click on the cog next to Inbox - Click on Edit `Error: View props should have a "resModel" key` Cause of the issue ================== The relation was removed from the activeFields here https://github.com/odoo/odoo/pull/113092 Solution ======== The info is still available in `fields` opw-3268916 Forward-Port-Of: odoo/enterprise#39737
At the moment, XSD files are automatically downloaded at database initialization, which is quite unnecessary. The idea is to change Odoo's use of XSDs from being systematically downloaded and used for validation to simply being available if desired (e.g. for development or for customers who want them). To achieve this, this PR does the following: - remove the XSD download crons; - provide a 'download XSDs' button in the Settings (next to the debug mode button) which is available in deb
Original PR description
At the moment, XSD files are automatically downloaded at database initialization, which is quite unnecessary. The idea is to change Odoo's use of XSDs from being systematically downloaded and used for validation to simply being available if desired (e.g. for development or for customers who want them). To achieve this, this PR does the following: - remove the XSD download crons; - provide a 'download XSDs' button in the Settings (next to the debug mode button) which is available in debug mode; - skip XSD validation if any required XSD file is not present; and - deprecate the 'force_reload' option. Community PR: https://github.com/odoo/odoo/pull/115720 Task id: 3010716 Forward-Port-Of: odoo/enterprise#39832 Forward-Port-Of: odoo/enterprise#38350
As PKCS#12 support in pyOpenSSL is now deprecated, it raises a warning and prevents the update of the lib. See odoo/odoo#118286 Forward-Port-Of: odoo/enterprise#39795
Original PR description
As PKCS#12 support in pyOpenSSL is now deprecated, it raises a warning and prevents the update of the lib. See odoo/odoo#118286 Forward-Port-Of: odoo/enterprise#39795
Purpose: ======== Replace the nonexistent `article.cover_height` field by the correct `article.cover_image_position` field in the frontend view. This commit also adds a cover to an article in the frontend tour to make sure that covers do not make knowledge crash in frontend. It also fixes the icon position that was not overlapping the cover in frontend anymore. Task-3221175 Forward-Port-Of: odoo/enterprise#38712
Original PR description
Purpose: ======== Replace the nonexistent `article.cover_height` field by the correct `article.cover_image_position` field in the frontend view. This commit also adds a cover to an article in the frontend tour to make sure that covers do not make knowledge crash in frontend. It also fixes the icon position that was not overlapping the cover in frontend anymore. Task-3221175 Forward-Port-Of: odoo/enterprise#38712
Steps to reproduce: - create a new rental period with day unit; - add this period on a rented product; - go to ecommerce on the page of this product. Issue: The default duration is one day too long. Solution: We have to serialize correctly depending on whether we have to process a date or a datetime. opw-3252646 Forward-Port-Of: odoo/enterprise#39507
Original PR description
Steps to reproduce: - create a new rental period with day unit; - add this period on a rented product; - go to ecommerce on the page of this product. Issue: The default duration is one day too long. Solution: We have to serialize correctly depending on whether we have to process a date or a datetime. opw-3252646 Forward-Port-Of: odoo/enterprise#39507
## Current behaviour There is no way to see the weekly overtime in the grid view. ## Expected behaviour Should be able to see the weekly overtime, in similar fashion to saas-16.1. ## Steps to reproduce - Install Timesheet - Open the Timesheet app, there is no way to see the weekly overtime. You can hover over the daily totals bars to see the daily overtime. ## Reason for the problem Functional regression when converting the grid view to Owl. ## Fix Show the weekly overtime when
Original PR description
## Current behaviour There is no way to see the weekly overtime in the grid view. ## Expected behaviour Should be able to see the weekly overtime, in similar fashion to saas-16.1. ## Steps to reproduce - Install Timesheet - Open the Timesheet app, there is no way to see the weekly overtime. You can hover over the daily totals bars to see the daily overtime. ## Reason for the problem Functional regression when converting the grid view to Owl. ## Fix Show the weekly overtime when hovering over the weekly summary column. ## Affected versions - saas-16.2 - master --- opw-3252814 Forward-Port-Of: odoo/enterprise#39356
Steps to reproduce ================== - Go to repair - Switch to the kanban view - Toggle studio - Click on "Add a priority" - Select the state field The view is now unusable and there is no user friendly way to restore it to a working state Cause of the issue ================== The state field is already present in the view and the kanban view can only handle one ocurrence for each field. https://github.com/odoo/odoo/blob/d32c0ddbcb99385407a5030e8d3ea4df44509377/addons/web/
Original PR description
Steps to reproduce ================== - Go to repair - Switch to the kanban view - Toggle studio - Click on "Add a priority" - Select the state field The view is now unusable and there is no user friendly way to restore it to a working state Cause of the issue ================== The state field is already present in the view and the kanban view can only handle one ocurrence for each field. https://github.com/odoo/odoo/blob/d32c0ddbcb99385407a5030e8d3ea4df44509377/addons/web/static/src/js/views/kanban/kanban_record.js#L234 Solution ======== Remove activeFields from the selection possibilities opw-3089137 Forward-Port-Of: odoo/enterprise#39786 Forward-Port-Of: odoo/enterprise#39598
If applied, this commit will solve the issue of the KeyError in 'My Timesheets' when the 'Company Working Hours' and Resource's 'Working Time' are not same then apply groupby as 'Employee' in the timesheet. Steps to produce: - Change the Company Working Hours from settings. - Open My timesheet and group by the records using 'Employee'. - If the Working Time of Resouce and Company Working Hours is not same, the error will produce. see - https://tinyurl.com/27fygana sentry - 4046295402
Original PR description
If applied, this commit will solve the issue of the KeyError in 'My Timesheets' when the 'Company Working Hours' and Resource's 'Working Time' are not same then apply groupby as 'Employee' in the timesheet. Steps to produce: - Change the Company Working Hours from settings. - Open My timesheet and group by the records using 'Employee'. - If the Working Time of Resouce and Company Working Hours is not same, the error will produce. see - https://tinyurl.com/27fygana sentry - 4046295402 Forward-Port-Of: odoo/enterprise#39655
If anyone deletes record from 'hr.payslip.input.type' and that record is used in '_get_attachment_types' then external_id is not found error will occur. see this traceback: https://tinyurl.com/24rpkptg Applying this commit will fix this issue. sentry-4054617926 Forward-Port-Of: odoo/enterprise#39607 Forward-Port-Of: odoo/enterprise#39381
Original PR description
If anyone deletes record from 'hr.payslip.input.type' and that record is used in '_get_attachment_types' then external_id is not found error will occur. see this traceback: https://tinyurl.com/24rpkptg Applying this commit will fix this issue. sentry-4054617926 Forward-Port-Of: odoo/enterprise#39607 Forward-Port-Of: odoo/enterprise#39381
max_digits is used to count the number of digits in the string representation of the number, ignoring the coma. When displaying the error message, we remove 3 to this number to create the digits before the coma : 1 character for the coma, then 2 characters for the decimal places. It's wrong, and should be 2, as, again, the coma does not count in this limit. Forward-Port-Of: odoo/enterprise#39556
Original PR description
max_digits is used to count the number of digits in the string representation of the number, ignoring the coma. When displaying the error message, we remove 3 to this number to create the digits before the coma : 1 character for the coma, then 2 characters for the decimal places. It's wrong, and should be 2, as, again, the coma does not count in this limit. Forward-Port-Of: odoo/enterprise#39556
The kanban view of a model created with studio has two issues: the card color is not displayed and there is an extra border on the card Steps to reproduce: 1. Install Studio 2. Go to the home page and trigger Studio 3. Create a new app and a new model with pipeline stages enabled 4. Close Studio and go to the kanban view 5. Create a new record and set the color 6. The color is not shown on the card and there is a border on the card Solution: Use `x_color` for the kanban color and re
Original PR description
The kanban view of a model created with studio has two issues: the card color is not displayed and there is an extra border on the card Steps to reproduce: 1. Install Studio 2. Go to the home page and trigger Studio 3. Create a new app and a new model with pipeline stages enabled 4. Close Studio and go to the kanban view 5. Create a new record and set the color 6. The color is not shown on the card and there is a border on the card Solution: Use `x_color` for the kanban color and remove the `o_kanban_record` class (it's already present on the article) opw-3257090 Forward-Port-Of: odoo/enterprise#39509
Since the refactoring of the permission panel, the custom css rules of the permission panel no longer apply. Those rules had the following effects on the component: 1. It highlighted in blue the current user in the member list. 2. When the user was unable to change the permissions of a user, the caret of the selection field was hidden and the cursor of the user was turned into a red sign (cursor: not-allowed) on mouse hover to indicate that the field can not be edited. 3. The buttons to rem
Original PR description
Since the refactoring of the permission panel, the custom css rules of the permission panel no longer apply. Those rules had the following effects on the component: 1. It highlighted in blue the current user in the member list. 2. When the user was unable to change the permissions of a user, the caret of the selection field was hidden and the cursor of the user was turned into a red sign (cursor: not-allowed) on mouse hover to indicate that the field can not be edited. 3. The buttons to remove a member from the member list only appeared when hovering a user from the list. 4. The font size of the email address was slightly reduced. To fix the issue, we will update the selectors of the permission panel component to ensure that the custom css rules will be properly applied on it as it was the case before. Related: https://github.com/odoo/enterprise/pull/35261 task-3251343 Forward-Port-Of: odoo/enterprise#38898
Steps to reproduce ================== - Toggle studio - Create a new app - Edit the form view -> The name field isn't editable This is a backport from master opw-3127850 Forward-Port-Of: odoo/enterprise#39778 Forward-Port-Of: odoo/enterprise#39547
Original PR description
Steps to reproduce ================== - Toggle studio - Create a new app - Edit the form view -> The name field isn't editable This is a backport from master opw-3127850 Forward-Port-Of: odoo/enterprise#39778 Forward-Port-Of: odoo/enterprise#39547
Forward-Port-Of: odoo/enterprise#38609
Original PR description
Forward-Port-Of: odoo/enterprise#38609
backport-of : https://github.com/odoo/enterprise/commit/45a860d52249fdc20a72010c8c184443af37b182 Since [1], [2], [3] and [4], the field API was simplified and specified. Some props were removed (update, type, setDirty and value) and some were now mandatory (record and name). This specification make it difficult to use the fields as a "normal" component (without a record). This was the case with MrpTimer, that was used as a field, but also as a component. To solve this issue, in this commit,
Original PR description
backport-of : https://github.com/odoo/enterprise/commit/45a860d52249fdc20a72010c8c184443af37b182 Since [1], [2], [3] and [4], the field API was simplified and specified. Some props were removed…
backport-of : https://github.com/odoo/enterprise/commit/45a860d52249fdc20a72010c8c184443af37b182 Since [1], [2], [3] and [4], the field API was simplified and specified. Some props were removed (update, type, setDirty and value) and some were now mandatory (record and name). This specification make it difficult to use the fields as a "normal" component (without a record). This was the case with MrpTimer, that was used as a field, but also as a component. To solve this issue, in this commit, we divide it in two different components, MrpTimer and MrpTimerField. [1]: https://github.com/odoo/odoo/commit/aed1ba484d0c48a59e166ef01e69967bd618a562 [2]: https://github.com/odoo/odoo/commit/8cde3e84bb70a2bd097921c08c0059bf65bee602 [3]: https://github.com/odoo/odoo/commit/688986f888f2fe2371d58b74ded81315ba6bb353 [4]: https://github.com/odoo/odoo/commit/91303252f413325859a6f1651d056593a8cf6382 closes odoo/enterprise#37960 Related: odoo/odoo#114761 Forward-Port-Of: odoo/enterprise#38546
[FIX] account_followup: inconsistency between followup_status search and compute functions To reproduce: 1) Create an invoice for partner A, at today's date, due in 30 days. 2) Go to the followup report, open partner A. 3) Force the followup level and set the reminder date in the past (a bit artificial, but we're replicating a setup; this can happen in real life with just time passing after this date was set by a legit followup action). 4) Create an second invoice for partner A, like th
Original PR description
[FIX] account_followup: inconsistency between followup_status search and compute functions To reproduce: 1) Create an invoice for partner A, at today's date, due in 30 days. 2) Go to the followup…
[FIX] account_followup: inconsistency between followup_status search and compute functions To reproduce: 1) Create an invoice for partner A, at today's date, due in 30 days. 2) Go to the followup report, open partner A. 3) Force the followup level and set the reminder date in the past (a bit artificial, but we're replicating a setup; this can happen in real life with just time passing after this date was set by a legit followup action). 4) Create an second invoice for partner A, like the one in 1) 5) Open the followup report => partner A appears with "no action needed", but stills is included by the filters "with overdue invoices" and "in need of action". This is inconsistent. Here is what causes the issue: - The query computes a value for followup_delay because of the existence of the first invoice. - The in_need_of_action_aml subquery tries to join the move lines with account_followup_followup_line. When the receivable line from the second invoice is treated by this query, no followup line is joined, so all the joined fields are NULL. - The expression "COALESCE(ful.delay, -999) <= partner.followup_delay" checks -999 <= delay of the followup level defined in step 3). This is the reason why steps 1) ,2) and 3) are needed to reproduce this case. Without them, we'd have no followup line at all, so the followup_delay would be NULL, and we'd check -999 <= NULL, which gives NULL, which evaluates as falsy in the condition. - The expression "COALESCE(line.date_maturity, line.date) + COALESCE(ful.delay, -999) < %(current_date)s" evaluates as line.date_maturity - 999 < today. That's where the problem is: this will most likely always be true, so the move line will be considered as needing an action, and will result in the query considering this partner as in need of an action, while it's not the case. Since this query is used by the search function defined on followup_status, it'll be called by the filters in the UI, and will hence include as needing an action some partners for which nothing needs to be done. followup_status's compute function, on the other hand, calls something else and is correct, so it'll display a value that's inconsistent with the filter. The fix is here rather easy: the problem is in this context, considering -999 as the default delay in case of a NULL followup line does not make sense (it does in other parts of the query, so it's probably what caused the confusion). When no followup line is linked to a move line, the followup line to check the delay from is actually the first one. [FIX] account_followup: fix corner case in computation of followup status To reproduce: 1) Make sure your first followup level has a delay of 15 days (it's the default value in demo data) 2) Create an invoice for partner A 16 days in the past, due immediately. 3) Open the followup report, and send a first followup reminder to partner A. 4) Set the next reminder date for A in the past (artificial, but it mimics the passage of time). 5) Create a new invoice for A, again 16 days in the past, so that it should match the first followup level. 6) Open the followup report. => Partner A appears as "with overdue invoices", but is still taken into account as "in need of action" by the filter. This is inconsistent. The desired behavior is here the one of the filter, so A should be "in need of action", because the second invoice never generated any followup and is overdue enough to enter the first followup level. [FIX] account_followup: more precise error messages when missing contact data When running the action 'Process Automatic Follow-ups', if a partner misses a mail address or phone number to send the follow-up to, a UserError is raised. However, this error did not say which partner was missing data, making it really hard to fix for the user. Forward-Port-Of: odoo/enterprise#39807 Forward-Port-Of: odoo/enterprise#39725