Thursday, January 16, 2025
20 changes · saas-17.2
Resolved issues and error corrections
This update fixes a failing automated test related to keyboard shortcuts in web navigation. It helps keep the web interface test suite reliable, reducing the risk of regressions reaching users.
Original PR description
Fixes test broken by: be23ed0 https://runbot.odoo.com/odoo/runbot.build.error/109595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Child contacts with portal access can now see the tasks menu when access rules allow them to view related customer tasks. This prevents eligible users from missing project information due to an overly restrictive task count check.
Original PR description
## Issue: - Child contacts of followers were unable to access the tasks menu in the portal home, despite having access according to the access rules. ## Steps to reproduce: 1. Create a parent contact with a child contact. 2. Grant the child contact portal access. 3. Create a task with the parent contact as the customer. 4. Add the parent contact as a follower or send a message in the task chatter. 5. Log in as the child contact in the portal. 6. Notice the tasks menu is unavailable. ## Solution: - The issue originated in `_prepare_home_portal_values`, where the task count was computed with a restrictive domain and sudo instead of relying on the access rules. - Removed the unnecessary domain filter to let the access rules handle it. opw-4306834 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
In version 16, we upgraded from Bootstrap 4 to Bootstrap 5 [here](https://github.com/odoo/odoo/pull/95450). As a result, the class font-weight-bold is no longer functional and has been replaced with[ fw-bold](https://github.com/odoo/odoo/blob/31d1be3de895d9e6667a35468b4be716127d17b3/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L8427). However, when creating a worksheet template, the deprecated Bootstrap class font-weight-bold is still being generated in the arch, causing the label t
Original PR description
In version 16, we upgraded from Bootstrap 4 to Bootstrap 5 [here](https://github.com/odoo/odoo/pull/95450). As a result, the class font-weight-bold is no longer functional and has been replaced with[…
In version 16, we upgraded from Bootstrap 4 to Bootstrap 5 [here](https://github.com/odoo/odoo/pull/95450). As a result, the class font-weight-bold is no longer functional and has been replaced with[ fw-bold](https://github.com/odoo/odoo/blob/31d1be3de895d9e6667a35468b4be716127d17b3/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L8427). However, when creating a worksheet template, the deprecated Bootstrap class font-weight-bold is still being generated in the arch, causing the label to not render in bold. **Steps to reproduce:** - create demo db in version >= 16.0 - navigate to Field Service > Configurations > Worksheet Template - Add the field `report_view_id` field to see the auto-generated view for report (using studio) - set the created template to the task and print the report (Task Report)  more ref: https://github.com/odoo/upgrade/commit/cfd58d145b8bbb99b0ec1dcc70bcfbfa3f9b7e20 - OPW: 4423371 Forward-Port-Of: odoo/enterprise#77203 Forward-Port-Of: odoo/enterprise#76509
Before this commit, the test `test_editing_task_planned_date` was written by using the belgium timezone but this test starts failing after the end of the summer time in belgium timezone since inside that test, the timezone used is the one used of the current calendar set on the company and/or the timezone set on the current user, that is the belgium one. And so, due to the change of the hours in belgium timezone to now use "winter time" the offset between the `datetime.now` with belgium ti
Original PR description
Before this commit, the test `test_editing_task_planned_date` was written by using the belgium timezone but this test starts failing after the end of the summer time in belgium timezone since inside that test, the timezone used is the one used of the current calendar set on the company and/or the timezone set on the current user, that is the belgium one. And so, due to the change of the hours in belgium timezone to now use "winter time" the offset between the `datetime.now` with belgium timezone and the one using utc timezone is no longer 2 hours but 1 hour. Because of that the assets are totally wrong because the expected results are fixed and do not take into account the offset could change. This commit makes sure the test uses only utc as timezone to avoid using offset between 2 timezones since the asserts are fixed and not dynamic according to the offset between 2 timezones. runbot-104873 Forward-Port-Of: odoo/enterprise#72876
Steps to Reproduce: ----------------------------------------------- 1. Install the `planning` module. 2. Create a shift from `8:00 AM to 9:30 AM` for any resource. The allocated hours will show as `1:30`. 3. Go to the list view and print the planning report. 4. In the report, you will notice that the allocated hours are rounded up to `2` Issue: ----------------------------------------------- - The allocated hours are being rounded up to a higher value but it should match
Original PR description
Steps to Reproduce:
-----------------------------------------------
1. Install the `planning` module.
2. Create a shift from `8:00 AM to 9:30 AM` for any resource. The allocated
hours will show as `1:30`.
3. Go to the list view and print the planning report.
4. In the report, you will notice that the allocated hours are rounded
up to `2`
Issue:
-----------------------------------------------
- The allocated hours are being rounded up to a higher value but it should match
with the UI and stay consistent.
Cause:
-----------------------------------------------
- The `ceil` function is being used, which rounds the value up to the next
higher number.
Fix:
-----------------------------------------------
- In this commit we removed the `ceil` function to ensure that the allocated
hours are not rounded up.
task-4416792
Forward-Port-Of: odoo/enterprise#77110
Forward-Port-Of: odoo/enterprise#761982 Bugs: When using grouped mode in the intrastat report, the load more would load the same result everytime because no offset or limit were provided. Another bug is that when you used the non grouped mode, the would be no load more at all. opw-4342518 Forward-Port-Of: odoo/enterprise#76887 Forward-Port-Of: odoo/enterprise#76543
Original PR description
2 Bugs: When using grouped mode in the intrastat report, the load more would load the same result everytime because no offset or limit were provided. Another bug is that when you used the non grouped mode, the would be no load more at all. opw-4342518 Forward-Port-Of: odoo/enterprise#76887 Forward-Port-Of: odoo/enterprise#76543
Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded. Steps to reproduce: ------------------- * Create a new customer, make a sale order and invoice it. This will set an amount due for that customer * Connect to the shop with a user that has the `point_of_sale.group_pos_user` but not the `account.group_account_readonly` group * Open customer list > Observation: You can see the amount
Original PR description
Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded. Steps to reproduce: -------------------…
Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded. Steps to reproduce: ------------------- * Create a new customer, make a sale order and invoice it. This will set an amount due for that customer * Connect to the shop with a user that has the `point_of_sale.group_pos_user` but not the `account.group_account_readonly` group * Open customer list > Observation: You can see the amount due for multiple customers * Search for the customer created * Select search more > You can't see the amount due for that customer Why the fix: ------------ Since simple pos users are allowed to see the amount due for the loaded customer, there is no reason they shouldn't see it as well for a customer they need to load. Commit allowing simple pos users to see (and settle) customer accounts: https://github.com/odoo/enterprise/commit/37fa4d5f4ed7c7d77f73395a53b7b3ab7006afc4 First we forward the above mentionned commit as it was not fully forwarded toward master. With the use of the new relational model in saas-17.2 we cannot use the same logic as before, i.e. we cannot simply send the value of the customer account when loading the session. Why? In the case of a simple pos user, you are able to send values to the session but you cannot send the field because of user rights. By not sending the field, the relational model does not expect to set any value for it, thus the values sent will not be used. what we do frow now is to make an rpc call after the store has been initialized, the relational models will be in place already, to compute the due amount of all customer loaded and set them. We also call this rpc after searching for customers that weren't previously loaded. opw-4141955 Forward-Port-Of: odoo/enterprise#73671
This file was not loaded in the manifest and is a duplicated of `/mrp_account_enterprise/views/cost_structure_report.xml` Forward-Port-Of: odoo/enterprise#77177
Original PR description
This file was not loaded in the manifest and is a duplicated of `/mrp_account_enterprise/views/cost_structure_report.xml` Forward-Port-Of: odoo/enterprise#77177
Steps to reproduce: Not reproducible in V16. However, in older versions, it was possible to have multiple finished_moves with different quantities (see https://github.com/odoo/odoo/pull/46718). This fix ensures such issues are avoided in the future and also addresses potential problems for clients migrating from older versions. Example: Two finished_moves with different quantities. Before the fix, both moves would be updated based on the unbuild quantity, resulting in incorrect quantit
Original PR description
Steps to reproduce: Not reproducible in V16. However, in older versions, it was possible to have multiple finished_moves with different quantities (see https://github.com/odoo/odoo/pull/46718). This fix ensures such issues are avoided in the future and also addresses potential problems for clients migrating from older versions. Example: Two finished_moves with different quantities. Before the fix, both moves would be updated based on the unbuild quantity, resulting in incorrect quantities. After the fix, the moves for unbuild will use only the move's quantity. opw-4379204 Forward-Port-Of: odoo/odoo#193777 Forward-Port-Of: odoo/odoo#191908
After merging of this PR [1], video tab will not be visible in media dialog in report as `allowCommandVideo` is false. But this will override `noVideos` option from `params` to false if `allowCommandVideo` is true and video tab will be visible even if `noVideos` is `true`. This PR makes sure that `noVideos` property from `params` should be checked if `allowCommandVideo` is true. [1]: 187251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Fo
Original PR description
After merging of this PR [1], video tab will not be visible in media dialog in report as `allowCommandVideo` is false. But this will override `noVideos` option from `params` to false if `allowCommandVideo` is true and video tab will be visible even if `noVideos` is `true`. This PR makes sure that `noVideos` property from `params` should be checked if `allowCommandVideo` is true. [1]: 187251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192838
When using an auto fifo product as part of the repair, the COGS won't be based on the used product To reproduce the issue: 1. Setup auto fifo product 2. Receive 1@10 and 1@20 3. Process a RO: - Invoice method: After repair - Parts: - Add 1 x fifo product 4. Create and post the invoice 5. Open its journal items Error: Cogs are $20 instead of $10 When posting the invoice, we generate the COGS: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/
Original PR description
When using an auto fifo product as part of the repair, the COGS won't be based on the used product To reproduce the issue: 1. Setup auto fifo product 2. Receive 1@10 and 1@20 3. Process a RO: -…
When using an auto fifo product as part of the repair, the COGS
won't be based on the used product
To reproduce the issue:
1. Setup auto fifo product
2. Receive 1@10 and 1@20
3. Process a RO:
- Invoice method: After repair
- Parts:
- Add 1 x fifo product
4. Create and post the invoice
5. Open its journal items
Error: Cogs are $20 instead of $10
When posting the invoice, we generate the COGS:
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L47-L48
We therefore compute the "anglo saxon unit price":
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L133
However, there isn't any override to handle the RO case, so it leads
to the default mechanism, i.e. the standard price of the product:
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L294-L295
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L294-L295
https://github.com/odoo/odoo/blob/7cd7563f6708331bb6baf0e06d07a9f9ee329e38/addons/stock_account/models/product.py#L753-L757
And, since the first product is out, its standard price is now based
on the next candidate: $20
About the `sudo`: an accountman has not any access to `repair`, so
posting such an invoice would raise an error. Since this diff is
specific to Odoo 16, the idea is not to impact any security rules
and rather minimize the changes.
Note: Indeed, `repair` does not depend on `stock_account`, so this
commit could lead to a traceback if the bridge is removed. I delegate
this issue to the error of dependencies. Anyway, removing the bridge
would lead to other bugs. Hopefully, this has been fixed on master [1].
[1] https://github.com/odoo/odoo/commit/f7dbdec11b74f8c7d969763d8c5cf09542a47f86
OPW-4166570
Forward-Port-Of: odoo/odoo#193588
Forward-Port-Of: odoo/odoo#193076Since commit 567b8d676b3b6dc747df4d9bf10e7a91b4cb61bb It used to insert a placeholder when the data is not there but we won't on real report 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#193531
Original PR description
Since commit 567b8d676b3b6dc747df4d9bf10e7a91b4cb61bb It used to insert a placeholder when the data is not there but we won't on real report 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#193531
Devices detected through usb don't always have there manufactured and product name which can be retrieved. For example, our foot pedal in the office doesn't which leads to it having a name `"None - None"` in Odoo. After this PR if a device doesn't have a product name / manufacturer name it will be saved as `"Unknown input device"` task-4472585 Forward-Port-Of: odoo/odoo#193295 Forward-Port-Of: odoo/odoo#193277
Original PR description
Devices detected through usb don't always have there manufactured and product name which can be retrieved. For example, our foot pedal in the office doesn't which leads to it having a name `"None - None"` in Odoo. After this PR if a device doesn't have a product name / manufacturer name it will be saved as `"Unknown input device"` task-4472585 Forward-Port-Of: odoo/odoo#193295 Forward-Port-Of: odoo/odoo#193277
Versions -------- - 17.0+ Steps ----- 1. Create a pricelist with 200 price rules; 2. export pricelist to xlsx; 3. delete original pricelist; 4. import pricelist, setting batch size to 100. Test files ready for import: - [200_products.xlsx](https://github.com/user-attachments/files/17848187/200_products.xlsx) - [200_pricelist_rules.xlsx](https://github.com/user-attachments/files/17848188/200_pricelist_rules.xlsx) Issue ----- Pricelist is imported with 400 price rules. Cause
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a pricelist with 200 price rules; 2. export pricelist to xlsx; 3. delete original pricelist; 4. import pricelist, setting batch size to 100. Test files…
Versions -------- - 17.0+ Steps ----- 1. Create a pricelist with 200 price rules; 2. export pricelist to xlsx; 3. delete original pricelist; 4. import pricelist, setting batch size to 100. Test files ready for import: - [200_products.xlsx](https://github.com/user-attachments/files/17848187/200_products.xlsx) - [200_pricelist_rules.xlsx](https://github.com/user-attachments/files/17848188/200_pricelist_rules.xlsx) Issue ----- Pricelist is imported with 400 price rules. Cause ----- The back-end signals there's nothing left to import by having `nextrow` be falsy[^1]. The front-end ignores this, and continues looping until it's taken as many steps as it initially planned. The upfront `totalSteps` calculation is too high when an imported record has a number of nested relational records that's larger than the batch size. Solution -------- If the ORM returns a falsy `nextrow` value, call `stopImport`. opw-4164056 [^1]: see note on f58368210c9c Forward-Port-Of: odoo/odoo#188092
When receiving an ubl file by mail, we need to ensure that the company from where we retrieve the product is the same as the invoice company, otherwise we end up with an UserError ("Incompatible companies on records"). Steps: - Have 2 company (X being id == 1 and Y being id == 2) - Create a product "Locations et leasing opérationnel" with X setas company_id - Create an alias on company Y vendor bills journals - Sent the `bis3_bill_example.xml` located in `addons/account_edi_ubl_cii/tests/tes
Original PR description
When receiving an ubl file by mail, we need to ensure
that the company from where we retrieve the product is the same as
the invoice company, otherwise we end up with an UserError ("Incompatible companies on records").
Steps:
- Have 2 company (X being id == 1 and Y being id == 2)
- Create a product "Locations et leasing opérationnel" with X setas
company_id
- Create an alias on company Y vendor bills journals
- Sent the `bis3_bill_example.xml` located in `addons/account_edi_ubl_cii/tests/test_files/`
to the email alias
- Open the created bill
-> Error in the chatter: "Error importing attachment ... as invoice
(decoder=_import_invoice_ubl_cii)
opw-4444747
Forward-Port-Of: odoo/odoo#193786The docstring of `@route` states that it accepts any iterable for the `methods` argument, but several places in the source code wrongly expected a list, and break if it is a tuple. Forward-Port-Of: odoo/odoo#193733 Forward-Port-Of: odoo/odoo#193621
Original PR description
The docstring of `@route` states that it accepts any iterable for the `methods` argument, but several places in the source code wrongly expected a list, and break if it is a tuple. Forward-Port-Of: odoo/odoo#193733 Forward-Port-Of: odoo/odoo#193621
Forward-Port-Of: odoo/odoo#193775
Original PR description
Forward-Port-Of: odoo/odoo#193775
### Before When creating a new vendor bill through Vendors > 'Example Vendor 1'> Vendor Bills (magic button), if the vendor was changed to 'Example Vendor 2' and the draft saved then it would show up under the 'Example Vendor 1' in the Partner Ledger instead of under the correct 'Example Vendor 2'. This is due to the partner_id being defined in the context when going through the 'Example Vendor 1' view. ### Now During the creation of the account move lines we use a context without the
Original PR description
### Before When creating a new vendor bill through Vendors > 'Example Vendor 1'> Vendor Bills (magic button), if the vendor was changed to 'Example Vendor 2' and the draft saved then it would show up under the 'Example Vendor 1' in the Partner Ledger instead of under the correct 'Example Vendor 2'. This is due to the partner_id being defined in the context when going through the 'Example Vendor 1' view. ### Now During the creation of the account move lines we use a context without the default_partner_id. The Partner Ledger now shows the draft bill entry under the right vendor. opw-4407709 Forward-Port-Of: odoo/odoo#193629 Forward-Port-Of: odoo/odoo#192567
Steps to reproduce the bug: - Create a storable product “C1”: - MTO + Manufacture - BoM: - Component: 1 unit of C2 - Create a storable product “P1” - Component: 1 unit of C1 - Create a MO to produce one unit of P1: - Confirm - A child MO with one unit of C1 is created - Update the qty producing of P1 to 2 - A new MO to produce one unit of C1 is created Problem: The MO of P1 is linked only to the last MO of C1. This occurs because the “created_productio
Original PR description
Steps to reproduce the bug: - Create a storable product “C1”: - MTO + Manufacture - BoM: - Component: 1 unit of C2 - Create a storable product “P1” - Component: 1 unit of C1 - Create a MO to produce…
Steps to reproduce the bug:
- Create a storable product “C1”:
- MTO + Manufacture
- BoM:
- Component: 1 unit of C2
- Create a storable product “P1”
- Component: 1 unit of C1
- Create a MO to produce one unit of P1:
- Confirm
- A child MO with one unit of C1 is created
- Update the qty producing of P1 to 2
- A new MO to produce one unit of C1 is created
Problem:
The MO of P1 is linked only to the last MO of C1.
This occurs because the “created_production_id” field in the stock move of C1 (associated with the MO of P1) is updated to reference the most recent MO of C1. Additionally, since the following fix:
https://github.com/odoo/odoo/commit/c5b3f41fbd442def9e97acb023a00862e7d03eb3#diff-6d86bc8c3e9aa22586656b702849c5bbbb00c9b97ffd08bc0842e0e68f8948f9R74
Each new MO has its own procurement group.
As a result, when using the _get_children method:
- The method retrieves stock moves linked to the current procurement group.
- It uses their created_production_id to fetch the associated procurement group and then retrieves the related production_id.
However, since the two child MOs of C1 belong to different procurement groups, only the latest MO is returned.
opw-4450210
Forward-Port-Of: odoo/odoo#193829
Forward-Port-Of: odoo/odoo#192952Issue: * Accrued Expense Entry shows wrong currency symbol for 'Total in Currency' for multicurrency POs. Steps To Reproduce: * In a multicurrency environmentcreate a PO with a currency different than the one of the company and confirm it. * Receive the product and validate it. * On the PO action wheel, create `Accrued Expense Entry`. * Notice 'Total in Currency' is set to the wrong currency. Solution: * In `_compute_move_vals` I set the move's `currency_id` of the accrual move to t
Original PR description
Issue: * Accrued Expense Entry shows wrong currency symbol for 'Total in Currency' for multicurrency POs. Steps To Reproduce: * In a multicurrency environmentcreate a PO with a currency different than the one of the company and confirm it. * Receive the product and validate it. * On the PO action wheel, create `Accrued Expense Entry`. * Notice 'Total in Currency' is set to the wrong currency. Solution: * In `_compute_move_vals` I set the move's `currency_id` of the accrual move to that of the order's currency. * in `create_entries` I prevent the creation of the accrual move if orders have different currencies. * Please note that there were no issues with currency conversions. opw-4072932 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177929