Thursday, September 12, 2024
38 changes
18 changes
Miscellaneous changes
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse to manufacturing in 3 steps - Create a storable product COMP with 10 units in stock - Create a manufacturing order for a product Final product using COMP as components #### > The forcast of the components indicates that they are not available ### Cause of the issue: The location query of the `_get_forecast_availability_outgoing
Original PR description
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse to manufacturing in 3 steps - Create a…
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse to manufacturing in 3 steps - Create a storable product COMP with 10 units in stock - Create a manufacturing order for a product Final product using COMP as components #### > The forcast of the components indicates that they are not available ### Cause of the issue: The location query of the `_get_forecast_availability_outgoing` was recently changed to: https://github.com/odoo/odoo/blob/49061347c181b1a451435bc363bb9508db8b6fab/addons/stock/models/stock_move.py#L2253 This change was made for optimisation purposes because the forecast lines now take care of the precise locations here: https://github.com/odoo/odoo/blob/49061347c181b1a451435bc363bb9508db8b6fab/addons/stock/models/stock_move.py#L2255 However, this optimisation is not correct as the forecast the result of this query is used in order to determine if a move is incoming or outgoing here: https://github.com/odoo/odoo/blob/49061347c181b1a451435bc363bb9508db8b6fab/addons/stock/report/stock_forecasted.py#L31-L44 and these domains only makes sense if the `wh_location_ids` are indeed all the locations of the warehouse and not these that are children of the "pre-prod" location. opw-3979953 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179850
Steps to reproduce: ----------------------------------------------------------------------------------------------------------- 1. Install the Project. 2. Go to settings and select customer ratings. 3. Then go to any project edit the stage and select the template for the rating email template. 4. Then change the stage of any task. check the email and give a rating to your task. 5. Check the Discus app then you will see a notification and no space between the name of the task and the
Original PR description
Steps to reproduce: ----------------------------------------------------------------------------------------------------------- 1. Install the Project. 2. Go to settings and select customer ratings.…
Steps to reproduce: ----------------------------------------------------------------------------------------------------------- 1. Install the Project. 2. Go to settings and select customer ratings. 3. Then go to any project edit the stage and select the template for the rating email template. 4. Then change the stage of any task. check the email and give a rating to your task. 5. Check the Discus app then you will see a notification and no space between the name of the task and the calendar icon. Issue: ----------------------------------------------------------------------------------------------------------- - A missing space between the name of the task and the calendar icon. Cause: ----------------------------------------------------------------------------------------------------------- - The task's name and the calendar icon are not separated. Fix: ----------------------------------------------------------------------------------------------------------- - After this commit there is a space between the name of the task and the calendar icon task-3681318 Forward-Port-Of: odoo/odoo#151700
The migration method from old config files to the new `odoo.conf` searched for a file named `subject` instead of `odoo-subject.conf`. Forward-Port-Of: odoo/odoo#179861
Original PR description
The migration method from old config files to the new `odoo.conf` searched for a file named `subject` instead of `odoo-subject.conf`. Forward-Port-Of: odoo/odoo#179861
Steps to reproduce the issue: ============================= - Switch to dark mode - Go to any record with a chatter - Open mail composer in log note - Add a table - Save - Switch to light mode - The table is still dark Origin of the issue: ==================== Since in dark mode we add some styles to improve the display, those styles are getting applied in convert_inline. Solution: ========= Skip the stylesheets for table that have color only for now since skipping all styles
Original PR description
Steps to reproduce the issue: ============================= - Switch to dark mode - Go to any record with a chatter - Open mail composer in log note - Add a table - Save - Switch to light mode - The…
Steps to reproduce the issue: ============================= - Switch to dark mode - Go to any record with a chatter - Open mail composer in log note - Add a table - Save - Switch to light mode - The table is still dark Origin of the issue: ==================== Since in dark mode we add some styles to improve the display, those styles are getting applied in convert_inline. Solution: ========= Skip the stylesheets for table that have color only for now since skipping all styles can produce more issues. We skip also the background-color and border color for light mode too because they will not display the same in dark mode. Before: ======   After: =====   opw-4137267 Forward-Port-Of: odoo/odoo#178520
Previously, setting the `size` prop to `fullscreen` in the `Dialog` component caused an error in debug mode, as the `fullscreen` utility class from Bootstrap was not included in the props. This commit resolves the issue by allowing the `fullscreen` option in the `size` props, ensuring compatibility with Bootstrap's utility classes. Forward-Port-Of: odoo/odoo#179627 Forward-Port-Of: odoo/odoo#174588
Original PR description
Previously, setting the `size` prop to `fullscreen` in the `Dialog` component caused an error in debug mode, as the `fullscreen` utility class from Bootstrap was not included in the props. This commit resolves the issue by allowing the `fullscreen` option in the `size` props, ensuring compatibility with Bootstrap's utility classes. Forward-Port-Of: odoo/odoo#179627 Forward-Port-Of: odoo/odoo#174588
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Dr
Original PR description
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we…
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Draw. ## Solution: We should take into account that it makes sense that everytime we update if our signature is empty, we update the state of the buttons accordingly avoiding this way to be able to sign without an actual sing. The solution address a similar approach at what was already being done with the onChangeName, we move this logic to be handled by a specific function for this buttons 'handleButtonStateChange'. The fix is part of > [#61981](https://github.com/odoo/enterprise/pull/61981) opw-3874034 Forward-Port-Of: odoo/odoo#178303 Forward-Port-Of: odoo/odoo#164410
Change ----- Take into account the case where the key is 0, which is falsy. Currently 0 acts the same as backspace. Steps ----- 1. Enable PIN identification in Attendances settings. 2. Attendances > Kiosk mode > Identify manually. opw-4155987 Forward-Port-Of: odoo/odoo#179501
Original PR description
Change ----- Take into account the case where the key is 0, which is falsy. Currently 0 acts the same as backspace. Steps ----- 1. Enable PIN identification in Attendances settings. 2. Attendances > Kiosk mode > Identify manually. opw-4155987 Forward-Port-Of: odoo/odoo#179501
Check identity would previously store a wrong password until the next grabage collection. This commit fix this behaviour. Forward-Port-Of: odoo/odoo#179960 Forward-Port-Of: odoo/odoo#179866
Original PR description
Check identity would previously store a wrong password until the next grabage collection. This commit fix this behaviour. Forward-Port-Of: odoo/odoo#179960 Forward-Port-Of: odoo/odoo#179866
### NOT FOR MASTER **17.0 -> Master - 0.1** Steps to reproduce the bug: - Go to Time Off -> Allocation -> Create - put a name - change the allocation type -> the name is reset Expected result: The name should not be reset to the old value Reason: The displayed name is relies on the private_name field to get its value. And thus every time an onchange is triggered the name is reset. Fix: Put the private_name field in the form view instead of the name field. Because we rely
Original PR description
### NOT FOR MASTER **17.0 -> Master - 0.1** Steps to reproduce the bug: - Go to Time Off -> Allocation -> Create - put a name - change the allocation type -> the name is reset Expected result: The name should not be reset to the old value Reason: The displayed name is relies on the private_name field to get its value. And thus every time an onchange is triggered the name is reset. Fix: Put the private_name field in the form view instead of the name field. Because we rely on the onchange of name on the dashboard to task-3713656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153044
Before 020ddc3a we allowed any Python identifier as column names. The usual field definition `name = fields.FieldType(...)` restricts `name` to be a valid Python identifier. Forbidding it in 17.0 causes issues during upgrades. For example, with the model: ```py class CustomModel(models.Model): _name = 'mymodule.custom.model' _description = "custom" année = fields.Char() ``` In 17.0 before this patch we get errors like: ``` File "/home/odoo/src/odoo/17.0/odoo/tools/
Original PR description
Before 020ddc3a we allowed any Python identifier as column names. The usual field definition `name = fields.FieldType(...)` restricts `name` to be a valid Python identifier. Forbidding it in 17.0…
Before 020ddc3a we allowed any Python identifier as column names. The usual field definition `name = fields.FieldType(...)` restricts `name` to be a valid Python identifier. Forbidding it in 17.0 causes issues during upgrades.
For example, with the model:
```py
class CustomModel(models.Model):
_name = 'mymodule.custom.model'
_description = "custom"
année = fields.Char()
```
In 17.0 before this patch we get errors like:
```
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 150, in identifier
assert IDENT_RE.match(name), f"{name!r} invalid for SQL.identifier()"
^^^^^^^^^^^^^^^^^^^^
AssertionError: 'année' invalid for SQL.identifier()
```
### Possible issue during upgrade from < `17.0` to >= `17.0`:
1. Install fresh db in `16.0`
2. Add custom field `année` to the `res.users` with custom module
3. Go to `Settings --> Manage Users` add the field `année` in the list view
by installing studio
4. Upgrade to `17.0`
You will get error like this:
```
('base.menu_action_res_users', 64, 'Settings > Users & Companies > Users', 70):
Traceback (most recent call last):
File "/tmp/tmpcmtylywh/migrations/base/tests/test_mock_crawl.py", line 256, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpcmtylywh/migrations/base/tests/test_mock_crawl.py", line 429, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpcmtylywh/migrations/base/tests/test_mock_crawl.py", line 557, in mock_view_tree
self.mock_web_search_read(model, view, [domain], fields_list)
File "/tmp/tmpcmtylywh/migrations/base/tests/test_mock_crawl.py", line 591, in mock_web_search_read
data = model.search_read(domain=domain, fields=fields_list, limit=80)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 5756, in search_read
records = self.search_fetch(domain or [], fields, offset=offset, limit=limit, order=order)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 1648, in search_fetch
return self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/res_users.py", line 545, in _fetch_query
records = super()._fetch_query(query, fields)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3929, in _fetch_query
sql = self._field_to_sql(self._table, field.name, query)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 2863, in _field_to_sql
return SQL.identifier(alias, fname)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 153, in identifier
assert IDENT_RE.match(subname), f"{subname!r} invalid for SQL.identifier()"
AssertionError: 'année' invalid for SQL.identifier()
```
Actually, the issue can occur anywhere that the new `SQL.Identifier()` is used.
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#179863The modules `account_audit_trail` and `account_lock` cannot be uninstalled since [1]. The issue is that the error message displayed to the end user is not specific enough and causes confusion when people are not directly uninstalling the module, but rather another module that happen to trigger the uninstallation of `account_audit_trail` or `account_lock` (`account` for example). After this commit the human readable and technical name of the module are displayed in the error message w
Original PR description
The modules `account_audit_trail` and `account_lock` cannot be uninstalled since [1]. The issue is that the error message displayed to the end user is not specific enough and causes confusion when people are not directly uninstalling the module, but rather another module that happen to trigger the uninstallation of `account_audit_trail` or `account_lock` (`account` for example). After this commit the human readable and technical name of the module are displayed in the error message which should allow the end user to either have a better understanding of why the operation is impossible or should not be performed, or at the very least will help them go check the description of the right modules to get further information. [1] https://github.com/odoo/odoo/pull/171244 opw-4172056 Forward-Port-Of: odoo/odoo#179601
Have a form view with an x2many field displayed as a list or kanban. Create a new record, and have an onchange/default value for that x2many that returns more commands 0 (create) than the limit. Before this commit, all records where displayed on the first page (as expected when new records are created in an x2many) but the pager was displayed. Then, if you went to the second page, you would see records in the reverse order. This commit fixes the order issue by inserting records in the correct
Original PR description
Have a form view with an x2many field displayed as a list or kanban. Create a new record, and have an onchange/default value for that x2many that returns more commands 0 (create) than the limit. Before this commit, all records where displayed on the first page (as expected when new records are created in an x2many) but the pager was displayed. Then, if you went to the second page, you would see records in the reverse order. This commit fixes the order issue by inserting records in the correct order when processing commands. But in the meantime, it also fixes the fact that a pager was displayed. Issue reported on discord (more details here [1]) [1] odoo/odoo#179650 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#179674
Since 17.0 and [renderToElement], the snippet is rerendered (and thus starts anew) on every key input in the descriptions options. The donation's publicWidget fetches the currency to display every time on start, meaning that it does a query on every key press. This also triggers jumps on the screen. To avoid both issues, this commit caches the currency for the duration of the publicWidget life. [renderToElement]: f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b task-4032975 Forward-Port-Of: odoo
Original PR description
Since 17.0 and [renderToElement], the snippet is rerendered (and thus starts anew) on every key input in the descriptions options. The donation's publicWidget fetches the currency to display every time on start, meaning that it does a query on every key press. This also triggers jumps on the screen. To avoid both issues, this commit caches the currency for the duration of the publicWidget life. [renderToElement]: f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b task-4032975 Forward-Port-Of: odoo/odoo#171788
Before this commit: Previously, when creating automation rules, users could select models that did not have any fields. This would result in either an invalid domain warning or an error. Steps to reproduce: - Install base_automation. - Navigate to Settings > Technical > Automation > Automation Rules. - Give an appropriate name to the rule and select base as the model. After this commit: Users will no longer be able to create automation rules for models without fields. Task
Original PR description
Before this commit: Previously, when creating automation rules, users could select models that did not have any fields. This would result in either an invalid domain warning or an error. Steps to reproduce: - Install base_automation. - Navigate to Settings > Technical > Automation > Automation Rules. - Give an appropriate name to the rule and select base as the model. After this commit: Users will no longer be able to create automation rules for models without fields. Task-3874560 --- Forward-Port-Of: odoo/odoo#163117
Some translations were missing in the DIN5008 modules. This commit updates the terms and completes missing translations. [opw-3961574](https://www.odoo.com/odoo/project.task/3961574?cids=1) Forward-Port-Of: odoo/odoo#175435 Forward-Port-Of: odoo/odoo#175360
Original PR description
Some translations were missing in the DIN5008 modules. This commit updates the terms and completes missing translations. [opw-3961574](https://www.odoo.com/odoo/project.task/3961574?cids=1) Forward-Port-Of: odoo/odoo#175435 Forward-Port-Of: odoo/odoo#175360
# Main changes: Always show the expiration date on the move lines of concerned products. # Before: Show a warning when the expiration date has been reached. # After: Show the expiration date of the product if it has one. Rather than showing an alert if the expiration date has been reached, set the text-danger bootstrap class on the expiration date. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143323
Original PR description
# Main changes: Always show the expiration date on the move lines of concerned products. # Before: Show a warning when the expiration date has been reached. # After: Show the expiration date of the product if it has one. Rather than showing an alert if the expiration date has been reached, set the text-danger bootstrap class on the expiration date. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143323
Duplicating languages wasn't possible because no logic was added to it, so it threw an error whenever trying to duplicate a language. The main reason is that when you try to duplicate a language, the ORM tries to create a new record with the same fields. However, the `name`, `code` , and `url_code` fields should be unique. This commit adds the needed logic to handle duplicating languages by adding a `(copy)` postfix to the fields. Task-4141689 Forward-Port-Of: odoo/odoo#179926 Forward-Port-O
Original PR description
Duplicating languages wasn't possible because no logic was added to it, so it threw an error whenever trying to duplicate a language. The main reason is that when you try to duplicate a language, the ORM tries to create a new record with the same fields. However, the `name`, `code` , and `url_code` fields should be unique. This commit adds the needed logic to handle duplicating languages by adding a `(copy)` postfix to the fields. Task-4141689 Forward-Port-Of: odoo/odoo#179926 Forward-Port-Of: odoo/odoo#179686
[FIX] website: avoid page template to crash at preview removed Steps to reproduce: - On the website, click on "New" then "Page" to create a new page. - On the blank page, click on "Use this template". - Insert a file name (e.g. `rte_translator.xml`) and click on 'Create'. -> If the last operation was fast enough a traceback of type `TypeError: Cannot read properties of null (reading 'fonts')` can occur. Note that to be able to reproduce the problem, a delay may have to be added in th
Original PR description
[FIX] website: avoid page template to crash at preview removed Steps to reproduce: - On the website, click on "New" then "Page" to create a new page. - On the blank page, click on "Use this…
[FIX] website: avoid page template to crash at preview removed Steps to reproduce: - On the website, click on "New" then "Page" to create a new page. - On the blank page, click on "Use this template". - Insert a file name (e.g. `rte_translator.xml`) and click on 'Create'. -> If the last operation was fast enough a traceback of type `TypeError: Cannot read properties of null (reading 'fonts')` can occur. Note that to be able to reproduce the problem, a delay may have to be added in the `onceAllImagesLoaded` method and the operations of file name insertion and page creation have to be quite quick (you can for example use the `rte_translator` test tour). Since [this commit], it is possible to create new pages from templates. The problem here is that the template preview is removed before the `onMounted()` operation of the `AddPageTemplatePreview` component finished. Due to it, the content document of the preview iframe is not set and trying to search for its `fonts` leads to an error. This commit fixes this issue by ensuring that the component has not been destroyed before continuing its `onMounted()` process. [this commit]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7 Forward-Port-Of: odoo/odoo#179894
7 changes
Enhancements to existing features
Australian payroll now uses the shared payroll period calculation method instead of a separate custom list. This keeps pay period handling more consistent and easier to maintain, with no expected change for day-to-day users.
Original PR description
After this commit, instead of using a dictionary, we will use a standard method to get the factors of a pay period in `l10n_au_hr_payroll`. task-4029012
Resolved issues and error corrections
This fix aligns asset-related screens with the newer "list" view naming instead of the older "tree" wording. It helps keep the interface and configuration consistent with recent platform changes, reducing small display or compatibility issues.
Original PR description
[FIX] base/ir.ui.view: fix use 'list' instead of 'tree' see: https://github.com/odoo/odoo/pull/159909
Code cleanup and technical improvements
Accounting reports now consistently receive prior report settings instead of sometimes receiving no settings at all. This internal cleanup reduces the risk of reporting errors and makes future maintenance of financial reports easier without changing day-to-day user workflows.
Original PR description
Keeping `previous_options` as None is error-prone and can be made simpler. This commit makes `previous_options` a mandatory parameter. Task ID: 3977823
This draft refactors automated tour tests across several Odoo Enterprise apps, including accounting, helpdesk, manufacturing, signing, and rental flows. The changes are internal and should help maintain test reliability without changing day-to-day user workflows.
Miscellaneous changes
…nvoice Before this commit, subscriptions automatic invoices are skipped when the flag pending transactions is set. it is correct to avoid double payment for the same period but there is a problem if the flag stays while the subscription has been renewed since. This commit aimes to remove that flag when an invoice is posted for this subscruption. taskid: 4107185 Forward-Port-Of: odoo/enterprise#69589 Forward-Port-Of: odoo/enterprise#68713
Original PR description
…nvoice Before this commit, subscriptions automatic invoices are skipped when the flag pending transactions is set. it is correct to avoid double payment for the same period but there is a problem if the flag stays while the subscription has been renewed since. This commit aimes to remove that flag when an invoice is posted for this subscruption. taskid: 4107185 Forward-Port-Of: odoo/enterprise#69589 Forward-Port-Of: odoo/enterprise#68713
The Helpdesk forum tour relies on the forum containing at least one post. This PR manually creates a post in python before launching the tour. Task-4143944 Forward-Port-Of: odoo/enterprise#69066
Original PR description
The Helpdesk forum tour relies on the forum containing at least one post. This PR manually creates a post in python before launching the tour. Task-4143944 Forward-Port-Of: odoo/enterprise#69066
Currently, when a user requests an invoice from a POS ticket under a Mexican company, the CFDI document attached to the invoice incorrectly uses the buyer's name instead of using the provided company name. ### Steps to reproduce * install `l10n_mx_edi_pos` * Switch to a Mexican company * the settings enable "Generate a code on ticket" * validate a POS order * follow the instructions on the ticket to generate an invoice. Make sure to provide a company name on the customer form. When
Original PR description
Currently, when a user requests an invoice from a POS ticket under a Mexican company, the CFDI document attached to the invoice incorrectly uses the buyer's name instead of using the provided company name. ### Steps to reproduce * install `l10n_mx_edi_pos` * Switch to a Mexican company * the settings enable "Generate a code on ticket" * validate a POS order * follow the instructions on the ticket to generate an invoice. Make sure to provide a company name on the customer form. When checking the XML file that is forwarded to the Mexican tax authorities, you see that only the "individual name" is registered there as the buyer, when it should be the company name. opw-4103543 opw-4071503 Forward-Port-Of: odoo/enterprise#69872 Forward-Port-Of: odoo/enterprise#69126