Thursday, September 12, 2024
27 changes · saas-17.2
Resolved issues and error corrections
Printer actions triggered through IoT longpolling now include the required print identifier. This prevents errors that could interrupt printing workflows after the saas-17.2 update.
Original PR description
Starting as from `saas-17.2`, PrinterDriver's default action requires a `print_id`, which was not provided by the longpolling service action method. We added the missing parameter to avoid the traceback created by this error.
Corrects the Ecuador EDI module setup so it no longer installs automatically when only the Ecuador localization is selected. This avoids enabling extra electronic invoicing features unexpectedly and keeps installations aligned with user intent.
Original PR description
The country was wrongly re-put (being merged around the same time). It prevents auto-installation of the module when only install l10n_ec runbot-74140
Miscellaneous changes
When ```KE eTIMS: Fetch KRA notices from eTIMS``` cron runs and eTIMS API returns an error, a traceback will appear. Steps to reproduce the error: - Install ```l10n_ke_edi_oscu``` - Set up Kenya eTIMS Integration - Run ```KE eTIMS: Fetch KRA notices from eTIMS``` cron Traceback: ``` KeyError: 'noticeList' File "odoo/tools/safe_eval.py", line 391, in safe_eval return unsafe_eval(c, globals_dict, locals_dict) File "ir.actions.server(909,)", line 1, in <module> File "home/
Original PR description
When ```KE eTIMS: Fetch KRA notices from eTIMS``` cron runs and eTIMS API returns an error, a traceback will appear. Steps to reproduce the error: - Install ```l10n_ke_edi_oscu``` - Set up Kenya…
When ```KE eTIMS: Fetch KRA notices from eTIMS``` cron runs and eTIMS API returns
an error, a traceback will appear.
Steps to reproduce the error:
- Install ```l10n_ke_edi_oscu```
- Set up Kenya eTIMS Integration
- Run ```KE eTIMS: Fetch KRA notices from eTIMS``` cron
Traceback:
```
KeyError: 'noticeList'
File "odoo/tools/safe_eval.py", line 391, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(909,)", line 1, in <module>
File "home/odoo/src/enterprise/saas-17.4/l10n_ke_edi_oscu/models/l10n_ke_edi_oscu_notice.py", line 35, in _cron_l10n_ke_oscu_get_notices
notice_map = {notice['noticeNo']: notice for notice in data['noticeList']}
ValueError: <class 'KeyError'>: "noticeList" while evaluating
'model._cron_l10n_ke_oscu_get_notices()'
File "odoo/addons/base/models/ir_cron.py", line 562, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 989, in run
res = runner(run_self, eval_context=eval_context)
File "addons/website/models/ir_actions_server.py", line 61, in _run_action_code_multi
res = super(ServerAction, self)._run_action_code_multi(eval_context)
File "odoo/addons/base/models/ir_actions.py", line 821, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 405, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
https://github.com/odoo/enterprise/blob/019a7cdd5a3071c0948656bdcacc95b63c2e8842/l10n_ke_edi_oscu/models/l10n_ke_edi_oscu_notice.py#L35 When eTIMS API returns an error, data will be empty,
So, it will lead to the above traceback.
sentry-5804573762, 5809459581
Forward-Port-Of: odoo/enterprise#69727To reproduce: Create an invoice, in foreign currency. Use a withholding tax, like 10% ILA Post the invoice => The rendering of the dte fails It's still using a deprecated method, which has been removed after 16. no task Forward-Port-Of: odoo/enterprise#69769
Original PR description
To reproduce: Create an invoice, in foreign currency. Use a withholding tax, like 10% ILA Post the invoice => The rendering of the dte fails It's still using a deprecated method, which has been removed after 16. no task Forward-Port-Of: odoo/enterprise#69769
### 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/enterprise#67931
## 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 > [#164410](https://github.com/odoo/odoo/pull/164410) opw-3874034 Forward-Port-Of: odoo/enterprise#69108 Forward-Port-Of: odoo/enterprise#61981
Installation of l10n_mx_edi_stock_30 module can fail due to memory limit Having a large number of "stock.picking" records causes this due to the computations of the initial values of fields. Solving this requires creating the field columns and assigning the values manually, by overriding the _auto_init method. This allows us to skip the computations, to avoid the memory limit. opw-3846355 Forward-Port-Of: odoo/enterprise#65830 Forward-Port-Of: odoo/enterprise#60948
Original PR description
Installation of l10n_mx_edi_stock_30 module can fail due to memory limit Having a large number of "stock.picking" records causes this due to the computations of the initial values of fields. Solving this requires creating the field columns and assigning the values manually, by overriding the _auto_init method. This allows us to skip the computations, to avoid the memory limit. opw-3846355 Forward-Port-Of: odoo/enterprise#65830 Forward-Port-Of: odoo/enterprise#60948
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#69126
This commit will allow to hide the sepa uetr depending on the pain version and the payment method. task: 4167726 Forward-Port-Of: odoo/enterprise#69659
Original PR description
This commit will allow to hide the sepa uetr depending on the pain version and the payment method. task: 4167726 Forward-Port-Of: odoo/enterprise#69659
### 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