Thursday, January 16, 2025
18 changes · saas-17.4
Resolved issues and error corrections
Work centers now show only the working calendars that belong to the user's current company. This prevents users from accidentally selecting calendars from other companies, reducing confusion in multi-company manufacturing setups.
Original PR description
Steps to reproduce the bug: - Create a workcenter: Problem: All the resource calendar from all the companies are displayed. opw-4478393
This fix ensures Belgian payroll demo holidays are assigned to the Belgian company instead of the main company. It prevents demo data from interfering with scheduling and payroll-related tests or behavior in multi-company setups.
Original PR description
In this FW-port https://github.com/odoo/enterprise/pull/74528 we are having a test failing when checking I found out that it is failing because demo data of payroll belgian localization as it is…
In this FW-port https://github.com/odoo/enterprise/pull/74528 we are having a test failing when checking I found out that it is failing because demo data of payroll belgian localization as it is creating a public holiday which affects the working dates of the test 'test_move_backward_without_conflicts'. This public holiday https://github.com/odoo/enterprise/blob/c16044ce583fd2caf9210ab2621e2bcd55be4421/l10n_be_hr_payroll/data/l10n_be_hr_payroll_demo.xml#L29-L35 should be only for the belgian company but since company_id field in 'resource.calendar.leaves' is readonly and computed so it is not protected while creation https://github.com/odoo/odoo/blob/0506eb85a3f6717117110bed53c4397e25672dc5/odoo/models.py#L4780-L4781 at some point it is getting changed to the main company id when computing the company_id in resource.calendar.leave since we don't have a calendar_id https://github.com/odoo/odoo/blob/d8fa043f085ee1e1d11708e2bd1213b7ce3c9dd9/addons/resource/models/resource_calendar_leaves.py#L59-L61 To fix this while computing the company_id we are now checking if the company_id is not set as if it is already has a value we will not override it and we fallback on the resource_id.company_id before we get the self.env.company
Features or functions removed from Odoo
An unused empty file that was accidentally included during a previous code update has been removed. This is a housekeeping change with no expected impact on users or business workflows.
Original PR description
In the forward port #190318 while fixing conflict, a new empty file from another projet was accedentally sled in the commit. This commit removes this empty useless file.
Miscellaneous changes
## 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.
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 Forward-Port-Of: odoo/odoo#191601
When a product has a fixed tax, there should be a separate downpayment line for the fixed tax amount. Steps to reproduce: ------------------- * Create a fixed tax of 1€ * Assign this tax to any product * Create a sale order with this product * Open PoS and make a downpayment of 10% > Observation: There is only one downpayment line with the total amount of the product and the fixed tax combined. opw-4252104 Forward-Port-Of: odoo/odoo#193269 Forward-Port-Of: odoo/odoo#192208
Original PR description
When a product has a fixed tax, there should be a separate downpayment line for the fixed tax amount. Steps to reproduce: ------------------- * Create a fixed tax of 1€ * Assign this tax to any product * Create a sale order with this product * Open PoS and make a downpayment of 10% > Observation: There is only one downpayment line with the total amount of the product and the fixed tax combined. opw-4252104 Forward-Port-Of: odoo/odoo#193269 Forward-Port-Of: odoo/odoo#192208
Forward-Port-Of: odoo/odoo#193775
Original PR description
Forward-Port-Of: odoo/odoo#193775
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#193786Versions -------- - 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
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g. Contact); 2. set trigger to On Creation; 3. in data to write, have evaluation type to Value; 4. fill in the value (e.g. 1); 5. create a record that would trigger the automation. Issue ----- > ValueError: Wrong value for res.partner.category_id: 1 Cause ----- In the `eval_value`
Original PR description
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g.…
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g. Contact); 2. set trigger to On Creation; 3. in data to write, have evaluation type to Value; 4. fill in the value (e.g. 1); 5. create a record that would trigger the automation. Issue ----- > ValueError: Wrong value for res.partner.category_id: 1 Cause ----- In the `eval_value` method, the `many2many` type doesn't get covered. Solution -------- 1. Have `eval_value` handle `many2many` values (linking them to relevant record, and existing as a single expression per column). 2. Undo 09a6df204f2a which disallowed writing by reference for many2many fields. This change makes writing by reference possible as well, and allows you to select the desired record, instead of having to manually fill in its ID. opw-4054461 Forward-Port-Of: odoo/odoo#193610 Forward-Port-Of: odoo/odoo#190047
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
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
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#193076To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen sizes. Newer versions of Chrome sometimes introduce slight variation between the Chrome's window size and its viewport size (due to changes in the interface layout...). While often not a deal-breaker, Chrome 128 forces a min-width for the window greater than the breakpoint we use for smaller/
Original PR description
To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen…
To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen sizes. Newer versions of Chrome sometimes introduce slight variation between the Chrome's window size and its viewport size (due to changes in the interface layout...). While often not a deal-breaker, Chrome 128 forces a min-width for the window greater than the breakpoint we use for smaller/mobile-like testing (e.g. 375px, which matches a small smartphone). This commit changes the way we instrument Chrome to use a specific size by using the DevTools' Emulated Device (aka. "responsive mode"). It allows to apply a very specific viewport's size independently of the actual Chrome's window size, which makes it way more predictable than before. Note: this change is part of the preparation to support the "new" headless mode, which becomes the default starting with Chrome 128. Reference: - https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setDeviceMetricsOverride Forward-Port-Of: odoo/odoo#193847 Forward-Port-Of: odoo/odoo#193696
…wnload Current behavior before PR: When using the "Download logs" button, from the IoT box form view, an Internal Server Error is raised every time. ```py Internal Server Error : Log file configuration is not set ``` Description of the issue/feature this PR addresses: New IoT Box images are missing the default `logfile` parameter in their config. This parameter is required for log downloading, and cannot be left empty. The `logfile` parameter has been removed from the `odoo.conf`
Original PR description
…wnload Current behavior before PR: When using the "Download logs" button, from the IoT box form view, an Internal Server Error is raised every time. ```py Internal Server Error : Log file…
…wnload Current behavior before PR: When using the "Download logs" button, from the IoT box form view, an Internal Server Error is raised every time. ```py Internal Server Error : Log file configuration is not set ``` Description of the issue/feature this PR addresses: New IoT Box images are missing the default `logfile` parameter in their config. This parameter is required for log downloading, and cannot be left empty. The `logfile` parameter has been removed from the `odoo.conf` config file in PR #169633. However, it is still explicitly mentioned as `/var/log/odoo/odoo-server.log` in two other files: https://github.com/odoo/odoo/blob/451a956a22015034b8c35bd0d9a860b78442af7f/addons/hw_posbox_homepage/controllers/homepage.py#L74 and https://github.com/odoo/odoo/blob/451a956a22015034b8c35bd0d9a860b78442af7f/addons/point_of_sale/tools/posbox/overwrite_before_init/etc/init_posbox_image.sh#L28 As such, a fallback to the default `/var/log/odoo/odoo-server.log` is added. Desired behavior after PR is merged: The Logs can be downloaded from the IoT box form view without receiving an Internal Server Error. opw-4443593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192922 Forward-Port-Of: odoo/odoo#192867
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
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
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#76198This 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
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