Tuesday, April 25, 2023
30 changes
Enhancements to existing features
The Field Service task search view was adjusted to stay compatible with related platform changes. This helps preserve search behavior for field service users as an older reference field is removed.
Original PR description
This commit moves a field in the inherited fsm task search view, since the field of reference is being removed. Community: https://github.com/odoo/odoo/pull/118515 Task-3264820
Helpdesk ticket titles can now expand across multiple lines when they are too long for the form header. This makes long ticket names easier for support teams to read without changing the underlying ticket workflow.
Original PR description
This commit changes the ticket form title to a text widget to make it possible to display it on multiple lines when too long. This is directly linked to changes in community: https://github.com/odoo/odoo/pull/117355 task-3138826
Daily point-of-sale reports now include a higher count for cash box openings. This improves the accuracy of end-of-day reporting and helps businesses better track cash drawer activity.
Original PR description
Increase the count of the cash box opening for the daily reports. task-id: 2206846
Resolved issues and error corrections
This fixes an issue where renaming a Helpdesk team could cause an error and interrupt the update. Users can now change Helpdesk team names normally, improving reliability for helpdesk configuration updates.
Original PR description
Description of the issue/feature this PR addresses: In helpdesk module, when name of helpdesk is try to update it gives traceback of alias_name not found. Current behavior before PR: generate traceback when helpdesk name is updated. Desired behavior after PR is merged: helpdesk name is updated without traceback. Fix: alias_name is not found as there is no record with name alias_name in values pass by _alias_get_creation_values function due to which traceback is generated. we added condition as if alias_name is not in self then only its called _alias_get_creation_values function. task-3252521
Code cleanup and technical improvements
The appointment-related code has been reorganized to make it easier to maintain and extend. This internal cleanup prepares the appointment setup for future resource-related improvements without changing day-to-day user behavior.
Original PR description
Move fields and methods into categories to prepare the addition of resources for appointment type to improve readibility. Prepare PR odoo/enterprise#37220 task-2453291
Miscellaneous changes
The XML was malformed, the special contributor tag was misplaced. It caused the XML to be rejected by SRI, please note it only occurred if the company was a special tax contributor. Forward-Port-Of: odoo/enterprise#39755
Original PR description
The XML was malformed, the special contributor tag was misplaced. It caused the XML to be rejected by SRI, please note it only occurred if the company was a special tax contributor. Forward-Port-Of: odoo/enterprise#39755
This update makes key record actions such as creating, updating, deleting, and setting defaults behave more consistently across affected Odoo apps. It reduces the risk of unexpected errors in edge cases, especially when actions are run with empty inputs or no selected records.
Original PR description
Enforce strict types for returned values for * create * write * unlink * default_get to make those methods more consistent and reliable. Also make sure they can be called with empty self/values, i.e. that they follow the same behavior as the base methods defined in the main orm Model. Community PR: https://github.com/odoo/odoo/pull/116809
Web Studio now uses the updated format expected by selection menus when choosing size options. This keeps Studio aligned with the main platform change and helps prevent issues when editing views.
Original PR description
This commit is the counterpart of the community fix, which removed the support of arrays as SelectMenu value. Instead, each size option has been replaced by a string. Community PR: https://github.com/odoo/odoo/pull/119298
This change updates the spreadsheet dashboard documents area to stop relying on an outdated page-loading component that has been removed. It helps keep the dashboard document workflow compatible with the latest platform code without changing the user-facing experience.
Original PR description
This commit removes the import from "web.dom_ready" as the module is removed. This module was used to wait for the content to be loaded to manipulate the dom after that. task id: 3265979
This update continues modernizing Point of Sale and IoT-related components by reducing reliance on older web technology. The change is mainly internal, helping keep these modules easier to maintain and evolve without altering day-to-day business workflows.
Original PR description
*: account_accountant,pos_l10n_se,pos_restaurant_iot,pos_settle_due This is part of the continuous effort of refactoring pos addons towards using more modern modules and programming patterns (such as services). After this commit, point_of_sale addons are now left with the use of the legacy `web.concurrency` module because of the `MutexedDropPrevious`. It's okay to keep because it's relatively an independent module compared to other legacy web module. See https://github.com/odoo/odoo/pull/117231 for more info.
The code editor used by Studio has been moved into Odoo’s core web components so it can be reused in more areas. Studio’s XML editor and related tests were updated, and the older “ace” widget name was replaced with the clearer “code” name for consistency.
Original PR description
The CodeEditor component is needed in other places and therefore it is moved to the web addon as part of the core components. The XmlEditor and some tests had to be adapted for this change. Community PR: https://github.com/odoo/odoo/pull/117782
In 16.1, when doing an invoice and fill all the fields except the invoice date and then print it with the button on top of the page. A traceback appears because we try to do a computation on the invoice date that we don't have. Forward-Port-Of: odoo/enterprise#40207
Original PR description
In 16.1, when doing an invoice and fill all the fields except the invoice date and then print it with the button on top of the page. A traceback appears because we try to do a computation on the invoice date that we don't have. Forward-Port-Of: odoo/enterprise#40207
This commit's purpose is to allow the user to remove the planned date end, or the planned date start of a task from the list view, or the form view of the task. If the user removes either the planned date end, or the planned date start, both dates will be removed. If the user tries to add only a date end or a date start while keeping the other date empty on a task with no planned date, these changes will be discarded. The goal of this fix is for the tasks to always have either both dates set, or
Original PR description
This commit's purpose is to allow the user to remove the planned date end, or the planned date start of a task from the list view, or the form view of the task. If the user removes either the planned date end, or the planned date start, both dates will be removed. If the user tries to add only a date end or a date start while keeping the other date empty on a task with no planned date, these changes will be discarded. The goal of this fix is for the tasks to always have either both dates set, or both dates set to False. task-3254564 note: an update is needed on the 16.1 forward branch. The date start and date end fields are not yet accessible for non fsm task in 16.0 from the list view, but in 16.1 they are. And the required option needs to be removed there too. Forward-Port-Of: odoo/enterprise#40172 Forward-Port-Of: odoo/enterprise#39874
On creating product template, Odoo first creates template record and then variants [1]. If product template has fields related to product variant fields, then such fields are not saved by default. However, using `_get_related_fields_variant_template` allows to pass by this behavior [2]. STEPS: 1. Create product.template with intrastat fields specified 2. The created record has empty intrastat fields [1]: https://github.com/odoo/odoo/blob/70a9995c9e02f36dc15d2723151ef0a205ebc12b/addons/pr
Original PR description
On creating product template, Odoo first creates template record and then variants [1]. If product template has fields related to product variant fields, then such fields are not saved by default. However, using `_get_related_fields_variant_template` allows to pass by this behavior [2]. STEPS: 1. Create product.template with intrastat fields specified 2. The created record has empty intrastat fields [1]: https://github.com/odoo/odoo/blob/70a9995c9e02f36dc15d2723151ef0a205ebc12b/addons/product/models/product_template.py#L423-L425 [2]: https://github.com/odoo/odoo/blob/70a9995c9e02f36dc15d2723151ef0a205ebc12b/addons/product/models/product_template.py#L427-L434 opw-3116428 Forward-Port-Of: odoo/enterprise#35800
Before this commit: When portal users record components used in a subcontracted product, and it has quality checks, it fails with an access error. After this commit: Portal users can record components without access errors. Fix: As portal users don't have access to `quality.check`, add `sudo()` on `check_ids` introduced in commit [4c44e88]. opw-3251079 [4c44e88]: https://github.com/odoo/enterprise/commit/4c44e889ad99a3f45d23aedbe8c29171b0b58af2 Forward-Port-Of: odoo/enterprise#39
Original PR description
Before this commit: When portal users record components used in a subcontracted product, and it has quality checks, it fails with an access error. After this commit: Portal users can record components without access errors. Fix: As portal users don't have access to `quality.check`, add `sudo()` on `check_ids` introduced in commit [4c44e88]. opw-3251079 [4c44e88]: https://github.com/odoo/enterprise/commit/4c44e889ad99a3f45d23aedbe8c29171b0b58af2 Forward-Port-Of: odoo/enterprise#39578
At the moment, all 16 localities within México City are called 'Ciudad de México'. So, if you try to create an export invoice document, referencing a partner there, you have no way of seeing which locality is the right locality to select for your customer. This commit renames them with the actual locality name. Server action to fix existing DBs: https://gist.github.com/antoine162/3166d6b44e629711463833772ce9eb0e opw-3181743 Forward-Port-Of: odoo/enterprise#40178
Original PR description
At the moment, all 16 localities within México City are called 'Ciudad de México'. So, if you try to create an export invoice document, referencing a partner there, you have no way of seeing which locality is the right locality to select for your customer. This commit renames them with the actual locality name. Server action to fix existing DBs: https://gist.github.com/antoine162/3166d6b44e629711463833772ce9eb0e opw-3181743 Forward-Port-Of: odoo/enterprise#40178
Steps to reproduce: - go to Documents app; - click on a workspace; - click on the share button; - click on "Download and Upload"; - fill in the email alias; - share it; - go to Configuration / Shares & Emails; Issue: The checkbox "Upload by Email" is not checked for our sharing. opw-3232085 Forward-Port-Of: odoo/enterprise#39344
Original PR description
Steps to reproduce: - go to Documents app; - click on a workspace; - click on the share button; - click on "Download and Upload"; - fill in the email alias; - share it; - go to Configuration / Shares & Emails; Issue: The checkbox "Upload by Email" is not checked for our sharing. opw-3232085 Forward-Port-Of: odoo/enterprise#39344
We have this problem: - You have a commercial partner of an invoice set as individual - You change its country - You set the commercial partner as a company - You expect the mod349 to be available for the commercial partner, but it's not. After this PR #29806 the `_compute_l10n_es_reports_mod349_available` can vary depending on `commercial_partner_id.is_company` but this field was not in the `depends`. We added it to the `depends`. Task: https://www.odoo.com/web#id=3281041&model=pro
Original PR description
We have this problem: - You have a commercial partner of an invoice set as individual - You change its country - You set the commercial partner as a company - You expect the mod349 to be available for the commercial partner, but it's not. After this PR #29806 the `_compute_l10n_es_reports_mod349_available` can vary depending on `commercial_partner_id.is_company` but this field was not in the `depends`. We added it to the `depends`. Task: https://www.odoo.com/web#id=3281041&model=project.task Ticket: https://www.odoo.com/web#id=3240171&model=project.task Task-3281041 opw-3240171 Forward-Port-Of: odoo/enterprise#39999
When using anglo-saxon accounting and automated inventory evaluation for a product category, some move lines are generated on the move upon posting. These "COGS" lines are unintentionally included in the intrastat report from v16.0 onwards. Before v16.0 a condition existed in the where clause of the query that gathers the lines to represent in the intrastat report that excluded lines that are not represented on the invoice tab. The condition was previously `NOT move_line.exclude_from_invoi
Original PR description
When using anglo-saxon accounting and automated inventory evaluation for a product category, some move lines are generated on the move upon posting. These "COGS" lines are unintentionally included in…
When using anglo-saxon accounting and automated inventory evaluation for a product category, some move lines are generated on the move upon posting. These "COGS" lines are unintentionally included in the intrastat report from v16.0 onwards. Before v16.0 a condition existed in the where clause of the query that gathers the lines to represent in the intrastat report that excluded lines that are not represented on the invoice tab. The condition was previously `NOT move_line.exclude_from_invoice_tab`, but was replaced with `move_line.display_type = 'product'` https://github.com/odoo/enterprise/commit/7a237e665a179c6bd0d7962d331c10dbfe50c0b8#diff-7b1b123893744b02df76c7fa971ebb68b9f59e26f619e3a7d8f290c0f45ed037L210-L220 and then subsequently unintentially removed in reportalypse https://github.com/odoo/enterprise/commit/f435654f70f3d6a1fec7fa696945f2c0eb9a7056#diff-7b1b123893744b02df76c7fa971ebb68b9f59e26f619e3a7d8f290c0f45ed037L215 This commit re-introduces this condition to the where-clause from v16.0 onwards task-id: 3222394 Forward-Port-Of: odoo/enterprise#40191
`no_format` may have None as a value, which may lead to TypeError: > unsupported operand type(s) for +: 'float' and 'NoneType' Fix it by using zero value in that case https://online.sentry.io/issues/4076553593 Forward-Port-Of: odoo/enterprise#40166
Original PR description
`no_format` may have None as a value, which may lead to TypeError: > unsupported operand type(s) for +: 'float' and 'NoneType' Fix it by using zero value in that case https://online.sentry.io/issues/4076553593 Forward-Port-Of: odoo/enterprise#40166
Loading up the Planning's GanttView can become quite slow, especially when there are slots with long-range period (spanning multiple years for instance). This commit introduces two optimizations to alleviate this issue. The first is to pass the GanttView start/end datetime to the `_gantt_resource_work_interval` method via context. Currently, this method returns all the work intervals between start_datetime:min and end_datetime:max. So it can return yearly long intervals even if the GanttView
Original PR description
Loading up the Planning's GanttView can become quite slow, especially when there are slots with long-range period (spanning multiple years for instance). This commit introduces two optimizations to…
Loading up the Planning's GanttView can become quite slow, especially when there are slots with long-range period (spanning multiple years for instance). This commit introduces two optimizations to alleviate this issue. The first is to pass the GanttView start/end datetime to the `_gantt_resource_work_interval` method via context. Currently, this method returns all the work intervals between start_datetime:min and end_datetime:max. So it can return yearly long intervals even if the GanttView only displays the current week. Given that navigating the GanttView triggers a new rpc call to the aforementioned method (i.e. no interval caching on the JS-side), it is enough to only get the work intervals for the current timerange. The second optimization introduces a caching mechanism on the JS side for the Luxon datetime. Even with the first fix, if the GanttView is set to the current year, the js method `_generateAndStoreWorkIntervals` can process lots and lots of work intervals. In that case, the luxon's method serializeDateTimeAccordingToScale can become a bottleneck. To avoid that, a cache is added that maps Luxon DateTimes to serialized Luxon Datetimes. This cache is instantiated each time `_fetchData` is called, to reduce the cache memory footprint while allowing to access it from `_populateAllocatedHours`. #### speedup Customer database with 59 planning slots. min start_datetime = 2023-01-02 07:00:00, max end_datetime = 2025-12-31 16:00:00. Scripting time for GanttView loading changing the timerange. | Timerange | Before PR | After PR | |:-----------:|:----------:|:---------:| | Day | 90s | 10s | | Week | 23s | 450ms | | Month | 23s | 900ms| | Year | 23s | 2s | Footprint of the luxon cache with scale = Year. - Cache retained size: 277Kb - Cache length: 2061. opw-3221517 Forward-Port-Of: odoo/enterprise#39858 Forward-Port-Of: odoo/enterprise#39383
The rental widget throws an error when the site's language uses a date format different than the default MM/DD/YYYY Steps to reproduce: 1. Install eCommerce Rental (website_sale_renting) module 2. Add a 'Rental Search' widget on the website 3. Activate a language with european date format (eg French) and translate the website 4. Go to Settings > Website > Website Info and set the website's default language to French 5. Log out (and set the language to French) 6. Trigger the rental searc
Original PR description
The rental widget throws an error when the site's language uses a date format different than the default MM/DD/YYYY Steps to reproduce: 1. Install eCommerce Rental (website_sale_renting) module 2. Add a 'Rental Search' widget on the website 3. Activate a language with european date format (eg French) and translate the website 4. Go to Settings > Website > Website Info and set the website's default language to French 5. Log out (and set the language to French) 6. Trigger the rental search 7. An error is thrown Solution: Get the date from the daterangepicker Problem: Because the date format can be different than MM/DD/YYYY, we couldn't always correctly parse the date from the input value opw-3266395 Forward-Port-Of: odoo/enterprise#40049
If applied, this commit will solve the cron cleanup issue. The 'NoneType' object is not iterable while evaluating 'model._cron_cleanup()' this issue occurs in model 'data_merge.record' because of method _original_records() returns 'None' and _cleanup() method tried to iterate records. The None object can't be allowed in iteration. so, we put conditions before using the _original_records() method. sentry - 3923640623 Forward-Port-Of: odoo/enterprise#37012
Original PR description
If applied, this commit will solve the cron cleanup issue. The 'NoneType' object is not iterable while evaluating 'model._cron_cleanup()' this issue occurs in model 'data_merge.record' because of method _original_records() returns 'None' and _cleanup() method tried to iterate records. The None object can't be allowed in iteration. so, we put conditions before using the _original_records() method. sentry - 3923640623 Forward-Port-Of: odoo/enterprise#37012
When opening a localized tax report (i.e. not the generic one) from the tax closing next activity (on the Accounting dashboard, after creating the closing move), it was impossible to switch between variants (selecting them had no effect at all). This was due to a javascript bug: the widget needs to keep track of the root report triggering the opening, and to get it, it took it from the options passed to the action, or (if not set) from the action's context. The usual opening flow of the reports
Original PR description
When opening a localized tax report (i.e. not the generic one) from the tax closing next activity (on the Accounting dashboard, after creating the closing move), it was impossible to switch between variants (selecting them had no effect at all). This was due to a javascript bug: the widget needs to keep track of the root report triggering the opening, and to get it, it took it from the options passed to the action, or (if not set) from the action's context. The usual opening flow of the reports (through the menus) does not pass any options in the action dict; however, it gets passed when going through the next activity. The bug was here caused by the fact the localized report was then used as root report, because it was in report_options['report_id']. The fix is here to rather take the report_id in the context of the action if it is provided, and fallback to previous_options['report_id'] only if it isn't set. OPW 3274875 Forward-Port-Of: odoo/enterprise#40200
To reproduce: 1- On the bank journal, create 50 journal entries. 2- Go to reporting > journal report > open the bank journal. 3- You don't have the "load more" button to have more items visible. => This was due to the fact the boolean value telling whether or not the line has more sublines to load was badly computed. Indeed, for bank journals, the "lines" variable will not always contain a line for each account.move.line fetched by the query, because of the condition made at the beginning
Original PR description
To reproduce: 1- On the bank journal, create 50 journal entries. 2- Go to reporting > journal report > open the bank journal. 3- You don't have the "load more" button to have more items visible. => This was due to the fact the boolean value telling whether or not the line has more sublines to load was badly computed. Indeed, for bank journals, the "lines" variable will not always contain a line for each account.move.line fetched by the query, because of the condition made at the beginning of _get_aml_line. Then, len(move_line_vals_list) + len(lines) > report.load_more_limit may not be True, while we actually have len(eval_dict) > report.load_more_limit, indicating the "load more" button should be shown. We fix that by counting the number of treated move lines each iteration of the loop corresponds to, disregarding the number of lines generated for them in the UI. OPW 3279409 Forward-Port-Of: odoo/enterprise#40190