Daily updates from Odoo
Navigate
Branch
Thursday, July 4, 2024
51 changes
20 changes
Resolved issues and error corrections
Fixed a display issue where recipient names in the mail chatter could appear without proper spacing. This improves readability for portal users when viewing message recipient lists.
Original PR description
task-4032550
This fixes a report generation issue where images with restricted access could disappear from printed or PDF reports. The session information is now handled so the report tool can still retrieve authorized images, and a test was added to prevent the problem from returning.
Original PR description
This is an oversight in bd7fe63ab4d7efd09304d9fd0546a16270c398eb The expiration date should follow the format defined in RFC 6265, which is Day, DD-Mon-YYYY HH:MM:SS GMT The expected format of the…
This is an oversight in bd7fe63ab4d7efd09304d9fd0546a16270c398eb The expiration date should follow the format defined in RFC 6265, which is Day, DD-Mon-YYYY HH:MM:SS GMT The expected format of the date for the expiration for `format_time`, using `babel`, is `EEE, dd-MMM-yyyy HH:mm:ss z` not `E, d-M-Y H:m:s z` During the development of the above revision, during the functional testing, the images in the reports were correctly working as expected. This is because the date parser was confused because of the wrong date format, and was ok for the date during which the tests were done (on April 23 2024). Nevertheless, since a few days, beginning of July, the expiration date parser no longer accepts the confusing format date, and believe the expiration date is passed, and hence wkhtmltopdf no longer forward the session id as expected, and hence the images with a restricted access right can no longer be downloaded, as the requests coming from wkhtmltopdf are no longer authenticated with the user printing the report. However, there is actually no need to set an expiration date in the first place, as this expiration date is meant for the client-side only, and the cookie jar file is deleted right after the report is printed. We therefore take the choice to simply remove the expiration date to solve the issue. A unit test is added to cover the case, so this can no longer happens. opw-3985316 opw-3985758 opw-3996620 opw-4023078 opw-4023430 opw-4023619 opw-4024377 opw-4024378 opw-4024528 opw-4027104 opw-4027115 opw-4027146 opw-4027207 opw-4027316 opw-4027338 opw-4027355 opw-4027391 opw-4027423 opw-4027622 opw-4027922 opw-4028933 opw-4029223 opw-4029395 opw-4029582 opw-4030219 opw-4032424 opw-4032956 opw-4033108 opw-4033142 opw-4033182 opw-4033766 opw-4033837 opw-4034508 opw-4035079 opw-4035246
Email marketing templates now display in a wider, desktop-like layout instead of appearing compressed like on small screens. This gives users a clearer and more accurate preview when working with templates.
Original PR description
**Current behavior before PR:** Templates were displayed in a compressed mode, similar to how they appear on small devices. **Desired behavior after PR is merged:** Templates are now displayed in a more expanded, desktop-like mode, providing a clearer and more accurate visual representation. **Task**-[3916601](https://www.odoo.com/odoo/my-tasks/3916601?cids=2)
When a spreadsheet contains an invalid field, users now see the intended friendly error message instead of a technical traceback. This helps users understand and resolve spreadsheet issues without needing technical support.
Original PR description
__Current behavior before commit:__ If there is some invalid fields inside a spreadsheet, an error message will be added to the `errors` list but it will never be shown to the user. Instead a Python `KeyError` traceback will appear because it still tries to access the field in the current iteration. __Description of the fix:__ Add `continue` after having added the error message so that it can continue the normal execution of the function and display a nice error to the user. task-4035272
The French accounting localization module name was changed from l10n_fr to l10n_fr_account without fixing the module references in the translation files. This commit fixes the module references in the i18n files. The French tax report was not showing the French translation. task-3986901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
The French accounting localization module name was changed from l10n_fr to l10n_fr_account without fixing the module references in the translation files. This commit fixes the module references in the i18n files. The French tax report was not showing the French translation. task-3986901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Currently a country code check on SOs may fail in case there is no country code. After this commit the check will return `False` in case there is no country code. (no task) see e.g.: https://runbot.odoo.com/runbot/build/64900406 Forward-Port-Of: odoo/odoo#171735
Original PR description
Currently a country code check on SOs may fail in case there is no country code. After this commit the check will return `False` in case there is no country code. (no task) see e.g.: https://runbot.odoo.com/runbot/build/64900406 Forward-Port-Of: odoo/odoo#171735
## Issue: - For all inventory operations, when using the detailed menu (three horizontal bars), Odoo did not correctly compute/autofill the quantity to be operated on. - The suggested quantity does not properly account for the correct unit of measure (uom). ## Steps To Reproduce: - Create a Product A and Product B - Set the product's B UoM to grams and tracking by lots - Create a BoM to produce product A using 2 KG of product B - Create a Manufacturing Order - Unreserve the quantity -
Original PR description
## Issue: - For all inventory operations, when using the detailed menu (three horizontal bars), Odoo did not correctly compute/autofill the quantity to be operated on. - The suggested quantity does not properly account for the correct unit of measure (uom). ## Steps To Reproduce: - Create a Product A and Product B - Set the product's B UoM to grams and tracking by lots - Create a BoM to produce product A using 2 KG of product B - Create a Manufacturing Order - Unreserve the quantity - Reserve manually using the detail menu (3 horizontal bars) - Notice it reserves 2000 Kg instead of 2Kg ## Solution: - in `_compute_quantity` compute the quantity based on `product_uom_qty` instead of `product_qty`. OPW-3816295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162271
Before this commit and since the refactor (odoo/odoo#110188), `updateAndBroadcastDebounce` would send outdated data if used within the debounce delay as it was immediate, which meant that state updates done within the debounce timing would be ignored. Note that the members of the call would still have live and correct information as they obtain it from the dataChannel. The inconsistent information is only visible to members outside the call. This commit fixes this issue by adding updating
Original PR description
Before this commit and since the refactor (odoo/odoo#110188), `updateAndBroadcastDebounce` would send outdated data if used within the debounce delay as it was immediate, which meant that state updates done within the debounce timing would be ignored. Note that the members of the call would still have live and correct information as they obtain it from the dataChannel. The inconsistent information is only visible to members outside the call. This commit fixes this issue by adding updating the API of debounce so that it allows more flexibility by allowing to have a combination of leading and trailing calls. Behavior/API inspired from lodash: https://lodash.com/docs/4.17.15#debounce Forward-Port-Of: odoo/odoo#171694
This commit revert commit https://github.com/odoo/odoo/commit/c360a6e0470c2c7f866d18c9150aef29818095a6 in order get minor currency sub unit ISO value proper instead depending on rounding field of currency. Reverted of PR https://github.com/odoo/odoo/pull/119308 opw-3955514 Forward-Port-Of: odoo/odoo#171495
Original PR description
This commit revert commit https://github.com/odoo/odoo/commit/c360a6e0470c2c7f866d18c9150aef29818095a6 in order get minor currency sub unit ISO value proper instead depending on rounding field of currency. Reverted of PR https://github.com/odoo/odoo/pull/119308 opw-3955514 Forward-Port-Of: odoo/odoo#171495
While upgrading to version 16.0, an error occurs due to [this](https://github.com/odoo/odoo/blob/65378432c6ab2ae1cb130c527b90b6be2940e3bb/addons/l10n_nl/migrations/3.3/post-migrate_update_taxes.py#L51) file. The tag '3bl (omzet)' is not present in version 16.0, so it return ```False``` value and this ```False``` value being updated in this [query](https://github.com/odoo/odoo/blob/65378432c6ab2ae1cb130c527b90b6be2940e3bb/addons/l10n_nl/migrations/3.3/post-migrate_update_taxes.py#L51) and ```acco
Original PR description
While upgrading to version 16.0, an error occurs due to…
While upgrading to version 16.0, an error occurs due to [this](https://github.com/odoo/odoo/blob/65378432c6ab2ae1cb130c527b90b6be2940e3bb/addons/l10n_nl/migrations/3.3/post-migrate_update_taxes.py#L51) file. The tag '3bl (omzet)' is not present in version 16.0, so it return ```False``` value and this ```False``` value being updated in this [query](https://github.com/odoo/odoo/blob/65378432c6ab2ae1cb130c527b90b6be2940e3bb/addons/l10n_nl/migrations/3.3/post-migrate_update_taxes.py#L51) and ```account_account_tag_id``` is an integer type and ```old_tax_tags``` a boolean value
```
2024-07-01 15:37:54,561 28 ERROR db_1780619 odoo.sql_db: bad query:
UPDATE account_account_tag_account_tax_repartition_line_rel
SET account_account_tag_id = 150
WHERE account_tax_repartition_line_id = ANY(ARRAY[1831,1832])
AND account_account_tag_id = false
ERROR: operator does not exist: integer = boolean
LINE 5: AND account_account_tag_id = false
^
HINT: No operator matches the given name and argument types. You might need to
add explicit type casts.
```
upg-1780619
opw-4027545
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#171577Issue: ====== Applying bold after copy paste doesn't cover all the selection. Steps to reproduce the issue: ============================= - Go to notes - Add 3 lines - Press `CTRL+A` to select all the lines. - `CTRL+X` then `CTRL+V` of all the lines - Press `CTRL+A` to select all the lines again. - Press `CTRL+B` to make all the lines bold - The last line doesn't get formatted. Origin of the issue: ==================== The issue is originating from the fact that paste add `br`
Original PR description
Issue: ====== Applying bold after copy paste doesn't cover all the selection. Steps to reproduce the issue: ============================= - Go to notes - Add 3 lines - Press `CTRL+A` to select all…
Issue: ====== Applying bold after copy paste doesn't cover all the selection. Steps to reproduce the issue: ============================= - Go to notes - Add 3 lines - Press `CTRL+A` to select all the lines. - `CTRL+X` then `CTRL+V` of all the lines - Press `CTRL+A` to select all the lines again. - Press `CTRL+B` to make all the lines bold - The last line doesn't get formatted. Origin of the issue: ==================== The issue is originating from the fact that paste add `br` in the last `p` element so actually the issue can be reproduced by just adding couple of lines and at the end of the last line press `SHIFT+enter` (to add br element). In the function `getTraversedNodes` we stop as soon as we reach the `endContainer` which is the last `p` elemnt because we can't have the `br` as endContainer so we don't include its desendants. In the case when we don't do copy paste (without the extra br) the `endContainer` is the node element so it will be included and it works correctly. Solution: ======== - `<p>ab<br>[</p>...]`, `<p>ab<br>[<br>cd</p>..`: startContainer is p element, we need to go to the node at the startOffset. - `<p>ab[<br></p>...`: start container is ab we need to skip it and start from the br element - `[...<p>ab<br>]cd</p>`: endContainer is cd we shouldn't include it - `[...<p>ab><br>]</p>`, `[...<p>ab<br>]<br>cd</p>`: encContainer is p element, we loop over descendants and include only the ones before endOffset. task-3874926 Forward-Port-Of: odoo/odoo#171607 Forward-Port-Of: odoo/odoo#162370
The account user group has full access to the analytic plan model, but not to the analytic applicabilities. This is uncovered in the hr_expense test, where the I am accountman user (account user group) is able to create plans, but not applicabilities. runbot error 70377 Forward-Port-Of: odoo/odoo#171736
Original PR description
The account user group has full access to the analytic plan model, but not to the analytic applicabilities. This is uncovered in the hr_expense test, where the I am accountman user (account user group) is able to create plans, but not applicabilities. runbot error 70377 Forward-Port-Of: odoo/odoo#171736
### How to reproduce 1. Go to website slides. 2. Add a new Quiz content. 3. Add a question. 4. Save it. 5. Now refresh the page. ### Issue It initialize a new QuestionFormWidget to input a new question. ### After this commit The QuestionFormWidget should not initialize if the question is created and saved. --- Task-3997404 Forward-Port-Of: odoo/odoo#170703
Original PR description
### How to reproduce 1. Go to website slides. 2. Add a new Quiz content. 3. Add a question. 4. Save it. 5. Now refresh the page. ### Issue It initialize a new QuestionFormWidget to input a new question. ### After this commit The QuestionFormWidget should not initialize if the question is created and saved. --- Task-3997404 Forward-Port-Of: odoo/odoo#170703
In PostgreSQL 16, we can no longer order by the constant FALSE anymore ("ERROR: non-integer constant in ORDER BY"). But the ORM can generate this `ORDER BY FALSE` (and `GROUP BY FALSE`) clause if we group by a property field linked to an invalid (transient/abstract) or non-existent model. Instead of making no sense query, raise a UserError to indicate the problem. Forward-Port-Of: odoo/odoo#171608
Original PR description
In PostgreSQL 16, we can no longer order by the constant FALSE anymore ("ERROR: non-integer constant in ORDER BY"). But the ORM can generate this `ORDER BY FALSE` (and `GROUP BY FALSE`) clause if we group by a property field linked to an invalid (transient/abstract) or non-existent model. Instead of making no sense query, raise a UserError to indicate the problem.
Forward-Port-Of: odoo/odoo#171608- customer display hidden in mobile view. task - 4016199 Forward-Port-Of: odoo/odoo#171364
Original PR description
- customer display hidden in mobile view. task - 4016199 Forward-Port-Of: odoo/odoo#171364
Description of the issue/feature this PR addresses: call to _get_activity_note should be request not self Current behavior before PR: When creating more than one maintenance you get the error: "raise ValueError("Expected singleton: %s" % self)" on note = self._get_activity_note() Desired behavior after PR is merged: create the note for each request correctly --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171
Original PR description
Description of the issue/feature this PR addresses:
call to _get_activity_note should be request not self
Current behavior before PR:
When creating more than one maintenance you get the error:
"raise ValueError("Expected singleton: %s" % self)" on
note = self._get_activity_note()
Desired behavior after PR is merged:
create the note for each request correctly
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#171161The font-awesome icons taking the `.btn` font-size was making them 14px while the other icons in the web_editor are 12px (eg. the svg ones) It creates an overflow on the #toolbar creating on some screensize an horizontal overflow. This commit applies a font size of 12px on the .fa inside the `#toolbar`. Additionally the createlink was not receiving the border radius rule due to the `#unlink` element being present in the DOM but invisible on screen after the create-link el. Swapping their o
Original PR description
The font-awesome icons taking the `.btn` font-size was making them 14px while the other icons in the web_editor are 12px (eg. the svg ones) It creates an overflow on the #toolbar creating on some screensize an horizontal overflow. This commit applies a font size of 12px on the .fa inside the `#toolbar`. Additionally the createlink was not receiving the border radius rule due to the `#unlink` element being present in the DOM but invisible on screen after the create-link el. Swapping their order in the xml and using the class `order-1` solve the issue without impacting the backend editor. task-3634260 Part of task-3503975 Forward-Port-Of: odoo/odoo#136806
Bug introduced with [1] on Chrome only. Using `instanceof` seems to be an issue in this case because of cross-frames code. Steps to reproduce: - Drag & drop a "Popup" snippet into a page - Drag & drop a "Parallax" snippet into the popup => Traceback (on Chrome, not Firefox) [1]: https://github.com/odoo/odoo/commit/f801f272582455461d561e6289e59a5306dc1a9c task-4018819 Forward-Port-Of: odoo/odoo#171540
Original PR description
Bug introduced with [1] on Chrome only. Using `instanceof` seems to be an issue in this case because of cross-frames code. Steps to reproduce: - Drag & drop a "Popup" snippet into a page - Drag & drop a "Parallax" snippet into the popup => Traceback (on Chrome, not Firefox) [1]: https://github.com/odoo/odoo/commit/f801f272582455461d561e6289e59a5306dc1a9c task-4018819 Forward-Port-Of: odoo/odoo#171540
Prior to this PR the mixin treated CSS variable as strings and escaped their values between quotation marks. task-3955207 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167073
Original PR description
Prior to this PR the mixin treated CSS variable as strings and escaped their values between quotation marks. task-3955207 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167073
Commit [1] introduced a fix which selects the last button of the Vert. Alignment option when switching back from grid mode. However, commit [2] removed the XML's data-js attribute which linked the JS code to the option in 16.1, and this was not caught in commit [1]'s forward-ports. Therefore, the fix was no longer working in 16.1+. This commit restores the data-js attribute in JS for a stable fix, and in master, will add it back on the template. [1]: https://github.com/odoo/odoo/comm
Original PR description
Commit [1] introduced a fix which selects the last button of the Vert. Alignment option when switching back from grid mode. However, commit [2] removed the XML's data-js attribute which linked the JS code to the option in 16.1, and this was not caught in commit [1]'s forward-ports. Therefore, the fix was no longer working in 16.1+. This commit restores the data-js attribute in JS for a stable fix, and in master, will add it back on the template. [1]: https://github.com/odoo/odoo/commit/cdf0870e1f81a5ec5096ddd062cf699e98681880 [2]: https://github.com/odoo/odoo/commit/c6561929f339ac1451cc998b2d2b399253db0016 Related to task-3142615 Forward-Port-Of: odoo/odoo#170990
19 changes
Enhancements to existing features
The appraisal shortcut on department cards now opens appraisal records for the selected department. This makes it easier for managers and HR teams to review department-specific appraisal information without extra filtering.
Original PR description
In this PR, - In the Kanban view, the appraisal action also shows records based on the selected department. Task - 3872574
Payroll users can now search salary rules by the Python code they contain. This makes it easier to find and manage rules based on their calculation logic, reducing time spent manually opening records.
Original PR description
This commit adds searching for python code in salary rules. task: 4014193
This update adds automated checks for creating worksheets directly from Field Service project forms and for sending reports in batches. These tests help reduce the risk of future issues in Field Service reporting workflows, improving reliability for teams that depend on those reports.
Original PR description
Added test cases regrading on the fly creation of worksheet from Field Service Project Form and sending reports in batches. task-3861764
The Helpdesk app’s automated checks were updated to a newer testing approach. This helps Odoo maintain the dashboard, ticket, SLA, and team screens with more reliable quality checks while keeping day-to-day user behavior unchanged.
Original PR description
task:3924542
The bank reconciliation screen now shows the bank account number when entering manual operations. This helps accounting users identify the correct account more easily and reduces the chance of selecting or recording details against the wrong bank account.
Original PR description
Add the bank account number field to the manual operations tab Part of: Task-3279342
The point-of-sale preparation display now uses clearer cashier naming instead of employee naming in its internal order data. This makes the module terminology more accurate and easier to maintain without changing the business workflow.
Original PR description
task-3941104
The WhatsApp message seen indicator has been moved to a consistent position at the bottom right of each message bubble. This makes conversations easier to scan and gives users a more predictable visual experience.
Original PR description
Before this PR the position of the message seen indicator doesn't feel consistent: if the message is squashed, its position is on the left. Otherwise, it's on the right after the date of the message. This PR removed those 2 positions and moved the message seen indicators on the bottom right of the message bubble. https://github.com/odoo/odoo/pull/171767
The Sign app now uses the recommended way to record current UTC times, avoiding a deprecated Python function. This keeps signing log reporting compatible with newer Python versions and reduces future maintenance risk without changing the user experience.
Original PR description
Starting python 3.12, utcnow() function is depreciated. https://github.com/odoo/odoo/pull/163794/files taskid: 3932486
Code cleanup and technical improvements
This update aligns the restaurant appointment point-of-sale module with recent core changes by simplifying how floor tables are displayed. It is an internal cleanup that helps keep the module maintainable without changing the business workflow for users.
Original PR description
In the corresponding community commit, the `Table` component has been removed and it's contents put directly in the `FloorScreen` component. In this commit we make this adaptation for the `pos_restaurant_appointment` module too. Task: 4014064 https://github.com/odoo/odoo/pull/170894
Miscellaneous changes
Versions -------- - 17.0+ Steps ----- 1. Go to Timesheets; 2. open list or kanban or list view; 3. click the START button to start a timer; 4. set a project & task; 5. stop timer. Issue ----- A record is added but hours spent remains 00:00, regardless of how much time has passed. Cause ----- 1. No timer was created on the server, because the `_setProjectTask` function that's responsible for it isn't being called when selecting a project or task. 2. From `_setProjectTask`, t
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Timesheets; 2. open list or kanban or list view; 3. click the START button to start a timer; 4. set a project & task; 5. stop timer. Issue ----- A…
Versions -------- - 17.0+ Steps ----- 1. Go to Timesheets; 2. open list or kanban or list view; 3. click the START button to start a timer; 4. set a project & task; 5. stop timer. Issue ----- A record is added but hours spent remains 00:00, regardless of how much time has passed. Cause ----- 1. No timer was created on the server, because the `_setProjectTask` function that's responsible for it isn't being called when selecting a project or task. 2. From `_setProjectTask`, the `onWillUpdateProps` hook wasn't getting triggered, because it's calling `load()` on `propsList` instead of `propsList.model`. 3. In `onWillUpdateProps`, the value of `timesheet.resId` wasn't getting updated because `resId` has a getter returning `config.resId`, but no setter modifying `config`. Solution -------- 1. Add a `onRecordChanged` hook. 2. Replace `propsList.load()` with `propsList.model.load()`. 3. Modify state tracking to supplant the need for changing `resId`. opw-3735463 Forward-Port-Of: odoo/enterprise#62630
Issue Currently, internals users are shown all the open shifts when they arrive on the planning app, even if the shift's role is not one of the user's role. Fix - If the employee doesn't have any roles, show all open shifts. - If the employee has role(s), show the open shifts with that role or no role. To do this, we modify the open shifts filter (which is set by default for internal users) to only show open shifts matching the user's role in the default Gantt view. opw-3888507 Forwar
Original PR description
Issue Currently, internals users are shown all the open shifts when they arrive on the planning app, even if the shift's role is not one of the user's role. Fix - If the employee doesn't have any roles, show all open shifts. - If the employee has role(s), show the open shifts with that role or no role. To do this, we modify the open shifts filter (which is set by default for internal users) to only show open shifts matching the user's role in the default Gantt view. opw-3888507 Forward-Port-Of: odoo/enterprise#65387 Forward-Port-Of: odoo/enterprise#62607
**Traceback:** ```python ('helpdesk.helpdesk_team_menu', 393, 'Helpdesk > Configuration > Helpdesk Teams', 559): Traceback (most recent call last): File "/tmp/tmpkjz256np/migrations/base/tests/test_mock_crawl.py", line 255, in crawl_menu self.mock_action(action_vals) File "/tmp/tmpkjz256np/migrations/base/tests/test_mock_crawl.py", line 412, in mock_action mock_method(model, view, fields_list, domain, group_by) File "/tmp/tmpkjz256np/migrations/base/tests/test_mock_craw
Original PR description
**Traceback:** ```python ('helpdesk.helpdesk_team_menu', 393, 'Helpdesk > Configuration > Helpdesk Teams', 559): Traceback (most recent call last): File…
**Traceback:**
```python
('helpdesk.helpdesk_team_menu', 393, 'Helpdesk > Configuration > Helpdesk Teams', 559):
Traceback (most recent call last):
File "/tmp/tmpkjz256np/migrations/base/tests/test_mock_crawl.py", line 255, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpkjz256np/migrations/base/tests/test_mock_crawl.py", line 412, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpkjz256np/migrations/base/tests/test_mock_crawl.py", line 441, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3540, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3751, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6631, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1207, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1389, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4875, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/enterprise/17.0/helpdesk_timesheet/models/helpdesk_team.py", line 22, in _compute_total_timesheet_time
[('helpdesk_ticket_id', 'in', helpdesk_timesheet_teams.ticket_ids.filtered(lambda x: not x.stage_id.fold).ids)],
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6110, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6110, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/enterprise/17.0/helpdesk_timesheet/models/helpdesk_team.py", line 22, in <lambda>
[('helpdesk_ticket_id', 'in', helpdesk_timesheet_teams.ticket_ids.filtered(lambda x: not x.stage_id.fold).ids)],
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2907, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3777, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3827, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3920, in _fetch_query
rows = self.env.cr.fetchall()
MemoryError
```
**Summary of changes:**
Previously, the code `helpdesk_timesheet_teams.ticket_ids.filtered( lambda x: not x.stage_id.fold).ids)` generating O(n) queries leading to a memory error when dealing with large numbers of tickets (e.g., 60k+ for this customer).
This commit refactors the code to use the search method instead. this approach reduces the number of queries to O(1) and significantly improves performance for customers with a large number of helpdesk tickets.
UPG - [1776915](https://upgrade.odoo.com/web#id=1776915&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form)
TASK - [3995988](https://www.odoo.com/odoo/my-tasks/3995988?cids=2)
Forward-Port-Of: odoo/enterprise#65615When creating a timesheet from the ticket view form, an access error is raised if the active company is different from the company of its project. Step to reproduce: - install helpdesk_sale_timesheet - open helpdek - open configuration menu -> helpdesk teams - select a team with the visibility set on 'invited portal users' - enable the 'billing' feature, and add a project on this team - select as active company any company other than the one set on the project selected before - select
Original PR description
When creating a timesheet from the ticket view form, an access error is raised if the active company is different from the company of its project. Step to reproduce: - install helpdesk_sale_timesheet…
When creating a timesheet from the ticket view form, an access error is raised if the active company is different from the company of its project. Step to reproduce: - install helpdesk_sale_timesheet - open helpdek - open configuration menu -> helpdesk teams - select a team with the visibility set on 'invited portal users' - enable the 'billing' feature, and add a project on this team - select as active company any company other than the one set on the project selected before - select an existing ticket, or create a new one on the team - try creating a new timesheet Validation error is raised Source of the issue: If no company_id is given in the vals_list, the default company_id used by analytic line model is the active company. The issue is not present on task, because the key 'company_id' is correctly set in the '_timesheet_preprocess' method. This method is overwritten in the helpdesk_sale module and the updates done in it prevent the correct setting of the 'company_id' later on. Solution: Ensure that the 'company_id' key is present and consistent when creating a new timesheet from the ticket form view. version: 16.0 - master task - 3581941 Forward-Port-Of: odoo/enterprise#65835 Forward-Port-Of: odoo/enterprise#50150
When renting with deliveries, if it's about a kit with subkit and shared component, the return will not be correct To reproduce the issue: 1. In Settings, enable "Rental Transfers" 2. Create a kit K as follow: - K - C1 - C2 - C3 - C2 3. Confirm a rental with 1 x K Error: in the return, there are two lines for each C2, which makes sense since each line is linked to a different kit. However, the quantity on each line is incorrect: 2 instead of 1 When
Original PR description
When renting with deliveries, if it's about a kit with subkit and shared component, the return will not be correct To reproduce the issue: 1. In Settings, enable "Rental Transfers" 2. Create a kit K…
When renting with deliveries, if it's about a kit with subkit and
shared component, the return will not be correct
To reproduce the issue:
1. In Settings, enable "Rental Transfers"
2. Create a kit K as follow:
- K
- C1
- C2
- C3
- C2
3. Confirm a rental with 1 x K
Error: in the return, there are two lines for each C2, which makes
sense since each line is linked to a different kit. However, the
quantity on each line is incorrect: 2 instead of 1
When generating the SM of the return, we first generate the values
https://github.com/odoo/odoo/blob/8db471e74238481a5429f0fcf8fbce1c0960ff27/addons/stock/models/stock_rule.py#L205-L206
In `_push_prepare_move_copy_values`, at some point, we adapt the
quantity of the returned SM based on the other SM of the SO. To do
so, we only consider the SM with the same product (among other
conditions). This criterion is not strict enough: for instance, when
looking at C2 of K, we take its quantity *and* we also take C2 of C1,
which is incorrect. Of course, we do the same when looking at C2 of
C1, hence the incorrect quantities.
OPW-3996074
Forward-Port-Of: odoo/enterprise#65951
Forward-Port-Of: odoo/enterprise#65758To reproduce the bug: - Have payroll and its l10n-au additional modules installed - Go to payroll -> config -> structure types - Change the first element 'Default Scheduled Pay' to semi-annually - Go to contacts and create click on New A python traceback will show. That's due to giving the PERIODS_PER_YEAR dictionary a non-existent key. As we can see, it lacks 'semi-monthly', 'bi-monthly', and 'semi-annually' periods. opw-4015682 Forward-Port-Of: odoo/enterprise#65927 Forward-Port-Of:
Original PR description
To reproduce the bug: - Have payroll and its l10n-au additional modules installed - Go to payroll -> config -> structure types - Change the first element 'Default Scheduled Pay' to semi-annually - Go to contacts and create click on New A python traceback will show. That's due to giving the PERIODS_PER_YEAR dictionary a non-existent key. As we can see, it lacks 'semi-monthly', 'bi-monthly', and 'semi-annually' periods. opw-4015682 Forward-Port-Of: odoo/enterprise#65927 Forward-Port-Of: odoo/enterprise#65618
### Original issue: When creating a debit note on a bill from a purchase order with the option 'copy_lines', the field 'Purchase Order' in the lines is not populated. ### Steps to reproduce: - Install Purchase, Inventory apps and the l10n_co_edi module - Switch to a Colombian company - Go to Accounting > Configuration > Accounting > Journals - In the Vendor Bill journal > Advanced Settings, uncheck the 'Electronic invoicing UBL 2.1 (Colombia)' option - Go to Purchase > Orders > Purchase
Original PR description
### Original issue: When creating a debit note on a bill from a purchase order with the option 'copy_lines', the field 'Purchase Order' in the lines is not populated. ### Steps to reproduce: -…
### Original issue:
When creating a debit note on a bill from a purchase order with the option 'copy_lines', the field 'Purchase Order' in the lines is not populated.
### Steps to reproduce:
- Install Purchase, Inventory apps and the l10n_co_edi module
- Switch to a Colombian company
- Go to Accounting > Configuration > Accounting > Journals
- In the Vendor Bill journal > Advanced Settings, uncheck the 'Electronic invoicing UBL 2.1 (Colombia)' option
- Go to Purchase > Orders > Purchase Orders, create a new one and confirm it
- 'Receive Products' and 'Validate'
- Go back to the Purchase order
- 'Create Bill' and 'Confirm'
- From actions, choose 'Debit Note'
- In the wizard, tick 'Copy Lines', select a 'Concepto Nota de Débito' and 'Create Debit Note'
- Display the Purchase Order field in the Invoice Line tab is visible, it should not be populated
### Cause:
This bug is due to another fix that have been badly made because no tests were there. Most of the content of enterprise/l10n_co_edi/wizards/account_debit_note.py:_prepare_default_values is not called when it is supposed to and called when it's not.
In the 'Create Debit Note' wizard view there is an option to copy the lines and so, autopopulate them. This option is not displayed for Debit Notes generated from Credit Notes because the lines would be negative.
(https://github.com/odoo/odoo/blob/47eff65afdba3a2a8283342d8b636657f1fac317/addons/account_debit_note/wizard/account_debit_note_view.xml#L16)
The logic of this option is located in the module account_debit_note: https://github.com/odoo/odoo/blob/2a02ba4de1c823bcdef0e8b6b6373fa27b5587a1/addons/account_debit_note/wizard/account_debit_note.py#L64, the line_ids value is filled with a default value if copy_lines is False. If left empty, the lines are copied from the original account.move.
In this commit, https://github.com/odoo/enterprise/commit/c738f14d4ac88d508b6b75747788f5867eb71a68 we are trying to manually populate the lines of a debit note when it is generated from a credit note. But the code is made so that the lines are always copied.
So in this other commit https://github.com/odoo/enterprise/commit/fa65a1ff8cb7333a3339438513d1eeb5d5f9690e there is a correction to take the copy_lines into consideration. But it breaks the precedent fix as Debit Notes of Credit Notes always have copy_lines to False. So the code to copy the lines manually is actually never called for Debit Notes of Credit Notes (which is the only case we want it to be called in). But is called every time copy_lines is set to True therefore ignoring the actual code to copy the lines in the module account_debit_note.
In the context of the bug of this PR, the problem comes from the manual copying of lines that is missing the value purchase_order_id.
### Solution:
Changing the logic of the _prepare_default_values function:
- if not a Colombian company or not a debit note of a credit note, stop here
- we let the logic in account_debit_note copy the lines (or not) depending on copy_lines.
- if the debit note comes from a credit note, we copy the lines and return
With this flow, the lines will not be copied manually so the value purchase_order_id will be populated.
opw-3962301
Forward-Port-Of: odoo/enterprise#65777
Forward-Port-Of: odoo/enterprise#64689To allow other localizations to use the same logic for negative lines, we moved the methods in account. We still extend it in the module to add specific logic about taxes and documents. task-3943357 Forward-Port-Of: odoo/enterprise#64379
Original PR description
To allow other localizations to use the same logic for negative lines, we moved the methods in account. We still extend it in the module to add specific logic about taxes and documents. task-3943357 Forward-Port-Of: odoo/enterprise#64379
Steps to reproduce: - install timesheet module - install project_timesheet_forecast bridge module - open timesheets - click on all timesheets - search an employee name Issue: - employees that are not matching this search are still being displayed Cause: - the conditions that are in domain causes this issue Solution: - if we gave the condition in domain ,that the filter is based on related search then the issue will be solved task-3653034 Forward-Port-Of: odoo/enterprise#533
Original PR description
Steps to reproduce: - install timesheet module - install project_timesheet_forecast bridge module - open timesheets - click on all timesheets - search an employee name Issue: - employees that are not matching this search are still being displayed Cause: - the conditions that are in domain causes this issue Solution: - if we gave the condition in domain ,that the filter is based on related search then the issue will be solved task-3653034 Forward-Port-Of: odoo/enterprise#53376
## Pull Request HOOT (PRHOOT) - part 19 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10
Original PR description
## Pull Request HOOT (PRHOOT) - part 19 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 19 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Communtiy: https://github.com/odoo/odoo/pull/171242 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#65945 Forward-Port-Of: odoo/enterprise#65767
12 changes
Enhancements to existing features
The 30% Tax Exemption field was appearing on all employee contracts, but it should only be available for Dutch employees. This improvement restricts the field visibility to Dutch contracts only, ensuring the payroll system displays relevant tax options based on employee location and contract type.
Original PR description
30% Exemption field shows on all contracts although it should only show on dutch employees contracts. This change restricts the 30% Exemption to only show on dutch contracts. task-3946599
This update enables the spreadsheet editor to properly support Serbian written in Latin characters (sr@latin). Previously, the system couldn't recognize this locale variant in JavaScript, causing errors. The fix adds a helper to convert locale formats so Serbian users can work with spreadsheets in their preferred writing system without technical issues.
Original PR description
Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin. To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin. Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale. This PR provides a helper to convert the locales from the Python side for use on the JavaScript side. Task-4014022 Community: https://github.com/odoo/odoo/pull/171837
Resolved issues and error corrections
Fixed an issue where users with limited access rights (own documents only) encountered an error when opening Field Service tasks with automatically generated sales orders. The fix allows these users to view their assigned tasks without triggering permission errors, improving the user experience for field service teams with restricted access levels.
Original PR description
Steps: -------- - Install Field Service module - Now, go to the field service's configuration - Click on Time and Material invoicing - Make the new Task - Add products - Now in internal user, give users access right level > sale: own document only - Now login as a user who has user access right level - After login, go to field service module - Open that task in which sale order automatically generated, access error comes Issue: ------- - An user who has user access rights level trying to read other user sale order. Cause: --------- - In this **PR enterprise-31363** added a new field pricelist_id on model project.task.This field is computed in _compute_currency_id.However user have no access to read record, therefore raises an access error for internal user. Fix: ----- - A sudo is used in method _compute_currency_id to be able to open the task but can not see sale order stat button. task-3610485 Forward-Port-Of: odoo/enterprise#52677
This update fixes a bug in the Belgian VAT listing report where data results were inconsistent when using PostgreSQL 16. The issue occurred because the report query lacked proper sorting instructions, causing unpredictable result ordering. Adding the missing sort order ensures the report always produces consistent, reliable results.
Original PR description
With PostgreSQL 16, test_report_load_more_limit fails because the result of `_get_lines` is not deterministic. It is the case because the query in `_report_custom_engine_partner_vat_listing` doesn't have a ORDER BY clause. Add a ORDER BY clause to have a deterministic behavior. Forward-Port-Of: odoo/enterprise#65991
This update fixes a test in the data cleaning module that was producing inconsistent results with newer database versions. The test was expecting search results in a specific order, but the order wasn't explicitly defined, causing random failures. The fix ensures the data cleaning process works reliably and consistently across all database environments.
Original PR description
This test expects a search result to be in a specific order but the order is not specified in the search query. With postgresql 16 it leads to random order. Forward-Port-Of: odoo/enterprise#65903
This fix restores the company's EDI certificate to the SAT XML export file for Mexican accounting reports. The certificate was missing in Odoo 16 and newer versions, but is now included again when exporting the Trial Balance report as SAT XML format. This ensures compliance with Mexican tax authority requirements.
Original PR description
With an MX company setup Go to Accounting > Reports > Trial Balance. Click "SAT (XML)" to export the file. Issue: No certificate in the xml In Odoo 15, exporting the SAT XML would include the company's EDI certificate. In Odoo 16 and newer, this is no longer the case. opw-3891205 Forward-Port-Of: odoo/enterprise#62969
This fix resolves an issue where printing to IoT devices in non-default companies would incorrectly show error messages. The system was sending printer status notifications to the wrong company channel. Now it correctly routes notifications to the company associated with the IoT device, ensuring users see accurate print status updates.
Original PR description
Before this commit: If an IoT is set on a company (other than the default one), when printing a report set to an IoT device. It would always show the "error to print" pop-up. This happened as the notification that the printing operation was successful was always send to the channel of the first company. After this commit: We force to use the company set on the device of the identifier (which is the iot box company). This heuristic is not perfect as different IoT might have devices with the same identifier, in this case, it would accidentally send to the wrong IoT channel. To solve this other issue, another PR in the IoT will force to send the IoT mac address in order to make sure to use the right IoT. As the code of the IoT might be outdated, we define it with a default value. opw-3965623
This update fixes an issue in Swiss payroll processing where employee dependent children counts were incorrectly calculated as zero when the field hadn't been manually updated, causing errors in tax code retrieval. The fix also improves the payslip recalculation process to properly apply changes from salary attachments and contract modifications.
Original PR description
When computing the number of children of an employee, if the field was never changed, it will be equal to False and appear as 0 on the form view, leading to an error in the retrieval of the appropriate IS Code. We also improve the recompute whole sheet mechanism, applying changes to salary attachments and contract modifications.
This fix corrects how optional insurance company contributions are calculated in the Swiss HR payroll system. The issue was in the salary rule configuration that determines the employer's portion of optional insurance payments, ensuring employees and employers are charged correctly.
This update fixes a display issue in the Shop Floor module where quantities were showing with rounding errors (e.g., "3.00...004" instead of "3"). The fix ensures that produced quantities and consumed component quantities are properly rounded for display, improving accuracy and clarity when managing manufacturing orders.
Original PR description
### Issue: A quantity of `3` gets displayed as `3.00...004`. ### Steps to reproduce: - Settings > Technical > Database Structure > Decimal Accuracy - Change the `Digits` of `Product Unit of measure`…
### Issue: A quantity of `3` gets displayed as `3.00...004`. ### Steps to reproduce: - Settings > Technical > Database Structure > Decimal Accuracy - Change the `Digits` of `Product Unit of measure` to 5 - Create a storable product P1 with a BOM: - In the operation tab: one operation in `Assembly line 1` - In the component tab: 1 unit of P2 consumed in the operation - Create and confirm an MO for 3 units of P1 - Go to the shopfloor module, remove the MO ready filter Two issues can be noticed: - Click on Register Production A pop up opens. Before validating it: The displayed producing quantity of P1 and the quantity of P2 that should be consumed by the operation is`3.00...004`. After validation, the produced quantity is rounded. However, if you click on the cross the rounding error will remain. In addition, the second rounding issue will remain even after validation of the consumed qty. ### Cause of the issue: Our float utils introduce tiny rounding errors, especially at higher precisions. In our case, these errors are introduced during the call of the write method of the `web_save`. ### Fix: We eliminate the rounding errors for the display in the same way as initially ptoposed by https://github.com/odoo/enterprise/pull/58880 see commit https://github.com/odoo/enterprise/commit/1c2f0068d319917bb4af163396d0861a1ff6c9e1 and adapt it to also apply to the raw_move_ids of the MO. opw-3861892 ---
This fix resolves a crash that could occur in the shop floor application when the MRP module wasn't fully updated with a new filter feature. The system now gracefully handles the missing filter instead of crashing, ensuring the shop floor application remains stable and functional for all users.
Original PR description
Since [1], the shop floor application might crash when not running an update of the MRP application to add the new filter to the search view. This fix resolves this issue by ignoring the 'This Station' filter if it is not installed. [1] https://github.com/odoo/enterprise/pull/64551
This update corrects how certain German tax transactions are categorized in the EC Sales List report. Previously, service transactions under German tax rule §13b were incorrectly included in the report when they should have been excluded. The fix ensures only the correct transaction types appear in compliance with German tax authority (DATEV) requirements.
Original PR description
Steps to reproduce: - set a customer with Belgian VAT and check one with German VAT - Create sales: * one for the Belgian company using the 0% EU sale taxe * another for the German company using the 0% tax for construction (provider §13b) - Go To Statement Reports > EC Sales List Issue: Only the invoice for the Belgian company should appear in the report EC Sales 60 tag should not be present only tags in (41, 42, 21) source: https://apps.datev.de/help-center/documents/1017530 opw-3923031 Forward-Port-Of: odoo/enterprise#65554 Forward-Port-Of: odoo/enterprise#65098