Friday, October 18, 2024
58 changes · 18.0
Enhancements to existing features
Odoo can now control how long on-screen notifications stay visible before disappearing automatically. This helps teams tailor messages so important notices remain visible longer while routine alerts can clear faster.
Original PR description
In this commit, we introduce a way to customize the duration it takes for a notification to automatically disappear which is achieved by specifying `autocloseDelay` option in ms. Documentation: https://github.com/odoo/documentation/pull/11219
Resolved issues and error corrections
Invoice reports now display the tax section correctly when an invoice uses a different currency and includes taxes. This prevents totals such as the untaxed amount from appearing in the wrong place, making printed or shared invoices clearer for customers and accounting teams.
Original PR description
If you have an invoice with a different currency, and with taxes, the layout of the Taxes box in company currency has a weird placement with the Untaxed Amount task-4269524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this commit, styling is used to hide the empty option when the selection is required. Option elements don't support CSS styling properties in Chrome and Safari[^1] Now, the empty option will not be rendered if the selection is required. [^1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#styling_with_css Forward-Port-Of: odoo/odoo#184175 Forward-Port-Of: odoo/odoo#183614
Original PR description
Before this commit, styling is used to hide the empty option when the selection is required. Option elements don't support CSS styling properties in Chrome and Safari[^1] Now, the empty option will not be rendered if the selection is required. [^1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#styling_with_css Forward-Port-Of: odoo/odoo#184175 Forward-Port-Of: odoo/odoo#183614
This fixes a crash that happened when users pressed Escape while transforming an image in the editor. Image editing now exits cleanly, improving reliability when adding or adjusting images in apps such as To-do.
Original PR description
### Steps to Reproduce: - Open the to-do app - Add an image (/image, upload an image) - Select the image - Click the Transform button - Press the Escape key, and a traceback occurs ### Desired behavior after PR is merged: - Clicking the image transform button in `toolbar` clears the image selection and enables the image transformation. - Removes the `active` class from the image transformation button. task-4184571
Fixes an issue where documents added from a bill of materials line briefly appeared and then disappeared. The document visibility is now correctly set for bills of materials, so users can reliably attach and view related files in manufacturing workflows.
Original PR description
Since https://github.com/odoo/odoo/pull/176483, the product_document_kanban_controller methods have been modified but not in MRP. The same logic will be applied to mps. Before ------ When clicking on the document icon of a bom line, and then adding a document, the document whill shortly appear and then disappear because the visibility is not set on bom https://drive.google.com/file/d/1gXiqtU3zEoFP76ue2pk-0FHnf5MyRT-P/view After ----- The document visibility is set on 'bom' and the document is visible when added --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where filtering payments could fail because the payment reference field name had changed. This keeps payment lists usable and prevents users from seeing an error when applying the affected filter.
Original PR description
`ref` field has been replaced by `memo` field in `account.payment` model. task-id: 4261127 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The customer portal no longer offers sorting by stage or reference for quotations and sales orders, because those fields are not shown in the list. This avoids confusing choices and defaults the list to order date for a clearer customer experience.
Original PR description
Issue: - Customers could sort quotations and sale orders by stage and reference, which are not displayed in the list. Fix: - Remove sorting options for stage and reference, and default to sorting by order date. opw-4165724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could occur when opening vendor payments for Swiss companies and contacts. The Swiss localization now uses the updated payment note field, so users can access these payments without interruption.
Original PR description
**Steps to reproduce:** - Install l10n_ch - Switch to a Swiss company (e.g. CH Company) - Go to "Invoicing / Vendors / Payments" - Select a Swiss contact as vendor **Issue:** A traceback is raised while trying to access "ref" field of "account.payment" model. **Cause:** "ref" field has been replaced by "memo" field in "account.payment" model. opw-4244999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restaurant floor screens now clear paid floating orders after checkout. This prevents staff from seeing already completed orders as still active, reducing confusion during service.
Original PR description
Steps: - Open the restaurant. - Create a floating order and validate it. - Navigate to the floor screen. - Floating order is still displayed. Issue: - Floating orders remain visible on the floor screen after payment. Cause: - The selected order does not reset when order has no assigned table. Fix: - Reset the selected order for all restaurant orders. Task-4251902
Removing a country from a company record no longer triggers an unexpected error. This improves reliability for users maintaining company information in accounting settings.
Original PR description
When the user removes the country from the company, a traceback will appear. Steps to reproduce the error: - Create a new company > Select any country > Save - Now, remove the country Traceback: ```…
When the user removes the country from the company,
a traceback will appear.
Steps to reproduce the error:
- Create a new company > Select any country > Save
- Now, remove the country
Traceback:
```
AttributeError: 'bool' object has no attribute 'lower'
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1010, in onchange
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1123, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 7000, in __getitem__
return self._fields[key].__get__(self)
File "odoo/fields.py", line 1287, in __get__
self.compute_value(recs)
File "odoo/fields.py", line 1469, in compute_value
records._compute_field_value(self)
File "addons/mail/models/mail_thread.py", line 427, in _compute_field_value
return super()._compute_field_value(field)
File "odoo/models.py", line 5243, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 109, in determine
return needle(*args)
File "addons/account/models/company.py", line 1014, in _compute_company_vat_placeholder
company.country_id.code.lower() or company.account_fiscal_country_id.code.lower()
```
https://github.com/odoo/odoo/blob/bc2106bfb401d98678fd9c727281bf20c1a0231e/addons/account/models/company.py#L1014
When the user removes the country, ``company.country_id.code`` will be False,
So, it will lead to the above traceback.
sentry-5996003549
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prAdministrators can now access all quote calculator spreadsheet templates from the technical settings. This makes it easier to clean up unused templates or import templates from JSON files without cluttering the Sales app menus.
Original PR description
Currently, there's no menu to get a list of all quote calculator spreadsheet templates. This commits adds a menu in the technical settings. It allows to: - delete/clean unused spreadsheet templates - import a template from its json file (BA do that quite often for dashboards, I expect they'll want to do it for spreadsheet quotation templates) Feedback from OXP Note: we don't add the menu in the Sales app menus because we don't want to add noise in there. It must be kept clean. Task: 4236559
The product form no longer shows an empty Accounting page to users who do not have the relevant accounting read-only access. This removes confusion for sales users by only displaying the page when meaningful accounting information can be shown.
Original PR description
Steps: - Install sale app. - Go to sale module. - Open product form. - Go to accounting page. Issue: - Empty accounting page. Cause: - In account_accountant module added invoice group to display accounting page even though there is no content added in that module to display which should be visible without have account readonly access. Fix: - Remove invoice group for stable to display that page only for readonly group. To-do master: Remove that view. opw-4209850
Users can now confirm multiple assets at once even when those assets use different journals. This prevents an error during depreciation confirmation and helps accounting teams process assets in bulk reliably.
Original PR description
Reproduce: * create an asset * duplicate it, and change the journal * in list view, compute the depreciation * in list view, confirm Traceback because we try to get the lock date related to multiple journals.
Documents added from a bill of materials line now remain visible instead of briefly appearing and disappearing. This ensures teams using manufacturing and PLM can reliably attach and view documents where they expect them.
Original PR description
Since [odoo/pull/176483](https://github.com/odoo/odoo/pull/176483), the product_document_kanban_controller methods have been modified but in MRP. This commit fixes it. Before ------ When clicking on the document icon of a bom line, and then adding a document, the document whill shortly appear and then disappear because the visibility is not set on bom https://drive.google.com/file/d/1gXiqtU3zEoFP76ue2pk-0FHnf5MyRT-P/view The same logic applies to PLM After ----- The document visibility is set on 'bom' and the document is visible when added
Opening a point-of-sale session no longer fails when UrbanPiper API credentials have not been entered. This prevents unnecessary blocking for users who do not need or have not yet configured the UrbanPiper integration.
Original PR description
Before this commit: === - When attempting to open a session, when there is no API key and username in pos_config, a validation error occurred. After this commit: === - No validation error occurs when the API key and username are missing in pos_config. task-4266405
Signature request emails now use one selected language consistently across both the email layout and message content. This prevents recipients from seeing mixed-language emails and improves the professionalism of translated communications.
Original PR description
Before this commit, the language of the logged in user and the language given in kwargs would be used to translate the content. The email layout would translate to the user language and the body content would use the kwarg's language. This lead to translation discrepancies. After this commit, only the language given in the kwargs is used and therefore fixing the translations issues.
Signature request emails now use the selected recipient language consistently across both the email layout and message content. This prevents mixed-language emails and improves the experience for customers receiving documents to sign.
Original PR description
Before this commit, the language of the logged in user and the language given in kwargs would be used to translate the content. The email layout would translate to the user language and the body content would use the kwarg's language. This lead to translation discrepancies. After this commit, only the language given in the kwargs is used and therefore fixing the translations issues.
This fix prevents an error when generating Indian payroll payment reports by correctly processing multiple report entries. It improves reliability for payroll teams without changing the report’s intended behavior.
Original PR description
The issue occurred because `vals_list` is a list of dictionaries, and calling `get()` on it caused an AttributeError. Updated the logic to iterate over the list and properly handle each dictionary entry.
Signing-related emails now use the requested recipient language consistently across both the email layout and message content. This prevents mixed-language emails and provides a clearer experience for customers receiving documents to sign.
Original PR description
Before this commit, the language of the logged in user and the language given in kwargs would be used to translate the content. The email layout would translate to the user language and the body content would use the kwarg's language. This lead to translation discrepancies. After this commit, only the language given in the kwargs is used and therefore fixing the translation issues.
This fixes an issue where saving a document folder without a name could display an incorrect placeholder value. Users will now be prompted to enter a valid folder name before saving, improving clarity and data quality.
Original PR description
When we save the folder without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4247496
Opening the backend appointment calendar from Point of Sale could fail because the system tried to read information that was not available. This fix adds a safeguard so users can open the view without encountering an error.
Original PR description
Issue: ========== - Modify the point of sale module manifest file as per the reference PR. Then, you get an error on runbot for accessing the tag value from null (check referenced PR runbot). Cause: ========== - When trying to open the backend appointment view in the point of sale, the current controller was not found. Consequently, the `_getCurrentAction()` method returns a null value, leading to an error when trying to access the tag value from null. FIX: ========== - We need to add a condition to avoid accessing a value from null. Related PR: Community: https://github.com/odoo/odoo/pull/181828 Enterprise: https://github.com/odoo/enterprise/pull/70891
Issue: ====== Going to next record in to do overrides the next record content with the older one. Steps to reproduce the issue: ============================== - Go to do and create 2 to-dos - Add an image using copy paste - Go to next record using the pager - The record has the same content as the first one Origin of the issue: ==================== The main reason behind the issue is a race condition. Basically there are 2 flows being executed in parallel: - First flow is from `o
Original PR description
Issue: ====== Going to next record in to do overrides the next record content with the older one. Steps to reproduce the issue: ============================== - Go to do and create 2 to-dos - Add an…
Issue: ====== Going to next record in to do overrides the next record content with the older one. Steps to reproduce the issue: ============================== - Go to do and create 2 to-dos - Add an image using copy paste - Go to next record using the pager - The record has the same content as the first one Origin of the issue: ==================== The main reason behind the issue is a race condition. Basically there are 2 flows being executed in parallel: - First flow is from `onWysiygBlur` which calls commit changes and save image changes. Since we have an image in the content, it will take longer to finish. the commit that was called now is fron emty content to the base64 image. - The scond flow comes from the pager update which finds the content dirty because its old content is the base64 image ans its new content is the image with the url so it will call commit changes itself and it will load the next id. - Currently we have the `_update` of the `commitChanges` from the `blur` event isn't done yet but we already changed the id of the record to the id of the new recod (comes fron pager). - Now when the `_update` of the old `blur` event is executed, it will update the body of the new record and not the old record. Solution: ========= If the html field is already saving sonething we wait for it first. so In our case, the commit changes of the paged will do nothing since it will wait for the one of the `blur` event and the editable after it will be not dirty. task-4082860 Forward-Port-Of: odoo/odoo#184147
A previous commit [1] fixed a bug where multiple "table of content" snippets were hidden in "mobile" view on a page (see commit message). However, this did not fix all cases. It is likely that with even more hidden elements on the page, the problem remains unresolved. We thought that await the start would solve the issue, but in some cases, the start wasn't even triggered by the time we reached the destroy. This commit fixes the issue by checking that the "this._scrollTarget" variable i
Original PR description
A previous commit [1] fixed a bug where multiple "table of content" snippets were hidden in "mobile" view on a page (see commit message). However, this did not fix all cases. It is likely that with even more hidden elements on the page, the problem remains unresolved. We thought that await the start would solve the issue, but in some cases, the start wasn't even triggered by the time we reached the destroy. This commit fixes the issue by checking that the "this._scrollTarget" variable is initialized before removing its listener in the destroy. This bug requires more investigation, but this fix solves the issue for now. [1]: https://github.com/odoo/odoo/commit/ac5e9fe93c2158be1e8555de3da1419c69f543e5 task-4160033 opw-4228666 opw-4220959 opw-4226783 Forward-Port-Of: odoo/odoo#183947
Before this commit, the pricelist was not considered when displaying product prices in the self-ordering, leading to incorrect pricing information. This commit ensures that the pricelist is correctly applied. opw-4190268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182884
Original PR description
Before this commit, the pricelist was not considered when displaying product prices in the self-ordering, leading to incorrect pricing information. This commit ensures that the pricelist is correctly applied. opw-4190268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182884
- open a composer in full view - click to save a template - close the modal before saving/cancelling - get a traceback The issue is that `onClose` when passed to an action is called even if the dialog closed did not come from the original action. This seems intended as documented by `_removeDialog`. `onClose` needs to be able to handle the composer not being in the DOM at all. task-4246399 Forward-Port-Of: odoo/odoo#183107
Original PR description
- open a composer in full view - click to save a template - close the modal before saving/cancelling - get a traceback The issue is that `onClose` when passed to an action is called even if the dialog closed did not come from the original action. This seems intended as documented by `_removeDialog`. `onClose` needs to be able to handle the composer not being in the DOM at all. task-4246399 Forward-Port-Of: odoo/odoo#183107
Before this PR, if you changed the time format in the language, the Gantt and the form view of the attendance did not follow those formats. With this PR, the dates displayed in the Gantt and form view are based on the time format set in the language. Task-4098672 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183828 Forward-Port-Of: odoo/odoo#176599
Original PR description
Before this PR, if you changed the time format in the language, the Gantt and the form view of the attendance did not follow those formats. With this PR, the dates displayed in the Gantt and form view are based on the time format set in the language. Task-4098672 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183828 Forward-Port-Of: odoo/odoo#176599
### Steps to reproduce: - Enable "Multi-steps Routes" in the settings - Inventory > COnfiguration > Warehouse Management > Warehouses - Change your warehouse settings to Deliver in 2 steps - Create a Storable product P with 10 units in stock - Create and confirm an SO for 1 unit of P > A pick and a ship deliveries were created. - Unreserve the PICK deliveries - Go to the forecast of your product avaialbility #### > the SO is unreconcilled and the product is treated as unavailable #
Original PR description
### Steps to reproduce: - Enable "Multi-steps Routes" in the settings - Inventory > COnfiguration > Warehouse Management > Warehouses - Change your warehouse settings to Deliver in 2 steps - Create a…
### Steps to reproduce: - Enable "Multi-steps Routes" in the settings - Inventory > COnfiguration > Warehouse Management > Warehouses - Change your warehouse settings to Deliver in 2 steps - Create a Storable product P with 10 units in stock - Create and confirm an SO for 1 unit of P > A pick and a ship deliveries were created. - Unreserve the PICK deliveries - Go to the forecast of your product avaialbility #### > the SO is unreconcilled and the product is treated as unavailable ### Cause of the issue: Since you unreserved the PICK delivery, the demand of the outgoing move is not null in the forecast lines computations: https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L278 In addition, since you deliver in 2 steps the outgoing moves are part of a move chain. To generate this chain, the moves were created with an `make_to_order` `procure_method` and as such, the quantity considered to reconcile this move from stock is set to be at 0 here: https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L283-L287 Furthermore, since there is no incoming moves made to reconcile this outgoing move (whcih happen for real "MTO" moves and not these flagged as MTO because they were part of a chain) the line will be created here and flagged as not repleinshed nor available: https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L295-L299 The forecast error ### Note: The issue is not reproducible in 16.0 since the forecast datas computed by the `_get_report_lines` was drastically prior to the 17.0 version. opw-4164403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183914 Forward-Port-Of: odoo/odoo#183211
There are two paths for a successful login via web_totp 1. The user has a cookie saved which saves them from having to enter the TOTP 2. The user is a new device / browser, enter the TOTP and a form is submitted Both call self._login_redirect but only the latter updates the env and context. This is a snippet to reproduce the bug: ```python @http.route() def web_totp(): response = super().web_totp(*args, **kw) if not request.env.user or request.env.user.is_public:
Original PR description
There are two paths for a successful login via web_totp 1. The user has a cookie saved which saves them from having to enter the TOTP 2. The user is a new device / browser, enter the TOTP and a form…
There are two paths for a successful login via web_totp
1. The user has a cookie saved which saves them from having to enter the TOTP
2. The user is a new device / browser, enter the TOTP and a form is submitted
Both call self._login_redirect but only the latter updates the env and context.
This is a snippet to reproduce the bug:
```python
@http.route()
def web_totp():
response = super().web_totp(*args, **kw)
if not request.env.user or request.env.user.is_public:
return response
do_something()
...
```
This would call `do_something` only when a user successfully logs in by putting the TOTP explicitly but not when they log in thanks to a cookie being set.
Description of the issue/feature this PR addresses:
Makes web_totp consistent for the 2 flows (submit totp or use cookie)
Current behavior before PR:
A code logic that works for web_login does not work for web_totp, or rather, it works only for one flow but not the other
Desired behavior after PR is merged:
A code logic that works for web_login also works for web_totp
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#183838### Steps to reproduce: - Open the To-do app. - Enter /link and provide a label. - Type / (e.g., /web) in the link dialog to preload available links. - Use the arrow keys to select a link from the dropdown. - Press Enter. - Edit the link again and check the result. ### Description of the issue/feature this PR addresses: Selecting a link from the dropdown with Enter would directly apply the link in the dialog, ignoring the selected dropdown link. ### Desired behavior after PR is
Original PR description
### Steps to reproduce: - Open the To-do app. - Enter /link and provide a label. - Type / (e.g., /web) in the link dialog to preload available links. - Use the arrow keys to select a link from the dropdown. - Press Enter. - Edit the link again and check the result. ### Description of the issue/feature this PR addresses: Selecting a link from the dropdown with Enter would directly apply the link in the dialog, ignoring the selected dropdown link. ### Desired behavior after PR is merged: Selecting a link from dropdown with Enter now correctly updates the link dialog with the selected link, and pressing Enter again applies the updated link. Forward-Port-Of: odoo/odoo#183753
Currently, it is not possible to inherit the company selector widget. To modify the behavior of the widget, developers need to create a new one instead of inheriting it, which is not ideal. This commit introduces changes that allow inheriting the company selector widget and also makes it easier to replace or extend the CompanySelector class within the SwitchCompanyMenu. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1
Original PR description
Currently, it is not possible to inherit the company selector widget. To modify the behavior of the widget, developers need to create a new one instead of inheriting it, which is not ideal. This commit introduces changes that allow inheriting the company selector widget and also makes it easier to replace or extend the CompanySelector class within the SwitchCompanyMenu. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179330 Forward-Port-Of: odoo/odoo#175094
Current behavior before PR: -Nested list numbering appeared differently in the preview compared to printed PDFs, causing inconsistencies in document appearance. Desired behavior after PR is merged: -Nested list numbering appears consistent between the preview and printed PDFs. task-4008883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172626
Original PR description
Current behavior before PR: -Nested list numbering appeared differently in the preview compared to printed PDFs, causing inconsistencies in document appearance. Desired behavior after PR is merged: -Nested list numbering appears consistent between the preview and printed PDFs. task-4008883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172626
Order of company values on reports is different in most of local software in Slovakia. Fix is only cosmetic to follow standards. This commit changes order of specific company values on report_template & report_invoice. Order before commit: vat (IČ DPH) company_registry (IČO) income_tax_id (DIČ) Order after commit: company_registry (IČO) income_tax_id (DIČ) vat (IČ DPH) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-
Original PR description
Order of company values on reports is different in most of local software in Slovakia. Fix is only cosmetic to follow standards. This commit changes order of specific company values on report_template & report_invoice. Order before commit: vat (IČ DPH) company_registry (IČO) income_tax_id (DIČ) Order after commit: company_registry (IČO) income_tax_id (DIČ) vat (IČ DPH) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182156
### Steps to reproduce the issue: 1. Give user full accounting access rights and no administrative access rights 2. With said user, create analytic plan 3. Following access error is shown: > You are not allowed to modify 'Fields' (ir.model.fields) records. > > This operation is allowed for the following groups: > - Administration/Access Rights ### Explanation: With commit odoo/odoo@0fe0246b0d5a0e372e69fbae2b5a2f61143eb93f, a `sudo` has been mistakenly removed in `_fi
Original PR description
### Steps to reproduce the issue: 1. Give user full accounting access rights and no administrative access rights 2. With said user, create analytic plan 3. Following access error is shown: > You are not allowed to modify 'Fields' (ir.model.fields) records. > > This operation is allowed for the following groups: > - Administration/Access Rights ### Explanation: With commit odoo/odoo@0fe0246b0d5a0e372e69fbae2b5a2f61143eb93f, a `sudo` has been mistakenly removed in `_find_plan_column`. ### Fix reasoning: Adding `sudo` back and a test to make sure it does not happen again. opw-4201314 Forward-Port-Of: odoo/odoo#182657
Steps ----- - Install Employees app. - Have a user with "Settings" Administration rights and no "Employees" rights. - Open an employee profile, open "Work Information" tab and click on an employee in the organizational tree. ** Access error for `message_main_attachment_id` field ** Cause ----- We are checking if the user has access rights on the employee https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L294 and redirecting to th
Original PR description
Steps ----- - Install Employees app. - Have a user with "Settings" Administration rights and no "Employees" rights. - Open an employee profile, open "Work Information" tab and click on an employee in the organizational tree. ** Access error for `message_main_attachment_id` field ** Cause ----- We are checking if the user has access rights on the employee https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L294 and redirecting to the private employee if that's the case. However, this does't guarantee that the user has the `hr.group_hr_user` group necessary to access some fields that were added with `groups="hr.group_hr_user"` https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L122 opw-4096073 Forward-Port-Of: odoo/odoo#182726
Issue ----- The activities from the calendar, which should be today's meetings, are in some circumstances displaying meetings from the next day. Steps ----- - Set the user timezone to "Asia/Manila". - In Calendar, create a meeting early (before 18:00) the next day. - Check the activities (clock in the navbar), tomorrow's meeting appears. Cause ----- `datetime.datetime` objects are not timezone aware, and using the `replace` function on them will simply lead to a naive convers
Original PR description
Issue
-----
The activities from the calendar, which should be today's
meetings, are in some circumstances displaying meetings
from the next day.
Steps
-----
- Set the user timezone to "Asia/Manila".
- In Calendar, create a meeting early (before 18:00) the
next day.
- Check the activities (clock in the navbar), tomorrow's
meeting appears.
Cause
-----
`datetime.datetime` objects are not timezone aware, and using
the `replace` function on them will simply lead to a naive
conversion which causes potential issues.
Example:
```
import pytz
import datetime
dt = datetime.datetime(2024,1,1,0,0)
dt = dt.replace(tzinfo=pytz.timezone("Asia/Manila")).astimezone(pytz.UTC)
print(dt)
>>> 2024-01-01 15:56:00+00:00 # 1 day offset to expected result
```
Instead, it is better to use the pytz `localize` function.
opw-4142911
Forward-Port-Of: odoo/odoo#183808
Forward-Port-Of: odoo/odoo#181795When changing the move associated with the bank statement line we i.e. update the `amount_currency` field on the bank statement line. But currently we just set it to the `amount_currency` value of the suspense line. This may not be correct in case we also have other lines on the move: We should have (liquidity = suspense + other) and the `amount_currency` on the bank statement line expresses the liquidity (total amount) and not the suspense (residual amount). After this commit we also include t
Original PR description
When changing the move associated with the bank statement line we i.e. update the `amount_currency` field on the bank statement line. But currently we just set it to the `amount_currency` value of the suspense line. This may not be correct in case we also have other lines on the move: We should have (liquidity = suspense + other) and the `amount_currency` on the bank statement line expresses the liquidity (total amount) and not the suspense (residual amount). After this commit we also include the other lines in the computation. (Note: We cannot just use the liquidity line It is in journal currency / company currency but the `amount_currency` of the bank statement line may be in a foreign currency that is neither the company nor the journal currency.) enterprise PR which needs the change: https://github.com/odoo/enterprise/pull/71243 Forward-Port-Of: odoo/odoo#184003 Forward-Port-Of: odoo/odoo#182589
When the customer creates the workorder for MO and clicks on the Done button without saving the record, a traceback will appear. Steps to reproduce the error: - Create one MO > Work Orders > Add a line > Click on Dropdown > Click on Done Traceback: ``` IndexError: tuple index out of range File "odoo/http.py", line 2364, in __call__ response = request._serve_db() File "odoo/http.py", line 1891, in _serve_db return self._transactioning( File "odoo/http.py", line 1954,
Original PR description
When the customer creates the workorder for MO and clicks on the Done button without saving the record, a traceback will appear. Steps to reproduce the error: - Create one MO > Work Orders > Add a…
When the customer creates the workorder for MO and clicks on the Done button
without saving the record, a traceback will appear.
Steps to reproduce the error:
- Create one MO > Work Orders > Add a line > Click on Dropdown > Click on Done
Traceback:
```
IndexError: tuple index out of range
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_workorder.py", line 876, in action_mark_as_done
self.button_finish()
File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_workorder.py", line 303, in button_finish
return super().button_finish()
File "addons/mrp/models/mrp_workorder.py", line 661, in button_finish
workorder.with_context(bypass_duration_calculation=True).write(vals)
File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_workorder.py", line 114, in write
res = super().write(values)
File "addons/mrp/models/mrp_workorder.py", line 475, in write
if workorder == workorder.production_id.workorder_ids[0] and 'date_start' in values:
File "odoo/models.py", line 7004, in __getitem__
return self.browse((self._ids[key],))
```
https://github.com/odoo/odoo/blob/a082495359a2e6a2bf25cc3744eb80fd6899f5d1/addons/mrp/models/mrp_workorder.py#L462 Here, when customer clicks on the Done button without saving the record,
``workorder_ids`` will be empty, so it will lead to the above traceback.
https://github.com/odoo/odoo/blob/a082495359a2e6a2bf25cc3744eb80fd6899f5d1/addons/mrp/static/src/components/wo_list_view_dropdown/wo_list_view_dropdown.js#L52-L61
Here, ``ids`` is ``false`` because the record is not saved yet,
It will call the ``action_mark_as_done`` method with ``false`` ids,
eventually, it will generate the above traceback.
sentry-5973943945
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#183170This commit addresses an issue where selecting multiple attributes for a product in the self-order service could lead to errors. opw-4253601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184116
Original PR description
This commit addresses an issue where selecting multiple attributes for a product in the self-order service could lead to errors. opw-4253601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184116
The LATERAL was destroying perfs to compute the account roots. It took more than 7 sec on a db that only had 660k move lines. Replaced it by a simple JOIN which reduced it to 1.2 sec. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183458 Forward-Port-Of: odoo/odoo#170689
Original PR description
The LATERAL was destroying perfs to compute the account roots. It took more than 7 sec on a db that only had 660k move lines. Replaced it by a simple JOIN which reduced it to 1.2 sec. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183458 Forward-Port-Of: odoo/odoo#170689
The test_get_first_fiscal_position() was failing on the runbot since its addition. The failure occurred because the company's partner in the environment either had no country set or a different country from the two fiscal positions defined in the test. This led to incorrect or missing fiscal positions being selected in _get_fiscal_position(). The issue arose because other test classes modified the company’s country. To resolve this, the test partner is now explicitly assigned a country, and t
Original PR description
The test_get_first_fiscal_position() was failing on the runbot since its addition. The failure occurred because the company's partner in the environment either had no country set or a different country from the two fiscal positions defined in the test. This led to incorrect or missing fiscal positions being selected in _get_fiscal_position(). The issue arose because other test classes modified the company’s country. To resolve this, the test partner is now explicitly assigned a country, and the fiscal positions are defined with the same country to maintain consistent priority levels compared to existing fiscal positions. This ensures the test remains isolated from external factors, verifying that when two fiscal positions have identical attributes except for sequence, the one with the lowest sequence is prioritized. Runbot issue: 98910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184097
Before this commit you could revoke all devices but attempting to revoke a single one will have resulted in an error that this.orm was undefined. Forward-Port-Of: odoo/odoo#184113
Original PR description
Before this commit you could revoke all devices but attempting to revoke a single one will have resulted in an error that this.orm was undefined. Forward-Port-Of: odoo/odoo#184113
Prior to this commit, when a URL started with an underscore (_) and didn’t match any existing controller, Odoo attempted to resolve the first part of the URL as a language code. If the first segment started with an underscore and was not a valid language code, Odoo would split at the underscore and attempt to match the empty string (''), causing it to default to the first available language. For example, accessing https://www.odoo.com/__NULL__ on odoo.com would result in the language being
Original PR description
Prior to this commit, when a URL started with an underscore (_) and didn’t match any existing controller, Odoo attempted to resolve the first part of the URL as a language code.
If the first segment started with an underscore and was not a valid language code, Odoo would split at the underscore and attempt to match the empty string (''), causing it to default to the first available language.
For example, accessing https://www.odoo.com/__NULL__ on odoo.com would result in the language being incorrectly set to Arabic, and a redirection to https://www.odoo.com/ar.
Forward-Port-Of: odoo/odoo#183607
Forward-Port-Of: odoo/odoo#182982Before this commit, adding a product without the l10n_in_hsn_code field to an order would cause an error, as the system expected this field to be a string. opw-4254897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183763
Original PR description
Before this commit, adding a product without the l10n_in_hsn_code field to an order would cause an error, as the system expected this field to be a string. opw-4254897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183763
Before this commit, searching for an existing product in the PoS and selecting 'search more' would cause pricelist rules to stop applying. This issue arose because a new product object was created without triggering the create event. This commit addresses the problem by ensuring pricelist computation occurs upon product update events. opw-4214963 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183587
Original PR description
Before this commit, searching for an existing product in the PoS and selecting 'search more' would cause pricelist rules to stop applying. This issue arose because a new product object was created without triggering the create event. This commit addresses the problem by ensuring pricelist computation occurs upon product update events. opw-4214963 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183587
Before this commit, only the distribution for Invoices had the modulo 390 tax grids. This commit will add the tax grid of the modelo 390 for credit node. They are the exact opposite has the one on the invoice. task: 4180225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183715 Forward-Port-Of: odoo/odoo#180029
Original PR description
Before this commit, only the distribution for Invoices had the modulo 390 tax grids. This commit will add the tax grid of the modelo 390 for credit node. They are the exact opposite has the one on the invoice. task: 4180225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183715 Forward-Port-Of: odoo/odoo#180029
**Rational:** for the time being pos.order model has a classic ir.rule ([('company_id', 'in', company_ids)]). However pos.order.line doesn't have such rule. So if we create a new menu and action to display pos.order.line model, it will display all the order lines, regardless the current companies of the user. **Note:** We apply exactly the same logic as for the model sale.order and sale.order.line. See : https://github.com/odoo/odoo/blob/16.0/addons/sale/security/ir_rules.xml#L5-L15 F
Original PR description
**Rational:**
for the time being pos.order model has a classic ir.rule ([('company_id', 'in', company_ids)]). However pos.order.line doesn't have such rule. So if we create a new menu and action to display pos.order.line model, it will display all the order lines, regardless the current companies of the user.
**Note:**
We apply exactly the same logic as for the model sale.order and sale.order.line.
See : https://github.com/odoo/odoo/blob/16.0/addons/sale/security/ir_rules.xml#L5-L15
Forward-Port-Of: odoo/odoo#183045Before each test on load_state.test.js and push_state.test.js, the startRouter function is called. This is not necessary, because is already called in : https://github.com/odoo/odoo/blob/3f142f332ef1eb168f91c6a83346c9c28a169aba/addons/web/static/tests/_framework/env_test_helpers.js#L109 Forward-Port-Of: odoo/odoo#183877
Original PR description
Before each test on load_state.test.js and push_state.test.js, the startRouter function is called. This is not necessary, because is already called in : https://github.com/odoo/odoo/blob/3f142f332ef1eb168f91c6a83346c9c28a169aba/addons/web/static/tests/_framework/env_test_helpers.js#L109 Forward-Port-Of: odoo/odoo#183877
This commit implements the changes needed after receiving the first feedback of the new `l10n_ro_efactura` module. (Send CIUSRO-XML to the SPV). It's also commonly known as "Romanian EDI" (`l10n_ro_edi` in master) Purpose: Index key (received and saved as `key_download`) is an important number that should be displayed so that the customer can easily reference the invoice in the SPV. For some customer, the state flow of E-Factura in Odoo is confusing as it doesn't match what they're used
Original PR description
This commit implements the changes needed after receiving the first feedback of the new `l10n_ro_efactura` module. (Send CIUSRO-XML to the SPV). It's also commonly known as "Romanian EDI"…
This commit implements the changes needed after receiving the first feedback of the new `l10n_ro_efactura` module. (Send CIUSRO-XML to the SPV). It's also commonly known as "Romanian EDI" (`l10n_ro_edi` in master) Purpose: Index key (received and saved as `key_download`) is an important number that should be displayed so that the customer can easily reference the invoice in the SPV. For some customer, the state flow of E-Factura in Odoo is confusing as it doesn't match what they're used to in the SPV. This might be caused by the state name. Changes: - After receiving the `key_download`, log it in the invoice's chatter. - Save the `key_download` data and pass it in-between documents, to make sure that relevant documents displays the index. (and the idx doesn't get lost when "sending" document is deleted) - Change the display name of the statuses of the document. - Add a tooltip on the E-Factura status fields (move & document). The create document function helpers are changed to have one dictionary as the param signature so that we can pass on the new `key_loading` data (and any other important data in the future, for easier stable fix), and also to make it general (the same for all ro-documents) task-id: 4059522 Forward-Port-Of: odoo/odoo#179278
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time wit
Original PR description
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time without taking into consideration that there might be a break hour in the middle of the duration. **Desired behavior after PR is merged:** We are now considering the employee resource calendar in our calculation for the time of the slot. opw-3890629 Forward-Port-Of: odoo/enterprise#72145 Forward-Port-Of: odoo/enterprise#63002
…entries Steps to reproduce: - Create a belgian company - Create an analytic distibution model - Create an asset, set the expense account to the account defined in the analytic distribution model - Click on "Compute Depreciation" Observed behavior: The analytic ditribution is not applied to the depreciation entries. Desired behavior: The analytic distribution is applied correctly. task-4241362 Forward-Port-Of: odoo/enterprise#72220
Original PR description
…entries Steps to reproduce: - Create a belgian company - Create an analytic distibution model - Create an asset, set the expense account to the account defined in the analytic distribution model - Click on "Compute Depreciation" Observed behavior: The analytic ditribution is not applied to the depreciation entries. Desired behavior: The analytic distribution is applied correctly. task-4241362 Forward-Port-Of: odoo/enterprise#72220
A previous [commit](https://github.com/odoo/enterprise/pull/63926/commits/c749e1358dbd0175d0de5f32eab2c4dd98053905) added a readonly condition on the field auto_sync of the account.online.link view. This was made to prevent the automatic fetching of transaction from interactive providers when the connexion had expired. The issue lies in that condition being based on the field it applies to. This does not work well with manual editing as the readonly condition would update before hitting 'sav
Original PR description
A previous [commit](https://github.com/odoo/enterprise/pull/63926/commits/c749e1358dbd0175d0de5f32eab2c4dd98053905) added a readonly condition on the field auto_sync of the account.online.link view. This was made to prevent the automatic fetching of transaction from interactive providers when the connexion had expired. The issue lies in that condition being based on the field it applies to. This does not work well with manual editing as the readonly condition would update before hitting 'save', preventing to save the changes when unticking the 'auto_sync' checkbox. After discussion with FLG, we decided to keep things simple and remove that condition altogether. Else, one would have had to create a new field and import new data from the institution (is_interactive). No opw but the issue was raised in a odoofin support discord thread. Forward-Port-Of: odoo/enterprise#71643
Set up Avatax environment Create an Invoice with 2 lines: - Prod A, Analytic Account A - Prod B, Analytic Account B Compute taxes Now open one of the newly added taxes On the repartition line click on the 3 dots menu, show 'Tax Closing Entry' Disable 'Tax Closing Entry' on the invoice repartition line Now go back to the invoice Compute taxes again Issue: Traceback will raise 'ValueError: Expected singleton: account.move.line(...' This occurs because, with this tax configuration
Original PR description
Set up Avatax environment Create an Invoice with 2 lines: - Prod A, Analytic Account A - Prod B, Analytic Account B Compute taxes Now open one of the newly added taxes On the repartition line click on the 3 dots menu, show 'Tax Closing Entry' Disable 'Tax Closing Entry' on the invoice repartition line Now go back to the invoice Compute taxes again Issue: Traceback will raise 'ValueError: Expected singleton: account.move.line(...' This occurs because, with this tax configuration, on the move we will have 2 tax lines for the same tax, as the lines needs a different analytic account and cannot be grouped together. When we compare the amount per tax we'll have a recordset and it will raise an error. A solution is to acknowledge that we might have more than 1 line and split the possible difference evenly on the tax lines opw-3976597 Forward-Port-Of: odoo/enterprise#69090
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always displays the full amount; even if the move is partly "reconciled" already. 3. Duplicate entries can appear. All issues are solved by rewriting the generation logic a bit. Issue (1) i.e. happens due to move lines with a 0 balance in the move associated with the bank statement (line). All
Original PR description
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always…
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always displays the full amount; even if the move is partly "reconciled" already. 3. Duplicate entries can appear. All issues are solved by rewriting the generation logic a bit. Issue (1) i.e. happens due to move lines with a 0 balance in the move associated with the bank statement (line). All 3 issues can happen due to the way the entries in the report are generated: Consider a single bank statement (line) / its associated "bank move". To generate the line the report we join the bank statement line and bank move to each line of the bank move (except the liquidity line). The report groups by move line id. This generates 1 row in the report per move line (except the liquidity line) of the bank move. This directly causes issue (3). It also causes issue (2) due to the following: The reason we join all the move lines in the first place is to compute the unreconciled amount of the bank move. (By summing amounts on the move lines). But when generating a single row of the report we only have the information about 1 line (due to the grouping by id) and not the whole sum. Thus we do not have the full residual information. opw-4178134 (Issue 1) community PR: https://github.com/odoo/odoo/pull/182589 Forward-Port-Of: odoo/enterprise#72146 Forward-Port-Of: odoo/enterprise#71243
Before this commit, when documents_project module is installed on a fresh DB the label of `Use Documents` and when documents_fsm module is installed the label is updated to be `Documents`. This commit makes sure the label of that field will always be `Documents` in all cases. task-4250848 Forward-Port-Of: odoo/enterprise#71741
Original PR description
Before this commit, when documents_project module is installed on a fresh DB the label of `Use Documents` and when documents_fsm module is installed the label is updated to be `Documents`. This commit makes sure the label of that field will always be `Documents` in all cases. task-4250848 Forward-Port-Of: odoo/enterprise#71741
Set up Avatax on a company Create Branch and switch to it Create an invoice with fiscal position Avatax Compute taxes > Taxes will be created in branch company Switch to main company Create an invoice with fiscal position Avatax again. Compute taxes > Error Error will block the action ``` Validation Error Tax names must be unique! - CA STATE TAX [06] (6.0000 %) in test ``` This occurs because we first created the taxes in the branch company. Then when retrieving taxes from the ma
Original PR description
Set up Avatax on a company Create Branch and switch to it Create an invoice with fiscal position Avatax Compute taxes > Taxes will be created in branch company Switch to main company Create an invoice with fiscal position Avatax again. Compute taxes > Error Error will block the action ``` Validation Error Tax names must be unique! - CA STATE TAX [06] (6.0000 %) in test ``` This occurs because we first created the taxes in the branch company. Then when retrieving taxes from the main company those taxes are not found and will be created again but we have a constraint that tax name must be unique opw-3962212 Forward-Port-Of: odoo/enterprise#72130
The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field. There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records. To reproduce: - Install `l10n_hk_hr_payroll` with demo data - Upgrade the module Forward-Port-Of: odoo/enterprise#71844
Original PR description
The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field. There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records. To reproduce: - Install `l10n_hk_hr_payroll` with demo data - Upgrade the module Forward-Port-Of: odoo/enterprise#71844
With this commit, the user will not have to wait for the acknowledge message coming through the websocket to process it, it will be processed directly after the message is sent, if the message is accepted server-side. With this commit, we are now robust to the case the websocket connection is dropped **and** the user is alone in the spreadsheet. Task: 4243943 Forward-Port-Of: odoo/enterprise#72187 Forward-Port-Of: odoo/enterprise#71782
Original PR description
With this commit, the user will not have to wait for the acknowledge message coming through the websocket to process it, it will be processed directly after the message is sent, if the message is accepted server-side. With this commit, we are now robust to the case the websocket connection is dropped **and** the user is alone in the spreadsheet. Task: 4243943 Forward-Port-Of: odoo/enterprise#72187 Forward-Port-Of: odoo/enterprise#71782
Turn off 'Show Timezone' and 'Show Duration' by default in 'Table' demo data. Task-4247801 Forward-Port-Of: odoo/enterprise#71768
Original PR description
Turn off 'Show Timezone' and 'Show Duration' by default in 'Table' demo data. Task-4247801 Forward-Port-Of: odoo/enterprise#71768