Daily updates from Odoo
Navigate
Branch
Wednesday, June 5, 2024
75 changes
37 changes
Resolved issues and error corrections
This update refreshes Odoo's spreadsheet engine with several fixes that make day-to-day spreadsheet work more reliable. Users should see fewer issues when pasting charts, editing sheets, using formulas, exporting files, and working with charts or conditional formatting.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/086af6d9a [REL] 17.2.9 Task: 0 https://github.com/odoo/o-spreadsheet/commit/eb6592c40 [FIX] package: saas-17.2 is no…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/086af6d9a [REL] 17.2.9 Task: 0 https://github.com/odoo/o-spreadsheet/commit/eb6592c40 [FIX] package: saas-17.2 is no longer the latest version Task: 0 https://github.com/odoo/o-spreadsheet/commit/cc5e097fb [FIX] clipboard: cannot paste chart with deleted ranges Task: 3618758 https://github.com/odoo/o-spreadsheet/commit/2d3d75e67 [FIX] FigureComponent: Stop Ctrl+A propagation Task: 3863300 https://github.com/odoo/o-spreadsheet/commit/6ea6ed083 [FIX] functions: throw errors with formula that return range Task: 3918882 https://github.com/odoo/o-spreadsheet/commit/4ace22d3c [FIX] module array: accept negative index on choose cols/rows Task: 3918882 https://github.com/odoo/o-spreadsheet/commit/c2b60528b [FIX] functions: Conditional functions now handle ranges with different size Task: 3918882 https://github.com/odoo/o-spreadsheet/commit/88a94589c [FIX] functions: correctly handle simple arguments on conditional functions Task: 3918882 https://github.com/odoo/o-spreadsheet/commit/ee96f3f57 [PERF] evaluation: faster spreading Task: 0 https://github.com/odoo/o-spreadsheet/commit/e02dca3e0 [FIX] clipboard: do not change clipboard state on INSERT_CELLS Task: 3874117 https://github.com/odoo/o-spreadsheet/commit/37d51bd4f [FIX] xlsx: Skip non-exported formula with no result Task: 3491974 https://github.com/odoo/o-spreadsheet/commit/8d850d06d [FIX] cf: drag & drop CF break on scroll Task: 3951043 https://github.com/odoo/o-spreadsheet/commit/985b2ba68 [FIX] BottomBarSheet: give focus back to grid after sheet name edition Task: 3945145 https://github.com/odoo/o-spreadsheet/commit/dfcbc9a31 [FIX] chartjs: remove forced hover dot size Task: 3869065 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix prevents delivery orders for different customers from being combined in two-step delivery workflows. It preserves the correct delivery address and ensures each customer gets a separate outbound delivery order.
Original PR description
### Issue: Pickings associated to different customers are merged in 2 steps delivery setups. ### Steps to reproduce: - Create 2 storable products: P1 and P2 - Enable multistep routes in the settings…
### Issue: Pickings associated to different customers are merged in 2 steps delivery setups. ### Steps to reproduce: - Create 2 storable products: P1 and P2 - Enable multistep routes in the settings > set Warehouse Routes - Create a new warehouse WH2 with 2 steps delivery - Go to inventory > Pick (WH2) - Create and validate a new pick for Customer 1: 1 x P1 Note: A delivery order was created for customer 1 - Create and validate a new pick for Customer 2: 1 x P2 ### Expected behavior: A delivery order is created for customer 2 ### Current behavior: The new delivery order is merged with delivery order created for customer 1 and the delivery address is erased as the picking would be associated with 2 contacts. ### Cause of the issue: When generated for the customer delivery is generated by the 2 step delivery the `_assign_picking` methods tries to assign the move to an existing picking if possible: https://github.com/odoo/odoo/blob/71b4a97c9e3da94bfc0130371db2c02beb81eebe/addons/stock/models/stock_move.py#L1250-L1254 However, the `partner_id` is only used in the search domain of this picking if the usage of the `location_id/dest_id` is a transit: https://github.com/odoo/odoo/blob/71b4a97c9e3da94bfc0130371db2c02beb81eebe/addons/stock/models/stock_move.py#L1240-L1241 This should also be the case when the destination is a customer. ### Note: The issue did not occur prior to saas-17.2 since no "Out" transfer were generated by manual pick transfer in 2 steps delivery prior to this version. opw-3857526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Adds a bit more information regarding one option for hotkeys. Forward-Port-Of: odoo/odoo#167716
Original PR description
Adds a bit more information regarding one option for hotkeys. Forward-Port-Of: odoo/odoo#167716
see also: https://github.com/odoo/enterprise/pull/63708 Forward-Port-Of: odoo/odoo#167738
Original PR description
see also: https://github.com/odoo/enterprise/pull/63708 Forward-Port-Of: odoo/odoo#167738
Ubuntu Noble (24.04) now provides [python3-websocket 1.7.0](https://packages.ubuntu.com/noble/python3-websocket). The websocket rate limiting tests asserts that an exception occurs when the code 1013 is returned because this code was not supported in [python3-websocket 1.2.3](https://packages.ubuntu.com/jammy/python3-websocket) provided by Ubuntu Jammy (22.04). Support was added in [websocket 1.3.0](https://github.com/websocket-client/websocket-client/commit/a28a016584f82cfca30a09a59ecd764569
Original PR description
Ubuntu Noble (24.04) now provides [python3-websocket 1.7.0](https://packages.ubuntu.com/noble/python3-websocket). The websocket rate limiting tests asserts that an exception occurs when the code 1013 is returned because this code was not supported in [python3-websocket 1.2.3](https://packages.ubuntu.com/jammy/python3-websocket) provided by Ubuntu Jammy (22.04). Support was added in [websocket 1.3.0](https://github.com/websocket-client/websocket-client/commit/a28a016584f82cfca30a09a59ecd764569c2fa3f) With this commit, presence of the status code in the lib is verified and the test is adapted accordingly. Forward-Port-Of: odoo/odoo#166899
Removed a work location column in the employee list view that is not relevant when the homeworking module is installed. Task-3933447 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166020
Original PR description
Removed a work location column in the employee list view that is not relevant when the homeworking module is installed. Task-3933447 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166020
Steps to reproduce [17.0]: - Go to website (in "Edit" mode) > Click on the "Contact Us" button - Save the page > The menu will be saved with the "oe_edited_link" class applied to it. Technical explanation (one of many scenarios causing the bug) [1]: After the website headers redesign in [2], two header navbars were added (for the desktop view and mobile). Which means that the "Contact Us" field is duplicated in the DOM. When clicking on the "Contact Us" desktop link, the `LinkPop
Original PR description
Steps to reproduce [17.0]: - Go to website (in "Edit" mode) > Click on the "Contact Us" button - Save the page > The menu will be saved with the "oe_edited_link" class applied to it. Technical…
Steps to reproduce [17.0]: - Go to website (in "Edit" mode) > Click on the "Contact Us" button - Save the page > The menu will be saved with the "oe_edited_link" class applied to it. Technical explanation (one of many scenarios causing the bug) [1]: After the website headers redesign in [2], two header navbars were added (for the desktop view and mobile). Which means that the "Contact Us" field is duplicated in the DOM. When clicking on the "Contact Us" desktop link, the `LinkPopoverWidget` will initialize a popover on it. The bootstrap code is automatically adding `data-original-title` and 'title' attributes to the targeted link (see: [3]), and as a consequence, the field observer will take in consideration the mutations and copy the DOM in the mobile version, leading to save the link in the same state when the BS popover was applied to it (with the `oe_edited_link` class). Remarks: - This behaviour was detected on 17.0, but we target 15.0 here to prevent similar issues linked to duplicated fields with links in the DOM. - The bootstrap attributes mutations (as explained in [1]) are just an example of many possible mutations (filtered by `observerUnactive()` in the main editor observer) that can cause the issue... Since we cannot set filters for all these mutations in the fields' observer, we ignore the `oe_edited_link` (and all editor's rendering classes) when copying the field content to solve the issue here. The field observer logic needs to be refactored to probably disable / enable the fields' synchronization when the editor's observer is disabled / enabled. [2]: https://github.com/odoo/odoo/pull/119650 [3]: https://github.com/odoo/odoo/blob/15.0/addons/web/static/lib/bootstrap/js/tooltip.js#L664 opw-3938383 Forward-Port-Of: odoo/odoo#167619 Forward-Port-Of: odoo/odoo#166736
For +100 on 5v: 160100 VAT credit For -100 on 4v: 260100 VAT debt task-3940102 opw-3938527 Forward-Port-Of: odoo/odoo#167731
Original PR description
For +100 on 5v: 160100 VAT credit For -100 on 4v: 260100 VAT debt task-3940102 opw-3938527 Forward-Port-Of: odoo/odoo#167731
Create a branch company [TEST] With [TEST] selected crete a new expense Issue: Taxes from parent company cannot be selected This occurs because we limit the domain to taxes of the current company, without considering the parent opw-3939722 Forward-Port-Of: odoo/odoo#167572
Original PR description
Create a branch company [TEST] With [TEST] selected crete a new expense Issue: Taxes from parent company cannot be selected This occurs because we limit the domain to taxes of the current company, without considering the parent opw-3939722 Forward-Port-Of: odoo/odoo#167572
Ensures that the exhibitor level badge is correctly displayed, as it was shown on a separate column for longer sponsor names. Now, it always appears inline, after the name of the sponsor. Task-3874059 Forward-Port-Of: odoo/odoo#162987
Original PR description
Ensures that the exhibitor level badge is correctly displayed, as it was shown on a separate column for longer sponsor names. Now, it always appears inline, after the name of the sponsor. Task-3874059 Forward-Port-Of: odoo/odoo#162987
Issue ----- When a partner has a valid peppol endpoint set but no bank account or country set, the user may not realize that the automatic generation for an electronic document has failed. For example when creating an invoice automatically for a subscription, there will only be an error note from odoobot, but no warning for the user like when creating an invoice manually. Fix ----- Display a warning to the user if some information is missing that would result in failling to generate the e
Original PR description
Issue ----- When a partner has a valid peppol endpoint set but no bank account or country set, the user may not realize that the automatic generation for an electronic document has failed. For example when creating an invoice automatically for a subscription, there will only be an error note from odoobot, but no warning for the user like when creating an invoice manually. Fix ----- Display a warning to the user if some information is missing that would result in failling to generate the expected electronic document. opw-3720730 Forward-Port-Of: odoo/odoo#163724
Steps: - Create a database on SaaS - Activate debug mode - Load demo data if not enabled - Install one of the module that use this template Actual result: - Module X installed - Demo data not loaded properly, traceback Expected result - Module X installed - Demo data loaded Initial PR on enterprise: https://github.com/odoo/enterprise/pull/63328 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167696
Original PR description
Steps: - Create a database on SaaS - Activate debug mode - Load demo data if not enabled - Install one of the module that use this template Actual result: - Module X installed - Demo data not loaded properly, traceback Expected result - Module X installed - Demo data loaded Initial PR on enterprise: https://github.com/odoo/enterprise/pull/63328 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167696
Steps to reproduce: - Install Time off module - Create a public holiday with Working Hours 'calendar_id' - Go to env user Time off dashboard Current behavior before PR: The public holidays that has 'calendar_id' assigned to it will not be shown in Legend when checking the dashboard of the env user. This is happening because we assign the self 'hr.employee' with the employee_id in context https://github.com/odoo/odoo/blob/c6142d9f1432cfabedcaa7264af9e5bc8e538c20/addons/hr_holidays/model
Original PR description
Steps to reproduce: - Install Time off module - Create a public holiday with Working Hours 'calendar_id' - Go to env user Time off dashboard Current behavior before PR: The public holidays that has…
Steps to reproduce:
- Install Time off module
- Create a public holiday with Working Hours 'calendar_id'
- Go to env user Time off dashboard
Current behavior before PR:
The public holidays that has 'calendar_id' assigned to it will not be shown in Legend when checking the dashboard of the env user. This is happening because we assign the self 'hr.employee' with the employee_id in context https://github.com/odoo/odoo/blob/c6142d9f1432cfabedcaa7264af9e5bc8e538c20/addons/hr_holidays/models/hr_employee.py#L313 and in '_get_contextual_employee' we just check if employee_id exists in ctx or not
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_employee.py#L388:L392
but we don't check the value so if ctx is like {'employee_id': None} it will return None.
Desired behavior after PR is merged:
We are now checking if the 'employee_id' in ctx
has a valid value as if it is not we need to return the employee object of the env user.
Other solution that we can add in this line https://github.com/odoo/odoo/blob/c6142d9f1432cfabedcaa7264af9e5bc8e538c20/addons/hr_holidays/models/hr_employee.py#L313 to check if the self._get_contetxtual_employee is None we assign self to self.env.user.employee_id
opw-3863947
Forward-Port-Of: odoo/odoo#166548Currently, if you have `pos_restaurant` but not `pos_self_order`, if you add a note on one line of the restaurant order, it visually disappears if you change table and then come back to it. Steps to reproduce: ------------------- * Install `pos_restanrant` * Uninstall `pos_self_order` * Open the restaurant session * Select a table and add an item to the order * Write an internal note > You can see the note on the line * Select **Change table** * Come back to the previous table > T
Original PR description
Currently, if you have `pos_restaurant` but not `pos_self_order`, if you add a note on one line of the restaurant order, it visually disappears if you change table and then come back to it. Steps to…
Currently, if you have `pos_restaurant` but not `pos_self_order`, if you add a note on one line of the restaurant order, it visually disappears if you change table and then come back to it. Steps to reproduce: ------------------- * Install `pos_restanrant` * Uninstall `pos_self_order` * Open the restaurant session * Select a table and add an item to the order * Write an internal note > You can see the note on the line * Select **Change table** * Come back to the previous table > The note is not visible anymore Why the fix: ------------ The note added is correctly registered but just invisible to the waiter. It is also visible in the display if you send the order in. The note field is added by the module `pos_restaurant` but loaded to the ui in `pos_self_order`. Technically the module `pos_self_order` gets auto-installed when `pos_restaurant` is installed but some customer might not have `pos_self_order` if they uninstalled it for example. `pos_self_order` depends on `pos_restaurant` so we can safely move the code that exports it inside the root module (`pos_restaurant`). The fix starts in 17.0 as in previous versions it was working fine with only `pos_restaurant` installed. opw-3917013 Forward-Port-Of: odoo/odoo#167223
**Steps to reproduce:** - open attendance module - go to overview and create a new attendance within 5:30 AM **Issue:** - Extra hours[overtime_hours] are not calculated accurately[output = 0]. **Cause:** The [SQL Query](https://github.com/odoo/odoo/blob/17.0/addons/hr_attendance/models/hr_attendance.py#L77-L91) [condition : date_trunc('day',att.check_in) = date_trunc('day', ot.date)] compares `att.check_in` time stored in UTC with `ot.date` stored in employee timezone, leading to inco
Original PR description
**Steps to reproduce:** - open attendance module - go to overview and create a new attendance within 5:30 AM **Issue:** - Extra hours[overtime_hours] are not calculated accurately[output = 0].…
**Steps to reproduce:**
- open attendance module
- go to overview and create a new attendance within 5:30 AM
**Issue:**
- Extra hours[overtime_hours] are not calculated accurately[output = 0].
**Cause:**
The [SQL Query](https://github.com/odoo/odoo/blob/17.0/addons/hr_attendance/models/hr_attendance.py#L77-L91)
[condition : date_trunc('day',att.check_in) = date_trunc('day', ot.date)] compares `att.check_in` time stored in UTC with `ot.date` stored in employee timezone, leading to incorrect calculations.
**Solution:**
Modify SQL query to convert `att.check_in` time to employee timezone before comparison with `ot.date`.
In saas-16.4, This [SQL Query](https://github.com/odoo/odoo/blob/saas-16.4/addons/hr_attendance/report/hr_attendance_report.py#L40-L46) is responsible for converting `check_in` time to employee
timezone.
Description of the issue/feature this PR addresses:
**Current behavior before PR:**
RUNBOT-17.0
**Desired behavior after PR is merged:**
UPG - 1573228
TASK - 3900287
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#167574
Forward-Port-Of: odoo/odoo#166302The Early Payment Discount (EPD) functionality is designed to work only with payment terms that include a single 100% line. A validation error is correctly displayed if a user attempts to create an EPD with multiple term lines. However, a bug existed where users could create a regular payment term with multiple lines, save it, and then enable the EPD, bypassing the validation. This allowed the record to be saved without error, leading to a traceback when the system later attempted to process
Original PR description
The Early Payment Discount (EPD) functionality is designed to work only with payment terms that include a single 100% line. A validation error is correctly displayed if a user attempts to create an EPD with multiple term lines. However, a bug existed where users could create a regular payment term with multiple lines, save it, and then enable the EPD, bypassing the validation. This allowed the record to be saved without error, leading to a traceback when the system later attempted to process the EPD, as it does not support multiple term lines. opw-3945596 Forward-Port-Of: odoo/odoo#167732
Issue ---- Demo company data contains a phone number of a real person, who receives phone calls from peolple asking to buy stuff :) Steps ---- Number is available on website footer. Cause ---- A real number is used in demo data. opw-3853066 Forward-Port-Of: odoo/odoo#164545
Original PR description
Issue ---- Demo company data contains a phone number of a real person, who receives phone calls from peolple asking to buy stuff :) Steps ---- Number is available on website footer. Cause ---- A real number is used in demo data. opw-3853066 Forward-Port-Of: odoo/odoo#164545
Description of the issue/feature this PR addresses: Livechat is set up with a Chatbot with a fallback to an operator. When a visitor visits a website with the Livechat and the visitor is not connected to an account, when falling back to the operator, an error occurs : `AttributeError: 'discuss.channel' object has no attribute 'livechat_visitor_id'` Current behavior before PR: When a visitor visits a website with the Livechat and the visitor is not connected to an account, when falling bac
Original PR description
Description of the issue/feature this PR addresses: Livechat is set up with a Chatbot with a fallback to an operator. When a visitor visits a website with the Livechat and the visitor is not connected to an account, when falling back to the operator, an error occurs : `AttributeError: 'discuss.channel' object has no attribute 'livechat_visitor_id'` Current behavior before PR: When a visitor visits a website with the Livechat and the visitor is not connected to an account, when falling back to the operator, an error occurs : `AttributeError: 'discuss.channel' object has no attribute 'livechat_visitor_id'` Desired behavior after PR is merged: The chatbot falls back to the human operator. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167710
Inspired by 8eba16db6fdf26b5a1e0a10d7f03863eb0d40632 Forward-Port-Of: odoo/odoo#167827 Forward-Port-Of: odoo/odoo#166959
Original PR description
Inspired by 8eba16db6fdf26b5a1e0a10d7f03863eb0d40632 Forward-Port-Of: odoo/odoo#167827 Forward-Port-Of: odoo/odoo#166959
Steps: - Install sale and editor apps. - Click on varient new button. - Add something in the description. - Discard that record. Issue: - Traceback component destroyed. Cause: - `commit_changes` does not had await on it and because of that it was performing other operations before actually commit changes and we are actully destroying record in `commit_changes` so there is no point doing other operations. Fix: - Add await and remove urgent from `commit_changes` method in-order t
Original PR description
Steps: - Install sale and editor apps. - Click on varient new button. - Add something in the description. - Discard that record. Issue: - Traceback component destroyed. Cause: - `commit_changes` does not had await on it and because of that it was performing other operations before actually commit changes and we are actully destroying record in `commit_changes` so there is no point doing other operations. Fix: - Add await and remove urgent from `commit_changes` method in-order to properly unmount component. opw-3892602 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#164151
The main purpose of this patch is to optimize how the location queries are generated in saas-17.2 in `stock.orderpoint`: https://github.com/odoo/odoo/blob/dd2da708bc4a42bba9670b874282a2206d8f5ffe/addons/stock/models/stock_orderpoint.py#L366-L374 The generated query is the same in 17.0. The advantage of the `any` operator is clarity and simplicity in this case. In saas-17.2 due to the presence of another branch using `location_final_id` the generated queries are much more efficient with
Original PR description
The main purpose of this patch is to optimize how the location queries are generated in saas-17.2 in `stock.orderpoint`:…
The main purpose of this patch is to optimize how the location queries
are generated in saas-17.2 in `stock.orderpoint`:
https://github.com/odoo/odoo/blob/dd2da708bc4a42bba9670b874282a2206d8f5ffe/addons/stock/models/stock_orderpoint.py#L366-L374
The generated query is the same in 17.0. The advantage of the `any` operator is
clarity and simplicity in this case.
In saas-17.2 due to the presence of another branch using
`location_final_id` the generated queries are much more efficient with
```py
dest_loc_domain = [
'|',
'&', ('location_final_id', '!=', False), ('location_final_id', 'any', paths_domain),
'&', ('location_final_id', '=', False), ('location_dest_id', 'any', paths_domain),
]
```
vs (current code in saas-17.2)
```py
dest_loc_domain = expression.OR([dest_loc_domain, [
'|',
'&', ('location_final_id', '!=', False), ('location_final_id.parent_path', '=like', location.parent_path + '%'),
'&', ('location_final_id', '=', False), ('location_dest_id.parent_path', '=like', location.parent_path + '%'),
]])
```
https://github.com/odoo/odoo/blob/88e75bb11053e3a16455f7d0e882cf2afd4b79a6/addons/stock/models/product.py#L311-L317
The version using the `any` operator is much faster: in an extreme case
with 6K replenish locations the any-based query runs in 1m50s while the
other runs in more than 3h.
In effect this is an example query generated by the ORM without the use
of `any` (3 replenish locations)
```sql
SELECT
"stock_move"."product_id",
"stock_move"."location_id",
SUM("stock_move"."product_qty")
FROM
"stock_move"
LEFT JOIN "stock_location" AS "stock_move__location_id" ON ("stock_move"."location_id" = "stock_move__location_id"."id")
LEFT JOIN "stock_location" AS "stock_move__location_final_id" ON ("stock_m ove"."location_final_id" = "stock_move__location_final_id"."id")
WHERE
(
(
(
(
(
(
(
(
(
"stock_move"."product_id" IN (16, 17, 18, 20, 21, 23, 24, 12, 13, 14, 25, 30, 26, 37, 31, 5, 8, 29, 32, 6, 28)
)
AND (
"stock_move"."state" IN ('waiting', 'confirmed', 'assigned', 'partially_available')
)
)
AND (
"stock_move"."location_final_id" IS NULL
OR (
"stock_move__location_final_id"."id" IS NULL
OR (
NOT (
(
"stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/18/%'
)
)
)
)
)
)
AND (
"stock_move"."location _final_id" IS NOT NULL
OR (
(
"stock_move"."location_dest_id" NOT IN (
SELECT
"stock_location"."id"
FROM
"stock_location"
WHERE
("stock_location"."parent_path" :: text LIKE '1/7/8/18/%')
AND (( "stock_location"."company _id" IN (1))
OR "stock_location"."company_id" IS NULL
)
)
)
OR "stock_move"."location_dest_id" IS NULL
)
)
)
AND (
"stock_move"."location_final_id" IS NULL
OR (
"stock_move__location_final_id"."id" IS NULL
OR (NOT (("stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/17/%')))
)
)
)
AND (
"stock_move"."location_final_id" IS NOT NULL
OR (
(
"stock_move"."location_dest_id" NOT IN (
SELECT
"stock_location"."id"
FROM
"stock_locati on"
WHERE
("stock_location"."parent_path" :: text LIKE '1/7/8/17/%')
AND (("stock_location"."company_id" IN (1))
OR "stock_location"."company_id" IS NULL
)
)
)
OR "stock_move"."location_dest_id" IS NULL
)
)
)
AND (
"stock_ move"."location_final_id" IS NULL
OR (
"stock_move__location_final_id"."id" IS NULL
OR (
NOT (( "stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/34/%')
)
)
)
)
)
AND (
"stock_move"."location_final_id" IS NOT NULL
OR (
(
"stock_move"."location_dest_id" NOT IN (
SELECT
"stock_location"."id"
FROM
"stock_location"
WHERE
("stock_location"."parent_path" :: text LIKE '1/7/8/34/%')
AND (
("stock_location"."company_id" IN (1))
OR " stock_location"."company_id" IS NULL
)
)
)
OR "stock_move"."location_dest_id" IS NULL
)
)
)
AND (
(
("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/18/%')
OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/17/%')
)
OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/34/%')
)
)
AND (
"stock_move"."company_id" IN (1)
)
GROUP BY
"stock_move"."product_id",
"stock_move"."location_id"
ORDER BY
"stock_move"."product_id" ASC,
"stock_move"."location_id" ASC
```
vs the query using `any` variant:
```sql
SELECT
"stock_move"."product_id",
"stock_move"."location_id",
sum("stock_move"."product_qty")
FROM
"stock_move"
LEFT JOIN "stock_location" AS "stock_move__location_id" ON ("stock_move"."location_id" = "stock_move__location_id"."id")
LEFT JOIN "stock_location" AS "stock_move__location_final_id" ON ("stock_m ove"."location_final_id" = "stock_move__location_final_id"."id")
WHERE
(
(
(
(
(
"stock_move"."product_id" IN (16, 17, 18, 20, 21, 23, 24, 12, 13, 14, 25, 30, 26, 37, 31, 5, 8, 29, 32, 6, 28)
)
AND (
"stock_move"."state" IN ('waiting', 'confirmed', 'assigned', 'partially_available')
)
)
AND (
"stock_move"."location_final_id" IS NULL
OR (
"stock_move__location_final_id"."id" IS NULL
OR (
NOT (
(
(
("stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/18/%')
OR ("stock_move__location_final_id "."parent_path" :: text LIKE '1/7/8/17/%')
)
OR ("stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/34/%')
)
)
)
)
)
)
AND (
"stock_move"."location_final_id" IS NOT NULL
OR (
(
"stock_move"."location_dest_id" NOT IN (
SELECT
"stock_location"."id"
FROM
"stock_location"
WHERE
(
(
("stock_location"."parent_path" :: text LIKE '1/7/8/18/%')
OR ("stock_location"."parent_path" :: text LIKE '1/7/8/17/%')
)
OR ("stock_location"."parent_pa th" :: text LIKE '1/7/8/34/%')
)
AND (
("stock_location"."company_id" IN (1))
OR "stock_location"."company_id" IS NULL
)
)
)
OR "stock_move"."location_dest_id" IS NULL
)
)
)
AND (
(
("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/18/%')
OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/17/%')
)
OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/34/%')
)
)
AND (
"stock_move"."company_id" IN (1)
)
GROUP BY
"stock_move"."product_id",
"stock_move"."location_id"
ORDER BY
"stock_move"."product_id" ASC,
"stock_move"."location_id" ASC
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#167553Issue: ------ In the input of a float factor field, it is not possible to use the ‘,’ as a decimal point, even if this is defined in the localization. This is because the value is calculated via: ```js let factorValue = value / this.props.factor; ``` does not work with `value = ‘x,y’` and will return `NaN`. Solution: --------- Parser the value by calling super to fallback on `parseFloat` which takes localization into account. opw-3932813 Forward-Port-Of: odoo/odoo#166822
Original PR description
Issue: ------ In the input of a float factor field, it is not possible to use the ‘,’ as a decimal point, even if this is defined in the localization. This is because the value is calculated via: ```js let factorValue = value / this.props.factor; ``` does not work with `value = ‘x,y’` and will return `NaN`. Solution: --------- Parser the value by calling super to fallback on `parseFloat` which takes localization into account. opw-3932813 Forward-Port-Of: odoo/odoo#166822
Purpose ======= Fix the session chart labels which were disappearing when zooming on the chart. Specification ============= When zooming, the chart x axis ticks were skipped / hidden leading to the labels disappearance. Fixing the issue by preventing the x axis ticks from being skipped. Task-3918382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167914 Forward-Port-Of: odoo/odoo#166462
Original PR description
Purpose ======= Fix the session chart labels which were disappearing when zooming on the chart. Specification ============= When zooming, the chart x axis ticks were skipped / hidden leading to the labels disappearance. Fixing the issue by preventing the x axis ticks from being skipped. Task-3918382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167914 Forward-Port-Of: odoo/odoo#166462
When setting `l10n_it_has_tax_representative` to False, the field `l10n_it_tax_representative_partner_id` stays set, this leads to inconsistencies when generating the xml on e-invoicing. Steps: - Install l10n_it_edi - Go to the form view of the italian company - On E-invoicing tab, check the `l10n_it_has_tax_representative` field, set `l10n_it_tax_representative_partner` and save - Create and confirm an invoice - Check the xml that has been generated, there is a field `RappresentanteFiscal
Original PR description
When setting `l10n_it_has_tax_representative` to False, the field `l10n_it_tax_representative_partner_id` stays set, this leads to inconsistencies when generating the xml on e-invoicing. Steps: - Install l10n_it_edi - Go to the form view of the italian company - On E-invoicing tab, check the `l10n_it_has_tax_representative` field, set `l10n_it_tax_representative_partner` and save - Create and confirm an invoice - Check the xml that has been generated, there is a field `RappresentanteFiscale` with `l10n_it_tax_representative_partner` infos - Go back to company form view, uncheck the `l10n_it_has_tax_representative` field and save - Create and confirm an other invoice - Check the xml generated -> The field `RappresentanteFiscale` is still there, it should not be. Fix: Add a compute to `l10n_it_tax_representative_partner` to set it to False when unchecking `l10n_it_has_tax_representative` opw-3947519 Forward-Port-Of: odoo/odoo#167825 Forward-Port-Of: odoo/odoo#166732
Purpose ======= Fix the tooltip header color which wasn't reactive to the theme color (light vs dark theme). The header text is black instead of white in light theme and is thus not visible on the tooltip black background. Specification ============= Overwritting the h5 color style that is set to a dark color by the basic bootstrap style. The border-bottom isn't visible in the dark theme because of the tooltip border color style. This border style is applied to the external border
Original PR description
Purpose ======= Fix the tooltip header color which wasn't reactive to the theme color (light vs dark theme). The header text is black instead of white in light theme and is thus not visible on the tooltip black background. Specification ============= Overwritting the h5 color style that is set to a dark color by the basic bootstrap style. The border-bottom isn't visible in the dark theme because of the tooltip border color style. This border style is applied to the external borders of the tooltip and thus shoudln't be changed. Replacing the border-bottom class by a hr tag as it is more adequate for a divider and its color is independant from the tooltip basic border color. Task-3956309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167833 Forward-Port-Of: odoo/odoo#167174
Problem: When a user saves a quotation in the POS session, the quotation gets confirmed into a SO and its invoice_status is "invoiced" but no invoice was created. This occurs because the POS has another POS as its trusted POS. The user is expected the quotation to stay as a quotation when they save it in the POS. Steps to reproduce: - Install "Point of Sale" and "Sales" apps - Create another POS that is not a bar/restaurant - On the settings of the "Shop" POS, set the newly created POS as
Original PR description
Problem: When a user saves a quotation in the POS session, the quotation gets confirmed into a SO and its invoice_status is "invoiced" but no invoice was created. This occurs because the POS has…
Problem: When a user saves a quotation in the POS session, the quotation gets confirmed into a SO and its invoice_status is "invoiced" but no invoice was created. This occurs because the POS has another POS as its trusted POS. The user is expected the quotation to stay as a quotation when they save it in the POS. Steps to reproduce: - Install "Point of Sale" and "Sales" apps - Create another POS that is not a bar/restaurant - On the settings of the "Shop" POS, set the newly created POS as its trusted POS - Create a sales quotation and save - Open a session in "Shop" POS and click "quotation/order" to import the sales quotation and click on "Settle the order" - Click on save - The quotation is now confirmed into a SO when it should not be Cause: All quotations with state "draft" or "sent" are confirmed while they shouldn't if the sale is not completed Solution: As the variable "draft" from "create_from_ui" is True when saving a quotation and is False when confirming an order, we can use it to proceed or not the confirmation of the quotation opw-3885845 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167762 Forward-Port-Of: odoo/odoo#166485
Add a background image for the iot homepage 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#167010
Original PR description
Add a background image for the iot homepage 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#167010
Description of the issue this commit addresses: When creating an invoice line with the analytic module installed, if the analytic field is show, focusing in on a line adds a little height offset to the entire line which makes the view shaky. This is not wanted. --- Steps to reproduce: 1 - Install analytic app 2 - Open a new invoice and display the analytic field in the invoice lines 3 - Add a new line, don't add any data inside it. 4 - Focus out, focus in, focus out, focus in. 5
Original PR description
Description of the issue this commit addresses: When creating an invoice line with the analytic module installed, if the analytic field is show, focusing in on a line adds a little height offset to…
Description of the issue this commit addresses: When creating an invoice line with the analytic module installed, if the analytic field is show, focusing in on a line adds a little height offset to the entire line which makes the view shaky. This is not wanted. --- Steps to reproduce: 1 - Install analytic app 2 - Open a new invoice and display the analytic field in the invoice lines 3 - Add a new line, don't add any data inside it. 4 - Focus out, focus in, focus out, focus in. 5 - You can see that focus in adds a few px and focus out removes them. --- Desired behavior after this commit is merged: This commit adds a fixed default height to the analyti widget to make sure there is no weird height computation when the focus happens. This way, we can make sure that the line height stays constant whether the focus is in or out of the line. --- no task-feedback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167723
Since [1] the legends tooltips are misplaced. A similar issue has been fixed for the main tooltips of the graph view. See [2] Since [3] the Chart.js lib has been updated and the event received by hovering the legend is now wrapped in an object. To access the native event we also need to access the `native` key of that object. [1]: https://github.com/odoo/odoo/commit/c8ca9da7bcee2c122a9d6cf8cda89f02823ba42d [2]: https://github.com/odoo/odoo/commit/c1f08c60b7272e5a30951c53b67427e2f205b72
Original PR description
Since [1] the legends tooltips are misplaced. A similar issue has been fixed for the main tooltips of the graph view. See [2] Since [3] the Chart.js lib has been updated and the event received by hovering the legend is now wrapped in an object. To access the native event we also need to access the `native` key of that object. [1]: https://github.com/odoo/odoo/commit/c8ca9da7bcee2c122a9d6cf8cda89f02823ba42d [2]: https://github.com/odoo/odoo/commit/c1f08c60b7272e5a30951c53b67427e2f205b722 [3]: https://github.com/odoo/odoo/commit/7e3c1ecdb86110912b15722e600f9571692807ed Forward-Port-Of: odoo/odoo#167971
- Remove the zero-rated tax from non-taxable tags as it is incorrectly applied, and instead, add it to items tagged with GST. - task - 3957555 Forward-Port-Of: odoo/odoo#167754
Original PR description
- Remove the zero-rated tax from non-taxable tags as it is incorrectly applied, and instead, add it to items tagged with GST. - task - 3957555 Forward-Port-Of: odoo/odoo#167754
Before this commit, loading an attribute value with an image would cause a TypeError due to the image data being of bytes type, which is not JSON serializable. This commit prevents this error by removing the image data before serialization. opw-3957587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167765
Original PR description
Before this commit, loading an attribute value with an image would cause a TypeError due to the image data being of bytes type, which is not JSON serializable. This commit prevents this error by removing the image data before serialization. opw-3957587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167765
Steps to reproduce: - Install Sales and Loyalty modules - Create a discount & loyalty program with type of 'Buy X get Y' and a reward product that has a quantity on-hand - Archive the discount & loyalty program - Check the quantity of the product you put as reward Current behavior before PR: The reward product lose its quantity when archiving the corresponding discount & loyalty program. This is happening because when archiving the program we archive the reward product too. https://
Original PR description
Steps to reproduce: - Install Sales and Loyalty modules - Create a discount & loyalty program with type of 'Buy X get Y' and a reward product that has a quantity on-hand - Archive the discount & loyalty program - Check the quantity of the product you put as reward Current behavior before PR: The reward product lose its quantity when archiving the corresponding discount & loyalty program. This is happening because when archiving the program we archive the reward product too. https://github.com/odoo/odoo/blob/17.0/addons/loyalty/models/loyalty_reward.py#L239 Desired behavior after PR is merged: We are now archiving just the free product that got created when we were creating the discount & loyalty program not the main product. This is happening only when the reward type is 'Product' opw-3909184 Forward-Port-Of: odoo/odoo#165225
In this PR fixes following bugs: - Subtasks don't set by-default to the configured stage. users have to manually set it after saving. - Expected: stages by default set upon creation. - the task name goes empty after selecting a project, even if you rewrite it and switch projects. This only happens in the Quick Add feature in the kanban view after enabling timesheets in the project settings. task-3706741 Description of the issue/feature this PR addresses: Current behavior b
Original PR description
In this PR fixes following bugs: - Subtasks don't set by-default to the configured stage. users have to manually set it after saving. - Expected: stages by default set upon creation. - the task name goes empty after selecting a project, even if you rewrite it and switch projects. This only happens in the Quick Add feature in the kanban view after enabling timesheets in the project settings. task-3706741 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#153607
In this Pr, the driver or the future driver of the car is in sync with the partner of the employee Task-3693838 Forward-Port-Of: odoo/odoo#157057
Original PR description
In this Pr, the driver or the future driver of the car is in sync with the partner of the employee Task-3693838 Forward-Port-Of: odoo/odoo#157057
**Description of the issue/feature this PR addresses:** fine tuning of https://github.com/odoo/odoo/commit/f8182fb625eb3e20c85388d4c342553af4fe7ab9 to prevent an olverload of postgres. @thle-odoo @sofiagvaladze I have update the commit. I use 'inselect' to reduce the query size. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167439
Original PR description
**Description of the issue/feature this PR addresses:** fine tuning of https://github.com/odoo/odoo/commit/f8182fb625eb3e20c85388d4c342553af4fe7ab9 to prevent an olverload of postgres. @thle-odoo @sofiagvaladze I have update the commit. I use 'inselect' to reduce the query size. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167439
Problem: When a quotation is printed for a client in a different language that uses different decimal separators, the discounted price for optional products are not being displayed with the same decimal separators used throughout the quotation. Purpose: The formats of the price should be consistent. Steps to Reproduce on Runbot: 1. Install Sales 2. Enable Discounts in Setting > Sales 3. Create a quotation with a German customer and discounted optional products 4. Print the quotation 5
Original PR description
Problem: When a quotation is printed for a client in a different language that uses different decimal separators, the discounted price for optional products are not being displayed with the same decimal separators used throughout the quotation. Purpose: The formats of the price should be consistent. Steps to Reproduce on Runbot: 1. Install Sales 2. Enable Discounts in Setting > Sales 3. Create a quotation with a German customer and discounted optional products 4. Print the quotation 5. Observe the discounted price has inconsistent formatting (ex. shows 140.00 instead of 140,00 since German uses , as decimal separators) opw-3853464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167688 Forward-Port-Of: odoo/odoo#165888
Prior to this commit, if a reward product domain contained a field that was not loaded into the Point of Sale (PoS), the promotion would not function correctly. This commit resolves this issue by adding the missing fields, ensuring that the promotion operates as expected. opw-3896038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164892
Original PR description
Prior to this commit, if a reward product domain contained a field that was not loaded into the Point of Sale (PoS), the promotion would not function correctly. This commit resolves this issue by adding the missing fields, ensuring that the promotion operates as expected. opw-3896038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164892
27 changes
Enhancements to existing features
Task-related time fields in the Project Gantt view are now shown only to users with timesheet access. This keeps sensitive or role-specific time planning information out of view for users who do not need it.
Original PR description
After this commit, time fields (e.g. allocated_hours, ...) related to tasks in the Project module are only visible if the user has the "hr_timesheet.group_hr_timesheet_user" group. task-3815771
The follow-up reminder wizard layout has been streamlined to make email, SMS, and postal mail options easier to review and select. This improves usability for staff preparing customer payment follow-ups by reducing visual clutter and aligning related messages with their checkboxes.
Original PR description
In this commit, we will do multiple modifications to improve the display of the followup wizard. The following changes has been done: - Remove the title "Actions" - Made the checkbox on the same line - Moving the group for the sms below the things about the email - Using classes instead of inline style - Putting the snailmail message next to the according checkbox and not in a group below. task:3931191
This update strengthens the internal checks behind spreadsheet global filters, helping reduce future errors when filters are edited or maintained. The change is mostly technical and should not alter day-to-day behavior for users, but it improves long-term stability of spreadsheet filtering.
Original PR description
This commit fixes & improves the typing of the global filter related files, and enable type checking on the files. Note that some files are still in red for typing issues: - in the business code, it's mostly due to wrong typing of LazyTranslatedString - in the tests, the import of legacy files isn't resolving properly. Task: [3948130](https://www.odoo.com/web#id=3948130&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Employees or managers who try to delete attendance or planning records tied to already validated work entries now receive clearer error notifications. This helps prevent accidental removal of records that are part of confirmed payroll or scheduling data, reducing confusion and data integrity risks.
Original PR description
This PR improves the deletion functionality for attendance and planning records linked with validated work entries. Users attempting to delete attendance and planning data associated with validated work entries will now receive appropriate error notifications. task-3815646
New export templates have been added to service-related apps so users can more easily export the most relevant fields from their database. This streamlines data extraction for project and timesheet-related workflows and reduces manual setup when exporting information.
Original PR description
This commit will add export templates to some apps of the services scope, in order to help user export relevant fields from their database. task-3830283
Manufacturing planners can now use a three-week Gantt view covering the current week and the next two weeks. This gives teams a more practical planning window for daily manufacturing work, especially near the end of a period.
Original PR description
The Gantt view is not very useful for planning manufacturing orders, especially towards the end of your period. We are introducing a 3-week mode: the current one and the following 2 weeks. It is more usable for daily work.
The VoIP softphone error message is now centered and easier to read. Its styling has also been adjusted for dark mode, giving users a cleaner and more consistent experience when errors appear.
Original PR description
Prior to this commit, the VoIP error text was not properly centered within the overlay div, and had background color issues in dark mode. This commit restructures the code for improved maintainability, centers the error text, updates a few classes, and adapts the design for dark mode.. task-3539670 | Master | This PR | |--------|--------| | <img alt="image" src="https://github.com/odoo/enterprise/assets/80678921/c9af3455-7562-40ec-af78-ac6c98a384bd"> | <img alt="image" src="https://github.com/odoo/enterprise/assets/80678921/119ccd03-9b80-424d-894e-847264678143"> | <details> <summary>Dark Mode</summary> | Master | This PR | |--------|--------| | <img alt="image" src="https://github.com/odoo/enterprise/assets/80678921/f83bc318-5fe0-4d52-ab2c-029875eead79"> | <img alt="image" src="https://github.com/odoo/enterprise/assets/80678921/0b56d874-5bd0-4ddc-84ab-5b66e6f85cea"> | </details>
Resolved issues and error corrections
This fixes an issue where discounts on subscription upsell orders could be applied incorrectly. It helps ensure customers receive the intended pricing and reduces the risk of billing errors during upsell transactions.
Features or functions removed from Odoo
The Belgian payroll double pay recovery wizard has been simplified by removing a field that was populated but never actually used. This reduces unnecessary internal complexity without changing how users work with the wizard.
Original PR description
In the double pay recovery wizard, there is a field 'classic_holiday_pay' which is never used. Its value is set but never read. Task: 3932947
Code cleanup and technical improvements
This internal cleanup prepares Odoo's guided test tours for a clearer default behavior. It reduces ambiguity in automated test steps, helping future updates be safer and easier to maintain without changing day-to-day user workflows.
Original PR description
Currently, in tour_compiler, to check that an element is actually present in the DOM in a step, there are 2 possibilities. - `isCheck: true` => Checks that the element is in the DOM. The latter can…
Currently, in tour_compiler, to check that an element is actually present in the DOM in a step, there are 2 possibilities.
- `isCheck: true` => Checks that the element is in the DOM. The latter can be disabled.
- `run() {}` => Checks that the element is in the DOM (because this is what is done by default). However, if the element is disabled, the step will be aborted.
In the codebase, we can see a lot of `run() {} //it's a check` and `isCheck:true`. However, the behavior is not exactly the same. What's more, there are 2 ways to do "the same thing". In order to clarify the turns API, it was decided to no longer put an action (step.run) by default. (Previously, the default action was the "click" action).
From then on, it is no longer necessary to stipulate `step.isCheck: true` nor `run() {}`.
The corollary is that now, you must explicitly write `run: click`, if you want the click action to be triggered on the target.
This commit sets the stage for making this change.
https://github.com/odoo/odoo/pull/167743Miscellaneous changes
In the balance sheet and Profit & Loss reports, we allow users to audit the General Ledger of a specific account if we want to look at the details of that account for the period of the report. When clicking on the link of the audit, it works well for small db, but if the account is low in the list, you don't even see it. This commit adds a default filter on the report. task-3839845 Forward-Port-Of: odoo/enterprise#63775 Forward-Port-Of: odoo/enterprise#60827
Original PR description
In the balance sheet and Profit & Loss reports, we allow users to audit the General Ledger of a specific account if we want to look at the details of that account for the period of the report. When clicking on the link of the audit, it works well for small db, but if the account is low in the list, you don't even see it. This commit adds a default filter on the report. task-3839845 Forward-Port-Of: odoo/enterprise#63775 Forward-Port-Of: odoo/enterprise#60827
users were getting a traceback from the sdk when credentials were incorrect AttributeError: 'Response' object has no attribute '_dom' opw-3873151 Forward-Port-Of: odoo/enterprise#63735 Forward-Port-Of: odoo/enterprise#62049
Original PR description
users were getting a traceback from the sdk when credentials were incorrect AttributeError: 'Response' object has no attribute '_dom' opw-3873151 Forward-Port-Of: odoo/enterprise#63735 Forward-Port-Of: odoo/enterprise#62049
Currently, an error occurs when installing a 'l10n_ec_edi' module. Step to produce: - Create a company and set its country 'Ecuador'. - And install the 'l10n_ec_edi' module. ```ValueError: External ID not found in the system: account.1_ec_sale_withhold_tax_base``` An error occurs when the system tries to retrieve a 'Sales Tax Base Account' through account view id at [1], but the view id is not available. To handle this issue, add 'raise_if_not_found=False' so that if the external
Original PR description
Currently, an error occurs when installing a 'l10n_ec_edi' module. Step to produce: - Create a company and set its country 'Ecuador'. - And install the 'l10n_ec_edi' module. ```ValueError: External ID not found in the system: account.1_ec_sale_withhold_tax_base``` An error occurs when the system tries to retrieve a 'Sales Tax Base Account' through account view id at [1], but the view id is not available. To handle this issue, add 'raise_if_not_found=False' so that if the external id of view is not found, the 'Sales Tax Base Account' will get an empty record. sentry-5183479269 Forward-Port-Of: odoo/enterprise#62700
Followup to refactoring that removed the product type=product (i.e. storable). Remove some leftover references to it. Forward-Port-Of: odoo/enterprise#63612
Original PR description
Followup to refactoring that removed the product type=product (i.e. storable). Remove some leftover references to it. Forward-Port-Of: odoo/enterprise#63612
Access with User having Accounting permissions Open a posted invoice Click 'Reset to draft' Delete the draft invoice Issue: Access Error will raise """ This operation is allowed for the following groups: - Payroll/Officer : Manage all contracts Contact your administrator to request access if necessary. """ Accounting user should be able to unlink the draft without having payroll permissions opw-3932705 Forward-Port-Of: odoo/enterprise#63262
Original PR description
Access with User having Accounting permissions Open a posted invoice Click 'Reset to draft' Delete the draft invoice Issue: Access Error will raise """ This operation is allowed for the following groups: - Payroll/Officer : Manage all contracts Contact your administrator to request access if necessary. """ Accounting user should be able to unlink the draft without having payroll permissions opw-3932705 Forward-Port-Of: odoo/enterprise#63262
Before this commit, when sending an invoice to the AFIP and that the result was accepted, it was still possible to reset the invoice the draft which caused discrepancies between the data in Odoo and the data that has already been sent to AFIP. This button to reset to draft is enabled for all users in Accounting. After an invoice is sent and validated, we cannot edit them. task-3955111 Forward-Port-Of: odoo/enterprise#63407
Original PR description
Before this commit, when sending an invoice to the AFIP and that the result was accepted, it was still possible to reset the invoice the draft which caused discrepancies between the data in Odoo and the data that has already been sent to AFIP. This button to reset to draft is enabled for all users in Accounting. After an invoice is sent and validated, we cannot edit them. task-3955111 Forward-Port-Of: odoo/enterprise#63407
Forward-Port-Of: odoo/enterprise#63578
Original PR description
Forward-Port-Of: odoo/enterprise#63578
also modified: test_marketing_automation Previously, campaign templates could not be used by non-admin users. This commit allows non-admin users with access to the marketing_automation app to create campaigns from templates as expected. task-3603400 Backport of: odoo@8fcdb85f0c4279c6a16c26aa669496cf456f0631 Forward-Port-Of: odoo/enterprise#63155
Original PR description
also modified: test_marketing_automation Previously, campaign templates could not be used by non-admin users. This commit allows non-admin users with access to the marketing_automation app to create campaigns from templates as expected. task-3603400 Backport of: odoo@8fcdb85f0c4279c6a16c26aa669496cf456f0631 Forward-Port-Of: odoo/enterprise#63155
Steps to reproduce: - share a workspace with more than one document and a spreadsheet - open the sharing link,(make sure you are login as internal user) - from the sharing portal page, click on the spreadsheet title to open the spreadsheet => access right error Task: 3897719 Forward-Port-Of: odoo/enterprise#63256
Original PR description
Steps to reproduce: - share a workspace with more than one document and a spreadsheet - open the sharing link,(make sure you are login as internal user) - from the sharing portal page, click on the spreadsheet title to open the spreadsheet => access right error Task: 3897719 Forward-Port-Of: odoo/enterprise#63256
If we upload a Soda and an account is not mapped, we'll fall back on the Suspense Account. However, when modifying the entry line with the Suspense Account, the general Soda Mapping is not updated. For UX reasons, we should update the general Soda Mapping too so that the user doesn't have to modify it twice. However, we shouldn't do the reverse. I.e. when modifying the general Soda Mapping, we shouldn't modify the existing entries. taks-id: 3954585 Forward-Port-Of: odoo/enterprise#6
Original PR description
If we upload a Soda and an account is not mapped, we'll fall back on the Suspense Account. However, when modifying the entry line with the Suspense Account, the general Soda Mapping is not updated. For UX reasons, we should update the general Soda Mapping too so that the user doesn't have to modify it twice. However, we shouldn't do the reverse. I.e. when modifying the general Soda Mapping, we shouldn't modify the existing entries. taks-id: 3954585 Forward-Port-Of: odoo/enterprise#63691 Forward-Port-Of: odoo/enterprise#63356
Some of the records had their `groupby` set to `account_id` in previous versions That field was removed from the data file and new expressions were added. This means that the records which already have `groupby` set won't get that field updated during an upgrade, and will trigger [an error](https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_report.py#L571-L578). By explicitly removing the value from the field, we ensure the field will be emptied. The change in the data fi
Original PR description
Some of the records had their `groupby` set to `account_id` in previous versions That field was removed from the data file and new expressions were added. This means that the records which already…
Some of the records had their `groupby` set to `account_id` in previous versions That field was removed from the data file and new expressions were added. This means that the records which already have `groupby` set won't get that field updated during an upgrade, and will trigger [an error](https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_report.py#L571-L578). By explicitly removing the value from the field, we ensure the field will be emptied. The change in the data files comes from: https://github.com/odoo/enterprise/pull/52603 ``` odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/l10n_ro_reports/data/balance_sheet_short.xml:3 Groupby feature isn't supported by aggregation engine. Please remove the groupby value on 'SOLDE C | 43' ``` Note: The original change to the data file happened in saas~16.1. Given that it's not possible to upgrade to intermediate versions any more and there's no issue in standard, the PR targets 17.0. Forward-Port-Of: odoo/enterprise#62421
This commit fixes an issue with the Knowledge Article Thread notifications where the user would be redirected to the technical view instead of the Article's view. To fix this, the threadActionsRegistry has been updated for the `expand-form` action so that if the thread model is a `knowledge.article.thread`, it will redirect the user to the corresponding article. task-3904795 Forward-Port-Of: odoo/enterprise#63779 Forward-Port-Of: odoo/enterprise#62024
Original PR description
This commit fixes an issue with the Knowledge Article Thread notifications where the user would be redirected to the technical view instead of the Article's view. To fix this, the threadActionsRegistry has been updated for the `expand-form` action so that if the thread model is a `knowledge.article.thread`, it will redirect the user to the corresponding article. task-3904795 Forward-Port-Of: odoo/enterprise#63779 Forward-Port-Of: odoo/enterprise#62024
In order to see all the resulting pages on the saas databases, we publish them by default. Also fixes a bug which would throw an error when menus had the same name. Forward-Port-Of: odoo/enterprise#63795
Original PR description
In order to see all the resulting pages on the saas databases, we publish them by default. Also fixes a bug which would throw an error when menus had the same name. Forward-Port-Of: odoo/enterprise#63795
There were translations such as "1. Gross profit/gross loss", which were translated to "1. Annoncering og reklame" That translation does not match and we have therefore identified the ones that were off and updated them Forward-Port-Of: odoo/enterprise#63564
Original PR description
There were translations such as "1. Gross profit/gross loss", which were translated to "1. Annoncering og reklame" That translation does not match and we have therefore identified the ones that were off and updated them Forward-Port-Of: odoo/enterprise#63564
When using the 'Find missing transactions' from account_online_synchronization module, the `transaction_details` field gets encapsulated in `<p></p>` HTML tags This is caused by that field being declared as a HTML field in the transient model `account.bank.statement.line.transient`, but then as a JSON field in the `account.bank.statement.line` model. That encapsulation causes Python JSON decoder to fail to decode from `transaction_details` when called in `_format_transaction_details()
Original PR description
When using the 'Find missing transactions' from account_online_synchronization module, the `transaction_details` field gets encapsulated in `<p></p>` HTML tags This is caused by that field being declared as a HTML field in the transient model `account.bank.statement.line.transient`, but then as a JSON field in the `account.bank.statement.line` model. That encapsulation causes Python JSON decoder to fail to decode from `transaction_details` when called in `_format_transaction_details()` in the bank reconciliation widget, resulting in a traceback Removing the HTML tags after the call to `read()` in the transient model allows the field to be correctly decoded. opw-3783078 opw-3773454 opw-3772561 and more.
[FIX] account_reports: adapt pil usage for ubuntu noble The `getsize` method on a FreeTypeFont object was deprecated [0] in Pillow 9.2.0. Ubuntu Noble provides Pillow 10.2.0. They advise to use `getbbox` which is already available in Pillow 9.0.1 provided by Ubuntu Jammy. See: https://pillow.readthedocs.io/en/stable/releasenotes/9.2.0.html#font-size-and-offset-methods [FIX] account_report: adapt xlsxwriter usage for ubuntu noble The `col_sizes` attribute
Original PR description
[FIX] account_reports: adapt pil usage for ubuntu noble The `getsize` method on a FreeTypeFont object was deprecated [0] in Pillow 9.2.0. Ubuntu Noble provides Pillow 10.2.0. They advise to use…
[FIX] account_reports: adapt pil usage for ubuntu noble
The `getsize` method on a FreeTypeFont object was deprecated [0] in Pillow
9.2.0. Ubuntu Noble provides Pillow 10.2.0. They advise to use `getbbox`
which is already available in Pillow 9.0.1 provided by Ubuntu Jammy.
See: https://pillow.readthedocs.io/en/stable/releasenotes/9.2.0.html#font-size-and-offset-methods
[FIX] account_report: adapt xlsxwriter usage for ubuntu noble
The `col_sizes` attribute on an worksheet was removed in xlsxwriter
version 3.0.6 [0]. Ubuntu Noble provides xlsxwriter 3.1.9.
The xlsxwriter author advises [1] to use the `col_info` attribute
instead, but this attribute appeared in 3.0.6 too (rename of `colinfo`).
With this commit, the version is checked in order to use the right
attribute.
See: jmcnamara/XlsxWriter@860f4a2404549aca1eccf9bf8361df95dc574f44
and jmcnamara/XlsxWriter#937
Forward-Port-Of: odoo/enterprise#63762
Forward-Port-Of: odoo/enterprise#63515The tariff fraction catalog has been updated on April 2024: https://www.snice.gob.mx/cs/avi/snice/ligie.info22.mod24.html opw-3921546 Forward-Port-Of: odoo/enterprise#63730 Forward-Port-Of: odoo/enterprise#62638
Original PR description
The tariff fraction catalog has been updated on April 2024: https://www.snice.gob.mx/cs/avi/snice/ligie.info22.mod24.html opw-3921546 Forward-Port-Of: odoo/enterprise#63730 Forward-Port-Of: odoo/enterprise#62638
11 changes
Enhancements to existing features
This update improves how foreign currencies are handled when synchronizing bank transactions from Odoofin. The system now automatically activates foreign currencies, properly converts currency codes to currency IDs for correct display, and prevents validation errors. This ensures smoother bank reconciliation for companies dealing with multiple currencies.
Original PR description
...d on foreign_currency_code received from odoofin Send `include_foreign_currency` to odoofin to avoid throwing errors when odoofin returns `foreign_currency_code` and `amount_currency` for customers that don't have the fix. Convert `foreign_currency_code` to corresponding `foreign_currency_id` in order to be displayed correctly alongside the amount in `account.bank.statement.line` To avoid a validation error(Currency is not activated) pop up for every foreign currency resides in transactions received from Odoofin while fetching transactions, Automatically activating foreign currencies. Remove foreign_currency_id and amount_currency from retrieved transactions in `Fetch Missing Transactions` flow in order to not break the flow in stable.(These fields will be added to `account.bank.statement.line.transient` in master) Odoofin PR: https://github.com/odoo/odoofin/pull/265 task id: 2870614
Resolved issues and error corrections
Fixed an issue where users with incorrect eBay credentials would encounter a technical error instead of a clear message. The system now properly handles authentication failures, providing a better user experience when credentials are invalid or misconfigured.
Original PR description
users were getting a traceback from the sdk when credentials were incorrect AttributeError: 'Response' object has no attribute '_dom' opw-3873151 Forward-Port-Of: odoo/enterprise#63735 Forward-Port-Of: odoo/enterprise#62049
This fix prevents users from resetting invoices back to draft status after they have been successfully sent and accepted by AFIP (Argentina's tax authority). Previously, this was possible and caused data inconsistencies between Odoo and AFIP's records. Now, once an invoice is sent and validated, it cannot be edited or reverted to draft, ensuring data integrity and compliance with tax regulations.
Original PR description
Before this commit, when sending an invoice to the AFIP and that the result was accepted, it was still possible to reset the invoice the draft which caused discrepancies between the data in Odoo and the data that has already been sent to AFIP. This button to reset to draft is enabled for all users in Accounting. After an invoice is sent and validated, we cannot edit them. task-3955111 Forward-Port-Of: odoo/enterprise#63407
This fix corrects how the "current year earnings" account is calculated in Chile's 8-column financial report. Previously, the report incorrectly included previous period balances, causing discrepancies between debit/credit and asset/liability columns. Now the report accurately shows only current period activity, ensuring financial statements are balanced and consistent.
Original PR description
Before this PR: The 8-column report for the "current year earnings" account type (equity_unaffected) incorrectly included the previous balance. This caused inconsistencies in reports, leading to imbalances between debit/credit and debtor/creditor columns, as well as assets/liabilities. Previously, this issue could be addressed by modifying the include_initial_balance boolean in the "account.user.type" model. However, this boolean is now computed and resides in the "account.account" model, making it uneditable. After this PR: This fix ensures the "current year earnings" account reflects only the activity for the current period, excluding the previous balance. This change eliminates the need to rely on the include_initial_balance state for this account, leading to a consistent and accurate 8-column report. Forward-Port-Of: odoo/enterprise#60713
This update fixes a critical issue in Romanian financial reports where outdated configuration settings were causing system errors during upgrades. The fix explicitly removes incompatible settings from balance sheet and profit/loss reports, ensuring they work correctly with the current reporting system.
Original PR description
Some of the records had their `groupby` set to `account_id` in previous versions That field was removed from the data file and new expressions were added. This means that the records which already…
Some of the records had their `groupby` set to `account_id` in previous versions That field was removed from the data file and new expressions were added. This means that the records which already have `groupby` set won't get that field updated during an upgrade, and will trigger [an error](https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_report.py#L571-L578). By explicitly removing the value from the field, we ensure the field will be emptied. The change in the data files comes from: https://github.com/odoo/enterprise/pull/52603 ``` odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/l10n_ro_reports/data/balance_sheet_short.xml:3 Groupby feature isn't supported by aggregation engine. Please remove the groupby value on 'SOLDE C | 43' ``` Note: The original change to the data file happened in saas~16.1. Given that it's not possible to upgrade to intermediate versions any more and there's no issue in standard, the PR targets 17.0. Forward-Port-Of: odoo/enterprise#62421
This fix resolves an issue where newly added employee skills were not appearing in the skills evaluation report. The problem occurred because the system wasn't properly handling new skill records that didn't have previous skill level data. The fix improves the report's data retrieval logic to ensure all skills, including newly created ones, are accurately displayed in employee appraisal reports.
Original PR description
…on report steps to reproduce: - add new appraisal of employee and confirm it. - add new skills and update existing ones. - check the skill evaluation report issue: A newly created skill doesn't appear in the report since the previous skill level may contain null while creating new records. fix: Apply a left join on the report so that it can provide accurate results. also, add a subquery based on the last completed appraisal, since the last `appraisal_id` is updated on the pending state too. task-3810220 Forward-Port-Of: odoo/enterprise#60088
This fix corrects how the system identifies which pivots are being used in a spreadsheet when they span multiple sheets. Previously, pivots used in non-active sheets were incorrectly marked as unused, which could lead to confusion about data dependencies. The fix ensures accurate tracking of pivot usage across all sheets in a spreadsheet.
Original PR description
Enterprise adaptations of the community branch. Steps to reproduce in 17.0: There's no way to reproduce the issue in 17.0 because the faulty getter in only called on positions in the active sheet (pivot autofill, global filter auto-matching) Steps to reproduce in saas-17.1: - insert a pivot in a blank spreadsheet - delete all pivot formulas - insert a new sheet - in the new sheet: - in A1: type "1" - in A2: =ODOO.PIVOT(A1) - activate the first sheet again - Open the Data menu => the pivot 1 is marked as being unused, even though it's used in the second sheet Task: 3859472
This fix resolves an issue where users couldn't open spreadsheets from shared workspace portals, which was causing access right errors. Now internal users can properly access and open spreadsheets when clicking on them from the sharing portal page, improving the collaborative document sharing experience.
Original PR description
Steps to reproduce: - share a workspace with more than one document and a spreadsheet - open the sharing link,(make sure you are login as internal user) - from the sharing portal page, click on the spreadsheet title to open the spreadsheet => access right error Task: 3897719 Forward-Port-Of: odoo/enterprise#63256
A CSS class name was updated in the spreadsheet module to match a recent library change. The button styling class was renamed from `o-sidePanelButton` to `o-button` to maintain consistency with the updated library. This ensures the version history panel buttons display correctly.
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo.
This fix corrects an issue where timesheet dates were being displayed in UTC time instead of the user's local time zone, causing dates to appear one day off. The fix removes an unnecessary UTC time override in the timesheet creation process, allowing the system to properly respect each user's time zone settings.
Original PR description
Versions -------- - 15.0e+ Steps ----- 1. If current UTC time is before 11:00, set user tz to Pacific/Niue; 2. if current UTC time is after 11:00, set user tz to Pacific/Kiritimati; 3. go to Helpdesk; 4. enable timesheets for a helpdesk team; 5. open a ticket of that helpdesk team; 6. start timer; 7. stop timer; 8. create timesheet. Issue ----- The date of the timesheet is set to the UTC date instead of the user date, which is one day off. Cause ----- The wizard creating timesheets adds a `Datetime.now()` value to `date`, which defaults to UTC time. Solution -------- Remove this line, allowing timesheets to be created with the default value, which does get adjusted for user timezone. opw-3834908 Forward-Port-Of: odoo/enterprise#63693 Forward-Port-Of: odoo/enterprise#63073
This fix resolves an issue where products with lot tracking could not be moved if they had inventory in customer locations. The system was incorrectly checking all inventory locations instead of only internal warehouse locations, causing errors during lot transfers. With this fix, users can now successfully move lots even when customer location inventory exists.
Original PR description
Description of the issue/feature this PR addresses: Products with lot tracking, have some quants in customer locations, function gets all quants not only internal locations Current behavior before PR: Raise exception when try to move location for stock.lot Desired behavior after PR is merged: Allow move stock.lot although it has quants in customer locations --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr