Daily updates from Odoo
Friday, August 9, 2024
22 changes · saas-17.2
Resolved issues and error corrections
This fix stops Odoo from repeatedly retrying failed screens when several actions in the URL cannot be opened, preventing users from getting stuck in an endless error cycle. It also improves page reload behavior so previously opened dynamic screens can be restored correctly, making navigation more reliable.
Original PR description
- Open Accounting; - Open Bank Reconciliation; - Change the Company, to a company with not installed a chart of account. Before this commit, an infinity access error loop was raise. This occurs, because when an action is in an error on mounting on the action service, we try to mount the previous action, choose from a list of previously executed actions. The previous action, in this case, was also in error. In these case, it should go to the before last of the list, but as the previous one wasn't removed. It will try to mount it again, and create an infinity loop. opw-[4076702](https://www.odoo.com/web#id=4076702&view_type=form&model=project.task)
Pressing backspace in an empty cashier password popup in Point of Sale no longer causes an error. This improves cashier selection reliability and prevents a small disruption during checkout operations.
Original PR description
Before this commit, pressing backspace in the cashier selection password number popup when it was empty would cause an error. opw-4089617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Duplicating records from list views now uses the same business context as duplicating from a form view. This prevents inconsistent copied records, such as rental sales orders missing rental-specific behavior when duplicated from a list.
Original PR description
Description of the issue/feature this PR addresses: - Adapting the fix for saas-17.2: https://github.com/odoo/odoo/pull/174137 It is found that context is never passed in '_duplicateRecords' function for list views, when making 'orm' calls from js side, while it is passed in 'duplicate' function of record.js, which is called when duplicating record from form view. 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
Miscellaneous changes
Description of the issue this commit addresses: Wrong invoice label for the tax 25.5 which shows 25%. --- Desired behavior after this commit is merged: The tax has the label 25.5% on invoices. --- no task-feedback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175908
Original PR description
Description of the issue this commit addresses: Wrong invoice label for the tax 25.5 which shows 25%. --- Desired behavior after this commit is merged: The tax has the label 25.5% on invoices. --- no task-feedback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175908
Mistakenly backported. Needed from saas-17.4 up to master Forward-Port-Of: odoo/odoo#175011
Original PR description
Mistakenly backported. Needed from saas-17.4 up to master Forward-Port-Of: odoo/odoo#175011
Steps to reproduce ================== As Admin: - Install project - Go to project - Click on the three dots on a project card - Select "Share" - Copy the link - Select the edit mode - Add "Joel Willis" to the recipients - Click on "Send" As portal in another browser (or in private navigation) - Paste the link - Type some random characters in the search bar so that no records are matched - remove the current filter => Every single column is displayed, for example `<field name
Original PR description
Steps to reproduce ================== As Admin: - Install project - Go to project - Click on the three dots on a project card - Select "Share" - Copy the link - Select the edit mode - Add "Joel…
Steps to reproduce
==================
As Admin:
- Install project
- Go to project
- Click on the three dots on a project card
- Select "Share"
- Copy the link
- Select the edit mode
- Add "Joel Willis" to the recipients
- Click on "Send"
As portal in another browser (or in private navigation)
- Paste the link
- Type some random characters in the search bar so that no records are matched
- remove the current filter => Every single column is displayed, for example
`<field name="sequence" readonly="1" column_invisible="True"/>`
As Admin:
- Go to the shared project settings
- Disable the "Milestones" checkbox
As portal:
- Refresh the page => The milestone column is still displayed
Cause of the issue
==================
The difference between invisible and column_invisible is that
`invisible` is meant to hide a cell in a row and is evaluated with the record data (`record.evalContextWithVirtualIds`).
`column_invisible` is meant to remove a column completely for the list, but is is not evaluated with the record. It only uses the context and a few more keys (`this.model.root.evalContext`).
It is thus not possible to hide an entire column depending on record values. It makes sense as the values could be different for every record displayed.
In this case though, there are a few fields that have the same values for every record. They are in fact related fields, declared on the project.
Those fields are
- allow_milestones
- allow_timesheets
The [ProjectSharingListRenderer] has been created to hide some columns from being displayed when a feature is disabled on the project displayed.
It works by evaluating the column_invisible with the first record. If there are no records, we skip any column_invisible processing,
When calling `setColumns` from `onWillUpdateProps`, we use `nextProps` for the columns, but still `this.props` to get the first record.
This means that we use an outdated first record, and this is why every column is displayed after removing the filter.
Another issue is that
During [View-Pocalypse],
In 16.0, the milestone_id field was
```xml
<field name="milestone_id" attrs="{'column_invisible': [('allow_milestones', '=', False)]}"/>
```
In 17.0, it is
```xml
<field name="milestone_id" invisible="not allow_milestones" context="{'default_project_id': project_id}" groups="project.group_project_milestone" optional="hide"/>
```
Solution
========
As there are some limitations to the js approach (when no records are in the list for example) and there is already a context key for the [allow_timesheets], we use a simpler approach to add the missing keys.
Finally, we put back the column_invisible attributes
---
[ProjectSharingListRenderer]: https://github.com/odoo/odoo/commit/ab2b5d1fd1f09d804ab410bc326cfebf26d5a7c6
[View-Pocalypse]: https://github.com/odoo/odoo/pull/104741
[allow_timesheets]: https://github.com/odoo/odoo/blob/d2a428c07fd728691e3ddd60fe4b7cc5e94455a6/addons/hr_timesheet/models/project_project.py#L290
opw-4015035
Forward-Port-Of: odoo/odoo#175756
Forward-Port-Of: odoo/odoo#172645Since [1], Werkzeug 3.0.1 is used depending on the python version. Unlike its previous versions, Werkzeug 3.0.1's `url_quote` does not escape the single quote character to `%27` anymore. This causes an issue for cover images that use the computed `image_src` in a `background-image` CSS property using `url(...)` or `url('...')`. This commit restores the former behavior of `_compute_image_src` to avoid issues when its output is used in inadequately quoted CSS properties. Steps to rep
Original PR description
Since [1], Werkzeug 3.0.1 is used depending on the python version.
Unlike its previous versions, Werkzeug 3.0.1's `url_quote` does not
escape the single quote character to `%27` anymore.
This causes an issue for cover images that use the computed `image_src`
in a `background-image` CSS property using `url(...)` or `url('...')`.
This commit restores the former behavior of `_compute_image_src` to
avoid issues when its output is used in inadequately quoted CSS
properties.
Steps to reproduce:
- Use python_version >= '3.12' so that Werkzeug is 3.0.1.
- Create a new blog post.
- Set a cover image.
- Save.
=> Image is not displayed anymore because URL contains `'`.
[1]: https://github.com/odoo/odoo/commit/4a019ae9de64b260fe6b18d21f4624902b3bb880
task-4099056
Forward-Port-Of: odoo/odoo#175815Since commit odoo/odoo@adb5357e7f93f2cba70acc576a597ea78bd1de42, we have added a new DIV (`o_form_view_container`) around the form view. But the CSS selector for the sticky control panel was not adapted so the feature was not working anymore. This commit fixes the CSS selector. Steps to reproduce: * Open Odoo on small screen * Open the Contact App * Select a contact * Try to scroll down and up into the form view => Bug the control panel is not sticky Note : backport of PR 176015
Original PR description
Since commit odoo/odoo@adb5357e7f93f2cba70acc576a597ea78bd1de42, we have added a new DIV (`o_form_view_container`) around the form view. But the CSS selector for the sticky control panel was not adapted so the feature was not working anymore. This commit fixes the CSS selector. Steps to reproduce: * Open Odoo on small screen * Open the Contact App * Select a contact * Try to scroll down and up into the form view => Bug the control panel is not sticky Note : backport of PR 176015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176164
This commit's purpose is to rename the other costs & other revenues section to avoid id conflict with other section of the project profitability panel. 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#171949
Original PR description
This commit's purpose is to rename the other costs & other revenues section to avoid id conflict with other section of the project profitability panel. 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#171949
This commit fixes an issue regarding down-payment calculation. ZATCA defines one rule to govern the way prepaid amounts (down-payment) is calculated, where PrepaidAmount = SUM([LINE.TaxableAmount + LINE.TaxAmount for LINE in invoice.invoice_line_ids]), obviously this poses a problem when we have a mix of down-payment and normal lines on our invoice since the formula does not differentiate between those. To fix this, we make sure that only down-payment lines actually include a Tax Subtotal breakd
Original PR description
This commit fixes an issue regarding down-payment calculation. ZATCA defines one rule to govern the way prepaid amounts (down-payment) is calculated, where PrepaidAmount = SUM([LINE.TaxableAmount +…
This commit fixes an issue regarding down-payment calculation. ZATCA defines one rule to govern the way prepaid amounts (down-payment) is calculated, where PrepaidAmount = SUM([LINE.TaxableAmount + LINE.TaxAmount for LINE in invoice.invoice_line_ids]), obviously this poses a problem when we have a mix of down-payment and normal lines on our invoice since the formula does not differentiate between those. To fix this, we make sure that only down-payment lines actually include a Tax Subtotal breakdown (TaxableAmount & TaxAmount) Description of the issue/feature this PR addresses: PrepaidAmount value in invoice XML, representing down-payment amounts, is Wrong, both on the XML and QR code associated, even though ZATCA returns a Valid submission status Current behavior before PR: PrepaidAmount value in invoice XML, representing down-payment amounts, is Wrong, both on the XML and QR code associated, even though ZATCA returns a Valid submission status Desired behavior after PR is merged: PrepaidAMount is calculated correctly on the XML invoice submitted to ZATCA and also represented correctly on the QR code --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174960
If the module l10n_be was installed and you tried to invoice a settled order, you got a traceback Steps to reproduce: ------------------- * Install l10n_be_pos_sale module * Open PoS in a non belgian company * Import an order from sales in PoS * Try to invoice it > Observation: You get a traceback Why the fix: ------------ Intracom taxes where not set and was causing a traceback. opw-4089625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-
Original PR description
If the module l10n_be was installed and you tried to invoice a settled order, you got a traceback Steps to reproduce: ------------------- * Install l10n_be_pos_sale module * Open PoS in a non belgian company * Import an order from sales in PoS * Try to invoice it > Observation: You get a traceback Why the fix: ------------ Intracom taxes where not set and was causing a traceback. opw-4089625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175898 Forward-Port-Of: odoo/odoo#175397
Steps to reproduce: - In website edit mode. - Drop enough blocks into the page to have a vertical scrollbar. - Click on the header. - Select the "Vertical" template in the options of the header. - Select the "Fixed" scroll effect in the options of the header. - click on the logo in the header. - Enter "80px" in the "Height" input in the options of the "Navbar Logo". - Scroll the page to the bottom. - Then, scroll the page to the top. - Bug: the "Navbar Logo" overlaps the navbar links
Original PR description
Steps to reproduce: - In website edit mode. - Drop enough blocks into the page to have a vertical scrollbar. - Click on the header. - Select the "Vertical" template in the options of the header. - Select the "Fixed" scroll effect in the options of the header. - click on the logo in the header. - Enter "80px" in the "Height" input in the options of the "Navbar Logo". - Scroll the page to the bottom. - Then, scroll the page to the top. - Bug: the "Navbar Logo" overlaps the navbar links. This bug occurred because the header size was calculated before the transition animation for the header height was completed. opw-4078173 Forward-Port-Of: odoo/odoo#175653
Before this commit, searching for a sale order with a partner name containing special characters (e.g., &) would fail to correctly filter the sale orders. This commit ensures that partner names with special characters are properly handled, allowing for accurate sale order searches. opw-4062365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174225
Original PR description
Before this commit, searching for a sale order with a partner name containing special characters (e.g., &) would fail to correctly filter the sale orders. This commit ensures that partner names with special characters are properly handled, allowing for accurate sale order searches. opw-4062365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174225
Set Company country to India Create a TAX as follows - Amount: 15% - Included in price: False - Tax repartition line: - 100.00% of tax to 100560 Tax Receivable - -100.00% of tax to 999999 Undistributed Profits/Losses Open Bank Reconciliation Widget Create a statement Match with Manual operation Select created tax Issue: created tax lines have no amount This occurs because when computing the tax amounts with compute_all if the configuration of tax is price included (enforced
Original PR description
Set Company country to India Create a TAX as follows - Amount: 15% - Included in price: False - Tax repartition line: - 100.00% of tax to 100560 Tax Receivable - -100.00% of tax to 999999 Undistributed Profits/Losses Open Bank Reconciliation Widget Create a statement Match with Manual operation Select created tax Issue: created tax lines have no amount This occurs because when computing the tax amounts with compute_all if the configuration of tax is price included (enforced from context) and the tax is in cache we use the computed amount. Unfortunately in this particular configuration the amount is 0 opw-3986439 Forward-Port-Of: odoo/odoo#173674
When a menu link is defined towards an anchor, the scroll effect of the browser does not trigger from within the translated pages where the URL contains the additional path element about the used locale. This scrolling is achieved by the browser itself, it is not related to `scroller_service.js`. The URL is not transformed by `website.menu`'s `clean_url` method. The language is added in `ir.http`'s `url_lang` method, but we cannot always know the current URL at that point, nor during the tem
Original PR description
When a menu link is defined towards an anchor, the scroll effect of the browser does not trigger from within the translated pages where the URL contains the additional path element about the used…
When a menu link is defined towards an anchor, the scroll effect of the browser does not trigger from within the translated pages where the URL contains the additional path element about the used locale. This scrolling is achieved by the browser itself, it is not related to `scroller_service.js`. The URL is not transformed by `website.menu`'s `clean_url` method. The language is added in `ir.http`'s `url_lang` method, but we cannot always know the current URL at that point, nor during the template rendering - making it impossible to determine if the rendered anchor is local. This commit solves this client-side by replacing link's `href` values with their anchor only whenever they are targeting the current page. Steps to reproduce: - Install a second language on the website. - Put some content in the Home page so that the bottom section requires scrolling to be seen. - Add a menu element that targets `#bottom`. - Either be a visitor or a connected user. - Go to the default language Home page. - Click on the new link. => Page scrolls to the bottom. - Switch to the second language Home page. - Click on the new link. => Page reloads targeting the bottom instead of scrolling. opw-3956066 Forward-Port-Of: odoo/odoo#176077 Forward-Port-Of: odoo/odoo#169944
Description of the issue/feature this PR addresses: - i found that context is never passed in [_duplicateRecords()](https://github.com/odoo/odoo/blob/bd922d14051e5cf09628ad20087d5a78c6588919/addons/web/static/src/model/relational_model/dynamic_list.js#L210) function for list views, when making 'orm' calls from js side, while it is passed in [duplicate](https://github.com/odoo/odoo/blob/bd922d14051e5cf09628ad20087d5a78c6588919/addons/web/static/src/model/relational_model/record.js#L191) functi
Original PR description
Description of the issue/feature this PR addresses: - i found that context is never passed in…
Description of the issue/feature this PR addresses: - i found that context is never passed in [_duplicateRecords()](https://github.com/odoo/odoo/blob/bd922d14051e5cf09628ad20087d5a78c6588919/addons/web/static/src/model/relational_model/dynamic_list.js#L210) function for list views, when making 'orm' calls from js side, while it is passed in [duplicate](https://github.com/odoo/odoo/blob/bd922d14051e5cf09628ad20087d5a78c6588919/addons/web/static/src/model/relational_model/record.js#L191) function of record.js, which is called when duplicating record from form view. **use case:** - In `sale_renting` module, There is difference in the result, when a `sale_order` is duplcated from form view(duplicated properly) and when it is duplicated from list view(unexpected result). When duplicating a sale_order, its lines are also being duplicated, and at that time [_compute_is_rental](https://github.com/odoo/enterprise/blob/10006504139abc706ccdb00f71c16846414731eb/sale_renting/models/sale_order_line.py#L56) is being computed, which relies on context key `in_rental_app`. 'in_rental_app' is set in the related action yet was not available when duplicating the sale_order from list view (which resulted in unexpected behaviour). Current behavior before PR: - Context is not passed when duplicating Records from list view. Desired behavior after PR is merged: - Context is passed when duplicating Records from list view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174137
Before this commit: While generating an ewaybill we get the following traceback: ```log File "/home/odoo/odoo/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 418, in _generate_ewaybill_direct 'ewaybill_expiry_date': self._indian_timezone_to_odoo_utc( File "/home/odoo/odoo/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 433, in _indian_timezone_to_odoo_utc local_time = datetime.strptime(str_date, time_format) TypeError: strpti
Original PR description
Before this commit:
While generating an ewaybill we get the following traceback:
```log
File "/home/odoo/odoo/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 418, in _generate_ewaybill_direct
'ewaybill_expiry_date': self._indian_timezone_to_odoo_utc(
File "/home/odoo/odoo/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 433, in _indian_timezone_to_odoo_utc
local_time = datetime.strptime(str_date, time_format)
TypeError: strptime() argument 1 must be str, not None
```
After this commit:
We resolve the traceback it was caused due to
string to datetime conversion because we were
receving `None` value instead of datetime string
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176183Before this commit, when using a product in a kit with a smaller unit of measure than the base product UoM, and the conversion resulted in a zero quantity, an unclear error message was displayed upon closing the PoS session: "Quantity or Reserved Quantity should be set." This error message lacked sufficient information, making it difficult to diagnose the issue, especially with multiple orders. This commit enhances the error message to clearly indicate the cause of the problem, providing spec
Original PR description
Before this commit, when using a product in a kit with a smaller unit of measure than the base product UoM, and the conversion resulted in a zero quantity, an unclear error message was displayed upon…
Before this commit, when using a product in a kit with a smaller unit of measure than the base product UoM, and the conversion resulted in a zero quantity, an unclear error message was displayed upon closing the PoS session: "Quantity or Reserved Quantity should be set." This error message lacked sufficient information, making it difficult to diagnose the issue, especially with multiple orders. This commit enhances the error message to clearly indicate the cause of the problem, providing specific details about the UoM conversion that resulted in a zero quantity. To reproduce the issue: 1. Create a product with a base UoM in kilograms (kg). 2. Include this product in a kit with a UoM of grams (g). 3. Set the rounding precision for both UoMs to 0.01. 4. Sell one kit through the PoS. The error would occur due to the quantity conversion from grams to kilograms resulting in zero, given the rounding precision settings. opw-4084783 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175007
A field from sale was used in point_of_sale. Introduced here https://github.com/odoo/odoo/pull/173389 opw-4005925-1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176265
Original PR description
A field from sale was used in point_of_sale. Introduced here https://github.com/odoo/odoo/pull/173389 opw-4005925-1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176265
Denmark government need a way to get ec sales. So now we have a report dedicated to denmark with an export to a CSV format This require us to add the triangular sales tax task-4080107 Backporting: https://github.com/odoo/odoo/pull/157211/commits/a6bd4048a20fada2822692107b57dbcd20d2baf9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174810
Original PR description
Denmark government need a way to get ec sales. So now we have a report dedicated to denmark with an export to a CSV format This require us to add the triangular sales tax task-4080107 Backporting: https://github.com/odoo/odoo/pull/157211/commits/a6bd4048a20fada2822692107b57dbcd20d2baf9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174810
Specification: The time should not be reset when dragging an event in the month view. Observed behavior: Time is reset when dragging an event in month mode. Task-3432065 Forward-Port-Of: odoo/odoo#171402
Original PR description
Specification:
The time should not be reset when dragging an event in the month view.
Observed behavior:
Time is reset when dragging an event in month mode.
Task-3432065
Forward-Port-Of: odoo/odoo#171402Before this commit, replying to a message from email author lead to a crash. Steps to reproduce: - Set notification preferences to "Handle in Odoo", in user preferences - Follow a record with chatter - Send a message on the followed record so that it's received by another follower by email - Follower replies to message from email client - Open Inbox in Discuss app and click on "Reply" action on that message => Crash `Cannot read property of undefined (reading 'name')` This happens bec
Original PR description
Before this commit, replying to a message from email author lead to a crash. Steps to reproduce: - Set notification preferences to "Handle in Odoo", in user preferences - Follow a record with chatter - Send a message on the followed record so that it's received by another follower by email - Follower replies to message from email client - Open Inbox in Discuss app and click on "Reply" action on that message => Crash `Cannot read property of undefined (reading 'name')` This happens because the reply-to text above composer when using the message reply feature assumed that the author is necessarily a partner. This is not necessarily the case: some message just have an email address as author. This commit fixes the issue by correctly showing the address email when replying to such a message. opw-4092015 Forward-Port-Of: odoo/odoo#176225 Forward-Port-Of: odoo/odoo#176139