Daily updates from Odoo
Navigate
Branch
Monday, October 14, 2024
76 changes
25 changes
Resolved issues and error corrections
The mobile search panel no longer shows an extra red dot when a filter is selected. This removes a redundant visual cue, making the interface cleaner while keeping the selected filter clearly visible.
Original PR description
On mobile, whwen a domain is selected in the SearchPanel, there is a red dot that indicates there is a domain applied. This red dot is useless because we actually see that the domain is selected. This commit removes it. task-4246980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings the embedded spreadsheet engine to a newer maintenance version and fixes several issues affecting formatting, exporting, find-and-replace, and session handling. Users should see more reliable spreadsheet behavior, especially when copying table styles, exporting styled sheets, and searching formulas.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7e88becba [REL] 17.2.24 Task: 0 https://github.com/odoo/o-spreadsheet/commit/1b554f7e1 [FIX] session: ignore already…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7e88becba [REL] 17.2.24 Task: 0 https://github.com/odoo/o-spreadsheet/commit/1b554f7e1 [FIX] session: ignore already processed SNAPSHOT_CREATED Task: 4243943 https://github.com/odoo/o-spreadsheet/commit/f562b8eed [FIX] clipboard: cannot paste whole table style Task: 4218988 https://github.com/odoo/o-spreadsheet/commit/2289fc357 [FIX] export: Fix default style ignored at export Task: 4178743 https://github.com/odoo/o-spreadsheet/commit/b57230ff5 [FIX] table: update table style on header group removal Task: 4081345 https://github.com/odoo/o-spreadsheet/commit/d73ba2ab8 [FIX] Find&Replace: always search cell content if `searchFormula` Task: 4175968 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>
Product catalog prices are now hidden when the catalog is opened from manufacturing or repair orders. This keeps the catalog focused on selecting components, where price information is not relevant and could distract users.
Original PR description
This commit hides the unit price of products in the catalog, in case that the catalog was opened from a manufacturing or a repair order. This is because the catalog in this case is used to add a component so the price information is irrelevant. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves Odoo's internal Hoot test tool by making failed test results easier to understand and rerun. It helps developers diagnose issues faster, which supports more reliable quality checks before changes reach users.
Original PR description
## Pull Request HOOT (PRHOOT) - part 25 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 25 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 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728 Part 24: https://github.com/odoo/odoo/pull/181971 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
Miscellaneous changes
Steps to reproduce: - Accounting > Configuration > Taxes - Create a tax with 'Tax Computation' as Fixed - Invoice a product with only that fixed tax - Print the invoice The subtotals for fixed taxes are displayed showing 'on $__', this is inconsistent with the intent of 5f77e6588ee2a15d7bf2cb593a51f509d9e4ca9d where the change was made. We want this mention only on percentage based taxes which actually depend on the amount the tax is applied to. i.e. '15% on $100' for percentage and ju
Original PR description
Steps to reproduce: - Accounting > Configuration > Taxes - Create a tax with 'Tax Computation' as Fixed - Invoice a product with only that fixed tax - Print the invoice The subtotals for fixed taxes are displayed showing 'on $__', this is inconsistent with the intent of 5f77e6588ee2a15d7bf2cb593a51f509d9e4ca9d where the change was made. We want this mention only on percentage based taxes which actually depend on the amount the tax is applied to. i.e. '15% on $100' for percentage and just 'Fix $15' for fixed taxes. opw-4110516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180341
The active flag [can be included](https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/stock_warehouse.py#L259-L277) in the values to update when calling function `_create_or_update_sequences_and_picking_types`, for example [during upgrades](https://github.com/odoo/upgrade/blob/master/migrations/stock/saas~17.3.1.1/end-migrate.py#L16). This will raise the Validation Error even if the flag is being kept as active. upg-2034998 Forward-Port-Of: odoo/odoo#180292
Original PR description
The active flag [can be included](https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/stock_warehouse.py#L259-L277) in the values to update when calling function `_create_or_update_sequences_and_picking_types`, for example [during upgrades](https://github.com/odoo/upgrade/blob/master/migrations/stock/saas~17.3.1.1/end-migrate.py#L16). This will raise the Validation Error even if the flag is being kept as active. upg-2034998 Forward-Port-Of: odoo/odoo#180292
### Description of the issue/feature this PR addresses: In the chatter if you try to insert signature with: /Signature , an error appear if auth_totp is not installed: > Error: Invalid ids list: > Error: Invalid ids list: > at validatePrimitiveList (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:28515:15) (/web/static/src/core/orm_service.js:73) > at ORM.read (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:28596:9) (/web/s
Original PR description
### Description of the issue/feature this PR addresses: In the chatter if you try to insert signature with: /Signature , an error appear if auth_totp is not installed: > Error: Invalid ids list: >…
### Description of the issue/feature this PR addresses: In the chatter if you try to insert signature with: /Signature , an error appear if auth_totp is not installed: > Error: Invalid ids list: > Error: Invalid ids list: > at validatePrimitiveList (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:28515:15) (/web/static/src/core/orm_service.js:73) > at ORM.read (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:28596:9) (/web/static/src/core/orm_service.js:154) > at ORM.read (https://www.stesi.consulting/web/assets/debug/web.assets_web_dark.js:39288:41) (/web/static/src/core/utils/hooks.js:101) > at Object.callback (https://www.stesi.consulting/web/assets/debug/web_editor.backend_assets_wysiwyg.js:25785:51) (/web_editor/static/src/js/wysiwyg/wysiwyg.js:2463) > at Powerbox._pickCommand (https://www.stesi.consulting/web/assets/debug/web_editor.backend_assets_wysiwyg.js:14811:27) (/web_editor/static/src/js/editor/odoo-editor/src/powerbox/Powerbox.js:232) ### Current behavior before PR: The error above appears because the web_editor get the session_user_id from session_info that is set by auth_totp or in a frontend session. Using uid it works on both ### Desired behavior after PR is merged: No error should appear --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179378
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#182667
Original PR description
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#182667
Upon attempting to refund an Authorize.net transaction, its state on the provider side is fetched to decide on the refund strategy. If the payment is not yet settled, the refund is achieved by sending a void request rather than a refund request. This flow was not fully working because the payment engine refused to move the transaction state from `done` to `cancel`. This forced users to hit the "Refund" button once to send the void request and a second time to cancel the transaction, as the se
Original PR description
Upon attempting to refund an Authorize.net transaction, its state on the provider side is fetched to decide on the refund strategy. If the payment is not yet settled, the refund is achieved by sending a void request rather than a refund request. This flow was not fully working because the payment engine refused to move the transaction state from `done` to `cancel`. This forced users to hit the "Refund" button once to send the void request and a second time to cancel the transaction, as the second attempt was working thanks to the change of transaction state on the provider side. This commit allows Authorize.net transactions to move from the `done` state to the `cancel` state. It is not necessary to ensure we are in the context of a refund because we always check that a transaction is in the `authorized` state before attempting to void it. opw-4201355 Forward-Port-Of: odoo/odoo#183184
The DisplayDriver class uses the `xdotool` command to send keypresses to the browser. However for Chromium, it is using the wrong process name causing the keystrokes not to be received. The symptom of this is the Pairing Code does not disappear after 5 minutes as intended, leaving an invalid code on the screen. This PR fixes the issue by using the correct process name for Chromium. Related PR for 18.0+: https://github.com/odoo/odoo/pull/180286 --- I confirm I have signed the CL
Original PR description
The DisplayDriver class uses the `xdotool` command to send keypresses to the browser. However for Chromium, it is using the wrong process name causing the keystrokes not to be received. The symptom of this is the Pairing Code does not disappear after 5 minutes as intended, leaving an invalid code on the screen. This PR fixes the issue by using the correct process name for Chromium. Related PR for 18.0+: https://github.com/odoo/odoo/pull/180286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182745
The demo mode option in the Peppol connection wizard is primarily used by internal teams (BA, support, sales) for demonstrations or testing. It is more appropriate to manage this mode through a system parameter instead of exposing it to all users in the wizard interface. This commit mirrors the change from (commit 6d222885f41f5136c690dcd56953f1a9775204ae pr odoo/odoo#182893), but without removing the related fields, making it suitable for stable versions. task-4215904 Forward-Port-Of: od
Original PR description
The demo mode option in the Peppol connection wizard is primarily used by internal teams (BA, support, sales) for demonstrations or testing. It is more appropriate to manage this mode through a system parameter instead of exposing it to all users in the wizard interface. This commit mirrors the change from (commit 6d222885f41f5136c690dcd56953f1a9775204ae pr odoo/odoo#182893), but without removing the related fields, making it suitable for stable versions. task-4215904 Forward-Port-Of: odoo/odoo#183180
Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear. Steps to reproduce: ------------------- * Use an Ipad (or simulate one) * Go to the **Point of sale** App * Select **Configuration** > **Settings** * Enable QR code on receipt * Open shop session * Make an order and pay it * Print the receipt > Observation: QR code does not appear, big white space where it sh
Original PR description
Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear. Steps to reproduce:…
Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear.
Steps to reproduce:
-------------------
* Use an Ipad (or simulate one)
* Go to the **Point of sale** App
* Select **Configuration** > **Settings**
* Enable QR code on receipt
* Open shop session
* Make an order and pay it
* Print the receipt
> Observation: QR code does not appear, big white space where it should be
* Print it again
> Observation: QR code is printed
Why the fix:
------------
```js
function createImage(url) {
return new Promise((resolve, reject) => {
const img = new Image();
img.onload = () => resolve(img);
img.decode = () => resolve(img);
img.onerror = reject;
img.crossOrigin = "anonymous";
img.decoding = "async";
img.src = url;
});
}
```
In this piece of code, `img.decode = () => resolve(img);` is supposed to ensure that the image is fully processed but is misused. Decode is not a setter, it's a method that returns a promise when the image is fully decoded. While this code wait for the image to load it does not wait for it to be fully ready (processed).
`img.decode()` ensures that the image has been fully decoded before continuing.
We go one step further with `requestAnimationFrame`. This defers the execution and will ensure that the resolved image is rendered in the next frame. It's more important in devices like Ipad because the broswers tend to handle image operations differently, thus creating rendering and timing issues.
With this fix, we now wait longer to make sure that the image is not only loaded but also fully processed and ready to be shown.
opw-4144049
Forward-Port-Of: odoo/odoo#182803Steps to reproduce ====================== Go to the user profile. Click on tags. You will be redirected to the courses instead of redirecting to the tags. Technical ========== Click event is there on the whole card as our tags are inside the card so the click event of a parent is triggering instead of the child. and we are redirected to the course page. After this PR =========== We will be redirected to tags when clicking on tag. Task-4203676 Forward-Port-Of: odoo/odoo#183079 F
Original PR description
Steps to reproduce ====================== Go to the user profile. Click on tags. You will be redirected to the courses instead of redirecting to the tags. Technical ========== Click event is there on the whole card as our tags are inside the card so the click event of a parent is triggering instead of the child. and we are redirected to the course page. After this PR =========== We will be redirected to tags when clicking on tag. Task-4203676 Forward-Port-Of: odoo/odoo#183079 Forward-Port-Of: odoo/odoo#181499
## Description After importing a large quantity of pending bills with no `invoice_date`, the dashboard can be significantly slow. The bottleneck comes primarily from the hot loop in `_count_results_and_sum_amounts`, as it's iterating over a potentially enormous list of dictionary of query results. This patch improvement consists mostly of hoisting invariants out of this hot loop, most impactful is the call to `context_today`, which does a lot of computation/conversions to apply the proper tim
Original PR description
## Description After importing a large quantity of pending bills with no `invoice_date`, the dashboard can be significantly slow. The bottleneck comes primarily from the hot loop in…
## Description After importing a large quantity of pending bills with no `invoice_date`, the dashboard can be significantly slow. The bottleneck comes primarily from the hot loop in `_count_results_and_sum_amounts`, as it's iterating over a potentially enormous list of dictionary of query results. This patch improvement consists mostly of hoisting invariants out of this hot loop, most impactful is the call to `context_today`, which does a lot of computation/conversions to apply the proper timezone and localize the date. ## Benchmark | len(results_dict) | Before | After | Speedup | |-------------------|--------|-------|---------| | Timings (10k) | 250ms | 50ms | 5x | | Timings (50k) | 1.2s | 300ms | 4x | | Timings (100k) | 2.7s | 820ms | 3.3x | | Timings (250k) | 6.7s | 1.7s | 3.9x | | Timings (~600k) | 13s | 4s | 3.25x | ## Reference opw-4235252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183342
Task: 4228916 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#182595
Original PR description
Task: 4228916 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#182595
To reproduce the issue: (Need website_sale) 1. Set up a website shop for ES company - With demo payment method 2. In Settings: - Website > Automatic Invoice: enabled 3. With a portal user, add a product to the cart 4. Open the cart 5. Pay with Demo Error: The client is redirected to a page "Internal server error: The partner needs a set tax identification number or VAT number" When post-processing the payment, and because of step 2, it leads to https://github.com/odoo/odoo/
Original PR description
To reproduce the issue: (Need website_sale) 1. Set up a website shop for ES company - With demo payment method 2. In Settings: - Website > Automatic Invoice: enabled 3. With a portal user, add a…
To reproduce the issue: (Need website_sale) 1. Set up a website shop for ES company - With demo payment method 2. In Settings: - Website > Automatic Invoice: enabled 3. With a portal user, add a product to the cart 4. Open the cart 5. Pay with Demo Error: The client is redirected to a page "Internal server error: The partner needs a set tax identification number or VAT number" When post-processing the payment, and because of step 2, it leads to https://github.com/odoo/odoo/blob/20365bcab548c4a2d93194c8c2b8b2577d14d3ce/addons/l10n_es_edi_facturae/wizard/account_move_send.py#L86-L88 Where we will generate the data for the Facturae XML. There, we check few things, like the vat number of the partner: https://github.com/odoo/odoo/blob/e157cb2d8640fac1365beb135763cb25cff554f5/addons/l10n_es_edi_facturae/models/account_move.py#L312-L313 And since the portal user does not have any vat number, the error is raised. The Facturae feature should only be enabled for B2B flows OPW-4121724 Forward-Port-Of: odoo/odoo#181653
Since [1], the ".o_default_text_snippet" class has not been correctly removed when text is modified within a content-editable element. This commit resolves the issue. Steps to reproduce: - Drag and drop the "Pricelist block" into the page. - Click on the snippet newly inserted to display the options on the right panel. - Enable the "Descriptions" option under the Pricelist block options to display descriptions. - Edit some descriptions directly in the snippet. - Disable and re-
Original PR description
Since [1], the ".o_default_text_snippet" class has not been correctly removed when text is modified within a content-editable element. This commit resolves the issue. Steps to reproduce: - Drag and drop the "Pricelist block" into the page. - Click on the snippet newly inserted to display the options on the right panel. - Enable the "Descriptions" option under the Pricelist block options to display descriptions. - Edit some descriptions directly in the snippet. - Disable and re-enable the "Descriptions" option. - Bug: The edited descriptions are replaced by the default text. [1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af#diff-52a4f9d2c217548e69e6b7fd097f286f1754a6389734eea254b87255e501cbef task-4084956 task-4147162 (first part) Forward-Port-Of: odoo/odoo#177588
Steps to reproduce the error 1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll 2.create a leave with existing leave type from l10n_be_hr_payroll module 3.upgrade db to 16.0 the below mentioned traceback will raise traceback ```py Traceback (most recent call last): File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 698, in _tag_root f(rec) File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 599, in _tag_record record = model._load_recor
Original PR description
Steps to reproduce the error 1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll 2.create a leave with existing leave type from l10n_be_hr_payroll module 3.upgrade db to 16.0 the…
Steps to reproduce the error
1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll
2.create a leave with existing leave type from l10n_be_hr_payroll module
3.upgrade db to 16.0 the below mentioned traceback will raise
traceback
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 698, in _tag_root
f(rec)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 599, in _tag_record
record = model._load_records([data], self.mode == 'update')
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4393, in _load_records
data['record']._load_records_write(data['values'])
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4324, in _load_records_write
self.write(values)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3806, in write
real_recs._validate_fields(vals, inverse_fields)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 1365, in _validate_fields
check(self)
File "/home/odoo/src/odoo/16.0/addons/hr_holidays/models/hr_leave_type.py", line 188, in check_allocation_requirement_edit_validity
raise UserError(_("The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead."))
odoo.exceptions.UserError: The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1310, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/16.0/odoo/modules/registry.py", line 91, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 484, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 372, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 231, in load_module_graph
load_data(cr, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(cr, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 763, in convert_file
convert_xml_import(cr, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 829, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 749, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 711, in _tag_root
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/16.0/l10n_be_hr_payroll/data/hr_leave_type_data.xml:14, somewhere inside
<record id="holiday_type_maternity" model="hr.leave.type">
<field name="name">Maternity Time Off</field>
<field name="requires_allocation">no</field>
<field name="leave_validation_type">no_validation</field>
<field name="request_unit">half_day</field>
<field name="color_name">lavender</field>
<field name="leave_notif_subtype_id" ref="hr_holidays.mt_leave"/>
<field name="work_entry_type_id" ref="work_entry_type_maternity"/>
<field name="icon_id" ref="hr_holidays.icon_11"/>
<field name="company_id" eval="False"/>
</record>
```
why this traceback is raised because while loading ``l10n_be_hr_payroll`` moduel this data file will load during that if record is noupdate false then it will go for write call so in that requires_allocation will also go for write call even the value is same. So, the newly introduced [``constraints``](https://github.com/odoo/odoo/commit/33da34b842f2fe700efaf55915d4cb9828e139d7) will trigger and check if any record
of leave is present with the that leavetype constraint will trigger .For fixing this issue pop the value of ``requires_allocation`` if the values are same otherwise record is modified by user.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182533Description this PR addresses: Fixes #181899: Prevents data loss when migrating attachments from DB to filestore by adding a writable permission check before migration. Current behavior before PR: Migration to filestore proceeds even if the target directory is not writable, resulting in data loss. Desired behavior after PR is merged: Writable permissions are checked before migration. If the target directory is not writable, an exception will be raised --- I confirm I have signed
Original PR description
Description this PR addresses: Fixes #181899: Prevents data loss when migrating attachments from DB to filestore by adding a writable permission check before migration. Current behavior before PR: Migration to filestore proceeds even if the target directory is not writable, resulting in data loss. Desired behavior after PR is merged: Writable permissions are checked before migration. If the target directory is not writable, an exception will be raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181998
In the Calendar app with the Arabic language, there is no AM/PM distinction or 24-hour clock option. Users can only select a time between 1 and 12 without the ability to specify AM or PM. This issue is caused by the missing %p placeholder in the Arabic record of the res.lang.csv file. OPW-4182242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180858
Original PR description
In the Calendar app with the Arabic language, there is no AM/PM distinction or 24-hour clock option. Users can only select a time between 1 and 12 without the ability to specify AM or PM. This issue is caused by the missing %p placeholder in the Arabic record of the res.lang.csv file. OPW-4182242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180858
Description of the issue/feature this PR addresses: sys.settrace prevents coverage.py from working properly: https://coverage.readthedocs.io/en/7.5.3/trouble.html The main cause of the problem is that when executing the SyncCollector profiler we will settrace(None). This makes the coverage result invalid since the settrace added by the coverage is not resumed. Also, it would be possible to have a similar problem with nested SyncCollector, or if any other tool/code uses sys.settrace.
Original PR description
Description of the issue/feature this PR addresses: sys.settrace prevents coverage.py from working properly: https://coverage.readthedocs.io/en/7.5.3/trouble.html The main cause of the problem is that when executing the SyncCollector profiler we will settrace(None). This makes the coverage result invalid since the settrace added by the coverage is not resumed. Also, it would be possible to have a similar problem with nested SyncCollector, or if any other tool/code uses sys.settrace. So, an error is logged when the profiler starts. Current behavior before PR: The coverage.py report doesn't correctly track which tests have been run. Desired behavior after PR is merged: coverage.py will report all the correct tests. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167379
## Description of the issue/feature this PR addresses: Prior to this commit, the health route is responding with a 200 status even when the database server is down or unreachable. In deployment scenario (CI/CD), this route (/web/health) is (can be) used in order to get the deployement state. This is actually the only one that can be used in order to check it without an active session or credentials or master password. Including the optional db_server_status arg will allow integrating th
Original PR description
## Description of the issue/feature this PR addresses: Prior to this commit, the health route is responding with a 200 status even when the database server is down or unreachable. In deployment…
## Description of the issue/feature this PR addresses: Prior to this commit, the health route is responding with a 200 status even when the database server is down or unreachable. In deployment scenario (CI/CD), this route (/web/health) is (can be) used in order to get the deployement state. This is actually the only one that can be used in order to check it without an active session or credentials or master password. Including the optional db_server_status arg will allow integrating the postgresql server state without breaking any eventual existing overrides. ## Current behavior before PR: When the postgresql database is not up / not reachable the route is returning a 200 code. ## Desired behavior after PR is merged: When the postgresql database is not up / not reachable the route is returning a 500 code. As we are in stable, an optional argument has been added to the route in order not to break any potential existing overrides. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182840 Forward-Port-Of: odoo/odoo#182537
Task: 41734 Odoo-task: 1239 Description of the issue/feature this PR addresses: This task was created to modify the demo data for Argentina, to avoid using real partner information except for their VAT number. Current behavior before PR: Desired behavior after PR is merged: Edit the demo data with fake information except for the VAT number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182663 Forward-Port-Of:
Original PR description
Task: 41734 Odoo-task: 1239 Description of the issue/feature this PR addresses: This task was created to modify the demo data for Argentina, to avoid using real partner information except for their VAT number. Current behavior before PR: Desired behavior after PR is merged: Edit the demo data with fake information except for the VAT number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182663 Forward-Port-Of: odoo/odoo#175390
When the session of the kiosk is closed in the backoffice, the kiosk is supposed to show the "We are closed" banner and to no longer accept orders. Currently, this is not the case. In this commit we fix the issue Task: 4219525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182081
Original PR description
When the session of the kiosk is closed in the backoffice, the kiosk is supposed to show the "We are closed" banner and to no longer accept orders. Currently, this is not the case. In this commit we fix the issue Task: 4219525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182081
when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case 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#182859
Original PR description
when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case 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#182859
18 changes
Enhancements to existing features
Timesheet views now handle multiple display widgets on the same field without one replacing another. This improves reliability of timesheet grid screens and preserves the intended user interface behavior.
Original PR description
Previously, when two widgets were applied separately to a single field within
the view, the second widget would replace the first. This issue was resolved in
17.0. Now, each field is assigned an index to avoid replacement issues.
Technical Details:
Example in 16.0:
`<field name="xx_name" widget="x"/>`
`<field name="xx_name" widget="x1"/>`
Example in 17.0:
`<field name="xx_name_0" widget="x"/>`
`<field name="xx_name_1" widget="x1"/>`
This limitation is resolved in this PR: https://github.com/odoo/odoo/pull/117799
task-4072722The Colombian electronic invoicing area now shows a properly designed form when users open type code records. This replaces the automatically generated layout with a cleaner, easier-to-use screen.
Original PR description
before this commit, there is no form view defined for the model l10n_co_edi.type_code and thus on accessing the form view, it shows odoo generated form view. after this commit, on accessing the form from the menu, it will show clean form view.
The Frontdesk visitor status bar now shows the canceled state only after a visitor record has actually been canceled. This keeps the workflow display cleaner and reduces confusion for staff reviewing visitor status.
Original PR description
before this commit, the cancelled state is shown in the statusbar always after this commit, the cancelled state will be shown in the statusbar once the record is in cancelled state
Resolved issues and error corrections
Recruitment users can now refuse an application without encountering an error. The fix removes an outdated field reference left after an earlier model change, improving reliability in the referral recruitment flow.
Original PR description
Steps: - Install hr_referral, hr_contract_salary - click on refuse button in application form Description of the issue/feature this PR addresses: In the recruitment module, clicking the refuse button on an application results in a traceback error. Cause The issue arises due to the name field, which was removed from the hr_applicant model (as per https://github.com/odoo/odoo/pull/173288). The system still attempts to retrieve this field, causing the error. Fix: This PR resolves the issue by removing the unnecessary name field from the applicant model task-4195716
Features or functions removed from Odoo
Odoo Studio no longer supports editing older kanban view definitions that use the legacy kanban-box format. This simplifies Studio around the newer kanban structure, but customers with custom legacy kanban views will need to convert them manually using the current documentation.
Original PR description
A new API for cleaner/simpler kanban archs has been introduced last year [1]. All standard kanban views in Odoo have been converted in v18 [2]. We kept the support of legacy kanban in v18, but it's now time to drop it. It means that custom legacy kanban archs will need to be manually converted into the new API (see documentation [3]). [1] Task `3650117` [2] Task `3992107` [3] https://www.odoo.com/documentation/master/developer/reference/user_interface/view_architectures.html#kanban Task `4199332`
Miscellaneous changes
This commit removes unnecessary base64 encoding and decoding operations when computing `spreadsheet_data` which contains the serialised json data. Previously, the binary field `spreadsheet_binary_data` was base64-encoded (as is the case with all binary fields), meaning the file was read, encoded to base64, and assigned to `spreadsheet_binary_data`. To retrieve the serialized JSON, it then had to be decoded again. By avoiding this redundant steps, we optimize the time spent in `_compute_spr
Original PR description
This commit removes unnecessary base64 encoding and decoding operations when computing `spreadsheet_data` which contains the serialised json data. Previously, the binary field `spreadsheet_binary_data` was base64-encoded (as is the case with all binary fields), meaning the file was read, encoded to base64, and assigned to `spreadsheet_binary_data`. To retrieve the serialized JSON, it then had to be decoded again. By avoiding this redundant steps, we optimize the time spent in `_compute_spreadsheet_data`: before: ~100ms after: ~30ms Task: 4256155 Forward-Port-Of: odoo/enterprise#71879
Since the fix in HOOT was merged the test can actually be run. https://github.com/odoo/odoo/pull/183099 Forward-Port-Of: odoo/enterprise#71862
Original PR description
Since the fix in HOOT was merged the test can actually be run. https://github.com/odoo/odoo/pull/183099 Forward-Port-Of: odoo/enterprise#71862
Currently, a traceback is occurring when the user tries to open a Vietnamese tax returns report. To reproduce this issue: 1) Install l10n_vn_reports and switch to VN company 2) Create an invoice with a product and tax 3) Now open the Tax Returns and change the report as `Sales/Purchase Tax Report (VN)` and tax period in years Error:- ``` ProgrammingError: can't adapt type 'dict' ``` This error is occurring because in `column_group_options` we get the values as dict. For
Original PR description
Currently, a traceback is occurring when the user tries to open a Vietnamese tax returns report. To reproduce this issue: 1) Install l10n_vn_reports and switch to VN company 2) Create an invoice with a product and tax 3) Now open the Tax Returns and change the report as `Sales/Purchase Tax Report (VN)` and tax period in years Error:- ``` ProgrammingError: can't adapt type 'dict' ``` This error is occurring because in `column_group_options` we get the values as dict. For the method `_currency_table_apply_rate` we expect the value to be in the string. To handle the dict for returning the join conditions we use `_currency_table_aml_join`. sentry-5962808992 Forward-Port-Of: odoo/enterprise#71387
Commit 1 ======== Steps to reproduce the issue: - add comment to a Facebook/youtube post. - keeping the `Comments` dialog box open, try replying the same comment. - we get a traceback. Reason: - due to the missing comments data structure, we get an error when trying to add the new comment. - LOC responsible for the traceback: https://github.com/odoo/enterprise/blob/16.0/social/static/src/xml/social_templates.xml#L311 Fix: - since the comments data structure is not returned from t
Original PR description
Commit 1 ======== Steps to reproduce the issue: - add comment to a Facebook/youtube post. - keeping the `Comments` dialog box open, try replying the same comment. - we get a traceback. Reason: - due…
Commit 1 ======== Steps to reproduce the issue: - add comment to a Facebook/youtube post. - keeping the `Comments` dialog box open, try replying the same comment. - we get a traceback. Reason: - due to the missing comments data structure, we get an error when trying to add the new comment. - LOC responsible for the traceback: https://github.com/odoo/enterprise/blob/16.0/social/static/src/xml/social_templates.xml#L311 Fix: - since the comments data structure is not returned from the post request made to post the commnet, we manually ensure it exists. Commit 2 ======== [FIX] social: fix various issues 1. social_instagram: ISSUES: - create a post on the instagram platform with commenting turned off. - try commenting on it from Odoo. We get a traceback. - also, if we delete the post from the platform and then try to comment from Odoo, we get a traceback. REASON: - there is no existing implementation to check if commenting is enabled/disabled on the post. FIX: - we now check if commenting is enabled or not while trying to add comment on the post TECHNICAL NOTE: - the correct way to check if commenting on a post is enabled or not is to request a field named `is_comment_enabled`. - more details --- https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-media - but to save us from making an extra request, we simply catch the error received to when trying to add a comment. ================================================================================ 2. social_linkedin ISSUE: - delete an existing post from the linkedIn platform. - now try commenting on it from Odoo. We get a traceback. REASON: - The response received from the request to fetch the comments is not validated. FIX: - validating the response before further execution. Task-3759530 Forward-Port-Of: odoo/enterprise#71750 Forward-Port-Of: odoo/enterprise#67079
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a grouped Payment in MXN for those invoices 5. Go to one of the Invoices and click on Update Payments 6. Go to the CFDI tab and, on the Payment line, click on Force CFDI 7. On the Payment line, you should now be able to Download an XML document 8. In the document, the EquivalenciaDR attributes
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a…
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a grouped Payment in MXN for those invoices 5. Go to one of the Invoices and click on Update Payments 6. Go to the CFDI tab and, on the Payment line, click on Force CFDI 7. On the Payment line, you should now be able to Download an XML document 8. In the document, the EquivalenciaDR attributes should have the same values, which is not the case ### Explanation: When calculating the rate (which then is used in EquivalenciaDR) in `_l10n_mx_edi_add_payment_cfdi_values`, we are using amounts that have been rounded out, leading to rates that differ when aiming for certain decimal precisions. ### Fix reasoning: While `_get_conversion_rate` can be used to avoid the inconsistencies of the rounded amounts, it should not be used if the values do not match once they are converted, since the rate would then be wrong. opw-4090269 Forward-Port-Of: odoo/enterprise#71767 Forward-Port-Of: odoo/enterprise#70083
When automatic entries are generated, a sequence number should not be assigned on them as long as they are on draft state. This is done because it may be confusing to see a sequence name for a move in draft. This commit ensures that the name of the entries is 'Draft' (or '/') when the move is generated. A sequence number will be assigned once the move is posted. Before this commit, it was possible to generate a draft move with a sequence number when doing a deferred entries with some entries in
Original PR description
When automatic entries are generated, a sequence number should not be assigned on them as long as they are on draft state. This is done because it may be confusing to see a sequence name for a move in draft. This commit ensures that the name of the entries is 'Draft' (or '/') when the move is generated. A sequence number will be assigned once the move is posted. Before this commit, it was possible to generate a draft move with a sequence number when doing a deferred entries with some entries in the future. task-4069862 Forward-Port-Of: odoo/enterprise#71409 Forward-Port-Of: odoo/enterprise#70855
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create an associated repair order and add a line for an other product in the part tabs - Go back to the return picking #### > the product added to the repair was also added to the retur
Original PR description
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer…
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create an associated repair order and add a line for an other product in the part tabs - Go back to the return picking #### > the product added to the repair was also added to the return picking ### Cause of the issue: A `default_picking_id` is added to the context of the form view of the repair order by the `_prepare_repairs_default_value` of the `action_repair_order_form` so that it prefils the form of the repair: https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L36-L40 https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L55-L56 However, this values stays in the context and will be added as a default value for each of the move that will be creted from this view. ### Fix: Thanks to commit odoo/odoo@3898d61046cc0338082fdcbe0df282241372361a, we now have a default getter that can be used to associate a default picking id to the repair order when necessary without the need to put a `default_picking_id` in the context. opw-4159779 Forward-Port-Of: odoo/enterprise#71704 Forward-Port-Of: odoo/enterprise#71337
Issue ---- When clicking an account report cell with the cash basis filter on, `account_reports_cash_basis.account_report.action_audit_cell` adds a domain to filter out `account.move.line`s that don't belong to the cash basis criteria. However, the model is not always an `account.move.line`. If an analytic account column is added with the "Analytic Group By" option, the model is `account.analytic.line`, which results in a field not found error. Steps ---- - Go to Accounting -> Report
Original PR description
Issue ---- When clicking an account report cell with the cash basis filter on, `account_reports_cash_basis.account_report.action_audit_cell` adds a domain to filter out `account.move.line`s that don't belong to the cash basis criteria. However, the model is not always an `account.move.line`. If an analytic account column is added with the "Analytic Group By" option, the model is `account.analytic.line`, which results in a field not found error. Steps ---- - Go to Accounting -> Reporting -> Profit and Loss. - From the Options button above, select "Cash Basis Method". - From the Analytic Group By button, add an analytic account in the "Accounts" filter. - Click on a cell under the analytic account's column. - An error is thrown. Cause ---- Domain is applied on the wrong model. opw-4034786 Forward-Port-Of: odoo/enterprise#68094 Forward-Port-Of: odoo/enterprise#66890
**Steps to reproduce:** - Install Accounting and l10n_cl_edi_boletas - Switch to a Chilean company (e.g. CL Company) - Create a branch company for it - Create a product with a tax from "ILA" group - Switch to the branch company - Create an invoice with the created product - Confirm it **Issue:** A traceback is raised while trying to fetch some tax groups: - self.env.ref(f'account.{cid}_tax_group_ila') - self.env.ref(f'account.{cid}_tax_group_retenciones') where {cid} is the id of th
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_cl_edi_boletas - Switch to a Chilean company (e.g. CL Company) - Create a branch company for it - Create a product with a tax from "ILA" group -…
**Steps to reproduce:**
- Install Accounting and l10n_cl_edi_boletas
- Switch to a Chilean company (e.g. CL Company)
- Create a branch company for it
- Create a product with a tax from "ILA" group
- Switch to the branch company
- Create an invoice with the created product
- Confirm it
**Issue:**
A traceback is raised while trying to fetch some tax groups:
- self.env.ref(f'account.{cid}_tax_group_ila')
- self.env.ref(f'account.{cid}_tax_group_retenciones') where {cid} is the id of the branch company.
**Cause:**
There is no tax group defined in the branch company. The taxes and the tax groups are defined in the parent company.
**Solution:**
Do not raise an error if the XMLID cannot be found and also check tax groups from parent companies as the taxes could come from them.
Use the "ref" method defined in "account.chart.template" model that is doing it.
opw-4227241
Related comminity PR: https://github.com/odoo/odoo/pull/182798
Forward-Port-Of: odoo/enterprise#71708
Forward-Port-Of: odoo/enterprise#71476To reproduce: ============= - log as admin and create a template on sign - give a user with **User : Own templates** authorization to the template - log as the user and try to use layout (from 3 dots in kanban view) -> access error Problem: ======== when duplicating the template we copy the original template, as the user does not have enough rights it leads to an access error Solution: ========= perform the copy as `sudo`, as the template won't be visible for the user if he is not
Original PR description
To reproduce: ============= - log as admin and create a template on sign - give a user with **User : Own templates** authorization to the template - log as the user and try to use layout (from 3 dots in kanban view) -> access error Problem: ======== when duplicating the template we copy the original template, as the user does not have enough rights it leads to an access error Solution: ========= perform the copy as `sudo`, as the template won't be visible for the user if he is not authorized to see it. opw-4166973 Forward-Port-Of: odoo/enterprise#71831 Forward-Port-Of: odoo/enterprise#70496
The manual fw-port of - https://github.com/odoo/enterprise/pull/71315 This PR https://github.com/odoo/enterprise/commit/ed431cd78dea4ad40e0e6a82eb3ffd9f44026d71 adds 'move_type = entry' on the '3.1 a,b,c,e' report lines, but only misc entries coming from the POS should impact the line. PoS entries are also considered in section 4, but they shouldn't. To determine which moves are from the PoS we use the l10n_in_pos_session_ids field from module l10n_in_reports_gstr_pos, so we had to inhe
Original PR description
The manual fw-port of - https://github.com/odoo/enterprise/pull/71315 This PR https://github.com/odoo/enterprise/commit/ed431cd78dea4ad40e0e6a82eb3ffd9f44026d71 adds 'move_type = entry' on the '3.1 a,b,c,e' report lines, but only misc entries coming from the POS should impact the line. PoS entries are also considered in section 4, but they shouldn't. To determine which moves are from the PoS we use the l10n_in_pos_session_ids field from module l10n_in_reports_gstr_pos, so we had to inherit the report in that module to add the condition. [Task link](https://www.odoo.com/odoo/project/69/tasks/4224066) **task**-4224066 Forward-Port-Of: odoo/enterprise#71646 Forward-Port-Of: odoo/enterprise#71533
**Steps to reproduce:** - Install Accounting and l10n_de_reports - Switch to a German company - Create a 19% included tax - Create an invoice with the following line: * Product: [any] * Quantity: 1.00 * Price: 19.95 * Taxes: [the 19% included tax] - Confirm the invoice - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv" **Issue:** The line for the created invoice has an amount of 19.94 inst
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_de_reports - Switch to a German company - Create a 19% included tax - Create an invoice with the following line: * Product: [any] * Quantity:…
**Steps to reproduce:** - Install Accounting and l10n_de_reports - Switch to a German company - Create a 19% included tax - Create an invoice with the following line: * Product: [any] * Quantity: 1.00 * Price: 19.95 * Taxes: [the 19% included tax] - Confirm the invoice - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv" **Issue:** The line for the created invoice has an amount of 19.94 instead of 19.95. **Cause:** As the tax is included, the balance on the line is computed and rounded. When the report is generated, "compute_all" is executed with the rounded balance to retrieve the total price with the taxes. Because the balance used in "compute_all" has been rounded and therefore is not exactly the same than the original computed value, there can be a 0.01 difference. **Solution:** Use directly "price_total" field when available. opw-4191876 Forward-Port-Of: odoo/enterprise#71787 Forward-Port-Of: odoo/enterprise#70801
**Current behavior:** Using 2 step delivery and modifying the route so the pick action's src location is a child of lot_stock will result in the move not being found by the Procurement mechanism, which can lead to inaccurate quantity being encoded on transfers created from rental orders. **Expected behavior:** Transfer quantity should match sale order line quantity. **Steps to reproduce:** 1. Enable 2-step delivery in the warehouse 2. In the 2-step delivery route, change the src loca
Original PR description
**Current behavior:** Using 2 step delivery and modifying the route so the pick action's src location is a child of lot_stock will result in the move not being found by the Procurement mechanism,…
**Current behavior:** Using 2 step delivery and modifying the route so the pick action's src location is a child of lot_stock will result in the move not being found by the Procurement mechanism, which can lead to inaccurate quantity being encoded on transfers created from rental orders. **Expected behavior:** Transfer quantity should match sale order line quantity. **Steps to reproduce:** 1. Enable 2-step delivery in the warehouse 2. In the 2-step delivery route, change the src location of the pick action (pull rule) to be a sub-location of WH/STOCK 3. Enable rental transfers in settings 4. Create a new rental order, add a product, confirm the order 5. Add some quantity to the order line and save 6. Look at the generated out-going picking's moves -> the demand is wrong **Cause of the issue:** The original move created when confirming the order, before editing the order line quantity, is not found when the additional move is created for the modified quantity. Existing outgoing moves are expected to have a location_id (source location) of WH/STOCK (warehouse.lot_stock_id), ours will have a location_id of some sub-location. **Fix:** Check all child locations of lot_stock (which includes lot_stock itself) when aggregating outgoing moves. opw-4178446 Forward-Port-Of: odoo/enterprise#71559
23 changes
Enhancements to existing features
Customer statement emails now have a reliable way to identify the responsible person who should sign them, even when the follow-up app is not installed. This prevents missing or incorrect sender details in customer communications and keeps statement emails consistent.
Original PR description
Partner Ledgers can be sent to Partners by email which is usually signed by the `followup_responsible` user, however, `_get_followup_responsible` is defined in `account_followup` which may not be installed. To solve this dependency issue, we define the method in `account_reports`, and the method in `account_followup` now extends it. No task - issue identified by marketing team upon review of the email template.
Spreadsheet documents now avoid an unnecessary data conversion step when reading stored spreadsheet content. This reduces processing time for large spreadsheet files, making spreadsheet access noticeably faster without changing user workflows.
Original PR description
This commit removes unnecessary base64 encoding and decoding operations when computing `spreadsheet_data` which contains the serialised json data. Previously, the binary field `spreadsheet_binary_data` was base64-encoded (as is the case with all binary fields), meaning the file was read, encoded to base64, and assigned to `spreadsheet_binary_data`. To retrieve the serialized JSON, it then had to be decoded again. By avoiding this redundant steps, we optimize the time spent in `_compute_spreadsheet_data`: before: ~100ms after: ~30ms Task: 4256155
This update removes outdated setup details from automated guided tour tests after recent platform changes. It keeps internal test definitions simpler and easier to maintain, with no expected change for end users.
Original PR description
After this commit: https://github.com/odoo/odoo/commit/37b35f18bd9138a9a8717d17268f375607b9482e Some attributes were useless in the registry of the tour. They have been deleted. TASK-ID: 4070659
Resolved issues and error corrections
Follow-up emails now attach the Partner Ledger in the customer’s selected language instead of the sender’s language. This helps customers receive account information they can understand and reduces confusion in multilingual collections processes.
Original PR description
If a language is set on the customer when doing the followup, the attached Partner Ledger was always generated in the language of the active user. Instead, if a language is set on the customer, we want to use it.
A previously disabled automated test for the mobile web interface has been re-enabled after the underlying testing issue was fixed. This improves confidence that mobile event handling continues to work correctly without changing user-facing behavior.
Original PR description
Since the fix in HOOT was merged the test can actually be run. https://github.com/odoo/odoo/pull/183099
Fixed an error that could stop recruitment data extraction when adding candidate skills. The system now uses the correct candidate reference, helping recruiters avoid failed or interrupted candidate processing.
Original PR description
Error is generated because ``applicant_id`` field is used to create record of ``hr.candidate.skill`` model. Error: ``ValueError: Invalid field 'applicant_id' on model 'hr.candidate.skill'`` https://github.com/odoo/enterprise/blob/0c7c006dcd0ba53ff9a7aa8ca2446794505a6916/hr_recruitment_extract/models/hr_candidate.py#L60-L61 Here, ``applicant_id`` field is used instead of ``candidate_id`` field. sentry-5983999720
The dashboard now shows accurate counts for bills waiting to be paid or overdue, including bills with split payment terms. This helps users trust the dashboard figures and avoid confusion when opening the related bill lists.
Original PR description
Description of the issue this commit addresses: Since recently, the <[X] To Pay> and <[X] Late> buttons don't send the user to an account.move.line model view anymore but to an account.move model one…
Description of the issue this commit addresses:
Since recently, the <[X] To Pay> and <[X] Late> buttons don't send the user to an account.move.line model view anymore but to an account.move model one but when that change was made, the computation of the number of items on the dashboard was not changed so it was still counting the amount of account.move. line there was in the account.move items that were shown in the view resulting in wrong totals.
---
Steps to reproduce:
1. Install account
2. Create new Vendor Bill with a split payment term ("30% now, Balance 60 Days" for example) on today's date for Bill Date.
3. Go to the dashboard, click the <[X] To Pay> button.
4. the amount of moves in the view that is opened with the button is one above the value of "X" in the button.
This is due to using a split payment term that creates two installment for a single vendor bill hence counting one more aml than there are moves.
---
Desired behavior after this commit is merged:
The right amount of To Pay and Late moves is shown at all times.
---
Note on the fix:
The fix for this issue is in the community PR of the bundle, the fix modifies a method which was overriden in enterprise and this PR addresses the override to match with the new version of the method.
---
Community PR: https://github.com/odoo/odoo/pull/181535
No taskFixed an error that prevented users from opening Vietnamese sales and purchase tax return reports in certain tax period views. This ensures companies using Vietnam localization can access required tax reports reliably.
Original PR description
Currently, a traceback is occurring when the user tries to open a Vietnamese tax returns report. To reproduce this issue: 1) Install l10n_vn_reports and switch to VN company 2) Create an invoice with a product and tax 3) Now open the Tax Returns and change the report as `Sales/Purchase Tax Report (VN)` and tax period in years Error:- ``` ProgrammingError: can't adapt type 'dict' ``` This error is occurring because in `column_group_options` we get the values as dict. For the method `_currency_table_apply_rate` we expect the value to be in the string. To handle the dict for returning the join conditions we use `_currency_table_aml_join`. sentry-5962808992
Miscellaneous changes
This task was created to modify the demo data for Argentina, to avoid using real partner information. latam-task-1239 adhoc-task-41734 Forward-Port-Of: odoo/enterprise#71471 Forward-Port-Of: odoo/enterprise#71230
Original PR description
This task was created to modify the demo data for Argentina, to avoid using real partner information. latam-task-1239 adhoc-task-41734 Forward-Port-Of: odoo/enterprise#71471 Forward-Port-Of: odoo/enterprise#71230
When invoicing an order from the PoS the invoice was not signed by the government before rendering the pdf of the invoice. This lead to a missing QR Code on the invoice. Steps to reproduce: ------------------- * Install l10n_pe_edi_pos module * Open the PoS * Make an order and invoice it > Observation: The invoice should contains a QR Code attesting that the document has been signed by the government but it's not Why the fix: ------------ The issue was that the invoice was sent to
Original PR description
When invoicing an order from the PoS the invoice was not signed by the government before rendering the pdf of the invoice. This lead to a missing QR Code on the invoice. Steps to reproduce: ------------------- * Install l10n_pe_edi_pos module * Open the PoS * Make an order and invoice it > Observation: The invoice should contains a QR Code attesting that the document has been signed by the government but it's not Why the fix: ------------ The issue was that the invoice was sent to the government after the invoice was rendered. To fix it we make the call to the government manually instead of waiting for the CRON to send it. We also cancel the CRON for this specific invoice so that it is not called twice. This is based on what is done here : https://github.com/odoo/odoo/blob/647197c0eae7ef786fa3d1aeafeafd1d14fe0fae/addons/l10n_es_pos_tbai/models/pos_order.py#L18-L29 opw-4165399 Forward-Port-Of: odoo/enterprise#70583
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period. Forward-Port-Of: odoo/enterprise#71642
Original PR description
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period. Forward-Port-Of: odoo/enterprise#71642
Issue: When a sale order made from the website with a pickup point (for instance using a sendcloud delivery method) is confirmed, a new partner is created to mix the data of the partner making the order and the address of the pickup point. If the partner is named Bob, this new partner will be named Bob, Bob. It woul dbe much clearer if he was named: Bob, pickup point name. opw-4181787 Forward-Port-Of: odoo/enterprise#71567
Original PR description
Issue: When a sale order made from the website with a pickup point (for instance using a sendcloud delivery method) is confirmed, a new partner is created to mix the data of the partner making the order and the address of the pickup point. If the partner is named Bob, this new partner will be named Bob, Bob. It woul dbe much clearer if he was named: Bob, pickup point name. opw-4181787 Forward-Port-Of: odoo/enterprise#71567
Issue ---- When clicking an account report cell with the cash basis filter on, `account_reports_cash_basis.account_report.action_audit_cell` adds a domain to filter out `account.move.line`s that don't belong to the cash basis criteria. However, the model is not always an `account.move.line`. If an analytic account column is added with the "Analytic Group By" option, the model is `account.analytic.line`, which results in a field not found error. Steps ---- - Go to Accounting -> Report
Original PR description
Issue ---- When clicking an account report cell with the cash basis filter on, `account_reports_cash_basis.account_report.action_audit_cell` adds a domain to filter out `account.move.line`s that don't belong to the cash basis criteria. However, the model is not always an `account.move.line`. If an analytic account column is added with the "Analytic Group By" option, the model is `account.analytic.line`, which results in a field not found error. Steps ---- - Go to Accounting -> Reporting -> Profit and Loss. - From the Options button above, select "Cash Basis Method". - From the Analytic Group By button, add an analytic account in the "Accounts" filter. - Click on a cell under the analytic account's column. - An error is thrown. Cause ---- Domain is applied on the wrong model. opw-4034786 Forward-Port-Of: odoo/enterprise#68094 Forward-Port-Of: odoo/enterprise#66890
When automatic entries are generated, a sequence number should not be assigned on them as long as they are on draft state. This is done because it may be confusing to see a sequence name for a move in draft. This commit ensures that the name of the entries is 'Draft' (or '/') when the move is generated. A sequence number will be assigned once the move is posted. Before this commit, it was possible to generate a draft move with a sequence number when doing a deferred entries with some entries in
Original PR description
When automatic entries are generated, a sequence number should not be assigned on them as long as they are on draft state. This is done because it may be confusing to see a sequence name for a move in draft. This commit ensures that the name of the entries is 'Draft' (or '/') when the move is generated. A sequence number will be assigned once the move is posted. Before this commit, it was possible to generate a draft move with a sequence number when doing a deferred entries with some entries in the future. task-4069862 Forward-Port-Of: odoo/enterprise#71409 Forward-Port-Of: odoo/enterprise#70855
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed: ``py File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create thread._message_auto_subscribe(create_values, followers_existing_policy='update') File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscr
Original PR description
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed: ``py File…
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed:
``py
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create
thread._message_auto_subscribe(create_values, followers_existing_policy='update')
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscribe
res = self._message_auto_subscribe_followers(updated_values, def_ids)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/enterprise/sale_subscription/models/account_move.py", line 76, in _message_auto_subscribe_followers
if salesperson and user_id == salesperson.id and user_id != self.env.user.id:
^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.users(56, 60)
```
Forward-Port-Of: odoo/enterprise#71188### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create an associated repair order and add a line for an other product in the part tabs - Go back to the return picking #### > the product added to the repair was also added to the retur
Original PR description
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer…
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create an associated repair order and add a line for an other product in the part tabs - Go back to the return picking #### > the product added to the repair was also added to the return picking ### Cause of the issue: A `default_picking_id` is added to the context of the form view of the repair order by the `_prepare_repairs_default_value` of the `action_repair_order_form` so that it prefils the form of the repair: https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L36-L40 https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L55-L56 However, this values stays in the context and will be added as a default value for each of the move that will be creted from this view. ### Fix: Thanks to commit odoo/odoo@3898d61046cc0338082fdcbe0df282241372361a, we now have a default getter that can be used to associate a default picking id to the repair order when necessary without the need to put a `default_picking_id` in the context. opw-4159779 Forward-Port-Of: odoo/enterprise#71704 Forward-Port-Of: odoo/enterprise#71337
1. Create Vendor bill and register payment 2. Create credit note for the vendor bill 4. Open the CABA entry created from vendor bill 5. Reverse Entry 6. Check DIOT report Issue: DIOT report shows negative line, but it not allowed CABA Entries should not be reverted, as the reversal generate a document with negative tax grid. They will revert automatically after the original document is reset to draft. opw-4142232 Forward-Port-Of: odoo/enterprise#70223
Original PR description
1. Create Vendor bill and register payment 2. Create credit note for the vendor bill 4. Open the CABA entry created from vendor bill 5. Reverse Entry 6. Check DIOT report Issue: DIOT report shows negative line, but it not allowed CABA Entries should not be reverted, as the reversal generate a document with negative tax grid. They will revert automatically after the original document is reset to draft. opw-4142232 Forward-Port-Of: odoo/enterprise#70223
1. Enable "auto-detect" on the Avatax fiscal position, 2. Go to "Abigail Peterson" contact and set "United States" as country 3. Expenses > My Expenses > New 4. Enter a description, set a total and "Abigail Peterson" as employee 5. "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" Issue: Validation error will raise because of the incomplete address However we only handle customer invoices and customer invoice refunds (aka credit notes) with external tax integr
Original PR description
1. Enable "auto-detect" on the Avatax fiscal position, 2. Go to "Abigail Peterson" contact and set "United States" as country 3. Expenses > My Expenses > New 4. Enter a description, set a total and "Abigail Peterson" as employee 5. "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" Issue: Validation error will raise because of the incomplete address However we only handle customer invoices and customer invoice refunds (aka credit notes) with external tax integrations so the constraint should only show for journal entries of this type. opw-4151193 Forward-Port-Of: odoo/enterprise#71747 Forward-Port-Of: odoo/enterprise#71543
Commit 1 ======== Steps to reproduce the issue: - add comment to a Facebook/youtube post. - keeping the `Comments` dialog box open, try replying the same comment. - we get a traceback. Reason: - due to the missing comments data structure, we get an error when trying to add the new comment. - LOC responsible for the traceback: https://github.com/odoo/enterprise/blob/16.0/social/static/src/xml/social_templates.xml#L311 Fix: - since the comments data structure is not returned from t
Original PR description
Commit 1 ======== Steps to reproduce the issue: - add comment to a Facebook/youtube post. - keeping the `Comments` dialog box open, try replying the same comment. - we get a traceback. Reason: - due…
Commit 1 ======== Steps to reproduce the issue: - add comment to a Facebook/youtube post. - keeping the `Comments` dialog box open, try replying the same comment. - we get a traceback. Reason: - due to the missing comments data structure, we get an error when trying to add the new comment. - LOC responsible for the traceback: https://github.com/odoo/enterprise/blob/16.0/social/static/src/xml/social_templates.xml#L311 Fix: - since the comments data structure is not returned from the post request made to post the commnet, we manually ensure it exists. Commit 2 ======== [FIX] social: fix various issues 1. social_instagram: ISSUES: - create a post on the instagram platform with commenting turned off. - try commenting on it from Odoo. We get a traceback. - also, if we delete the post from the platform and then try to comment from Odoo, we get a traceback. REASON: - there is no existing implementation to check if commenting is enabled/disabled on the post. FIX: - we now check if commenting is enabled or not while trying to add comment on the post TECHNICAL NOTE: - the correct way to check if commenting on a post is enabled or not is to request a field named `is_comment_enabled`. - more details --- https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-media - but to save us from making an extra request, we simply catch the error received to when trying to add a comment. ================================================================================ 2. social_linkedin ISSUE: - delete an existing post from the linkedIn platform. - now try commenting on it from Odoo. We get a traceback. REASON: - The response received from the request to fetch the comments is not validated. FIX: - validating the response before further execution. Task-3759530 Forward-Port-Of: odoo/enterprise#71534 Forward-Port-Of: odoo/enterprise#67079
Before this commit: The information of message sender using email alias was not shown, instead only mail subject with name Odoobot was displayed in chatter. After this commit: The information of sender such as email address, name, subject of email and email body is not displayed in chatter along with the attachment. Task - 4008634 Forward-Port-Of: odoo/enterprise#66503
Original PR description
Before this commit: The information of message sender using email alias was not shown, instead only mail subject with name Odoobot was displayed in chatter. After this commit: The information of sender such as email address, name, subject of email and email body is not displayed in chatter along with the attachment. Task - 4008634 Forward-Port-Of: odoo/enterprise#66503
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a grouped Payment in MXN for those invoices 5. Go to one of the Invoices and click on Update Payments 6. Go to the CFDI tab and, on the Payment line, click on Force CFDI 7. On the Payment line, you should now be able to Download an XML document 8. In the document, the EquivalenciaDR attributes
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a…
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a grouped Payment in MXN for those invoices 5. Go to one of the Invoices and click on Update Payments 6. Go to the CFDI tab and, on the Payment line, click on Force CFDI 7. On the Payment line, you should now be able to Download an XML document 8. In the document, the EquivalenciaDR attributes should have the same values, which is not the case ### Explanation: When calculating the rate (which then is used in EquivalenciaDR) in `_l10n_mx_edi_add_payment_cfdi_values`, we are using amounts that have been rounded out, leading to rates that differ when aiming for certain decimal precisions. ### Fix reasoning: While `_get_conversion_rate` can be used to avoid the inconsistencies of the rounded amounts, it should not be used if the values do not match once they are converted, since the rate would then be wrong. opw-4090269 Forward-Port-Of: odoo/enterprise#70083
**Current behavior:** Using 2 step delivery and modifying the route so the pick action's src location is a child of lot_stock will result in the move not being found by the Procurement mechanism, which can lead to inaccurate quantity being encoded on transfers created from rental orders. **Expected behavior:** Transfer quantity should match sale order line quantity. **Steps to reproduce:** 1. Enable 2-step delivery in the warehouse 2. In the 2-step delivery route, change the src loca
Original PR description
**Current behavior:** Using 2 step delivery and modifying the route so the pick action's src location is a child of lot_stock will result in the move not being found by the Procurement mechanism,…
**Current behavior:** Using 2 step delivery and modifying the route so the pick action's src location is a child of lot_stock will result in the move not being found by the Procurement mechanism, which can lead to inaccurate quantity being encoded on transfers created from rental orders. **Expected behavior:** Transfer quantity should match sale order line quantity. **Steps to reproduce:** 1. Enable 2-step delivery in the warehouse 2. In the 2-step delivery route, change the src location of the pick action (pull rule) to be a sub-location of WH/STOCK 3. Enable rental transfers in settings 4. Create a new rental order, add a product, confirm the order 5. Add some quantity to the order line and save 6. Look at the generated out-going picking's moves -> the demand is wrong **Cause of the issue:** The original move created when confirming the order, before editing the order line quantity, is not found when the additional move is created for the modified quantity. Existing outgoing moves are expected to have a location_id (source location) of WH/STOCK (warehouse.lot_stock_id), ours will have a location_id of some sub-location. **Fix:** Check all child locations of lot_stock (which includes lot_stock itself) when aggregating outgoing moves. opw-4178446 Forward-Port-Of: odoo/enterprise#71559
To reproduce: ============= - log as admin and create a template on sign - give a user with **User : Own templates** authorization to the template - log as the user and try to use layout (from 3 dots in kanban view) -> access error Problem: ======== when duplicating the template we copy the original template, as the user does not have enough rights it leads to an access error Solution: ========= perform the copy as `sudo`, as the template won't be visible for the user if he is not
Original PR description
To reproduce: ============= - log as admin and create a template on sign - give a user with **User : Own templates** authorization to the template - log as the user and try to use layout (from 3 dots in kanban view) -> access error Problem: ======== when duplicating the template we copy the original template, as the user does not have enough rights it leads to an access error Solution: ========= perform the copy as `sudo`, as the template won't be visible for the user if he is not authorized to see it. opw-4166973 Forward-Port-Of: odoo/enterprise#70496
10 changes
Enhancements to existing features
This update ensures that all date fields in a document are filled with the same date format when signing, rather than varying based on the user's location. The date format now depends on the company partner's language setting, providing a consistent and professional appearance across all signed documents.
Original PR description
Before this commit, it was possible to fill two date fields in two different date formats in the same document. This happened because the date format was dependent on the location of the user who is signing. After this commit, date fields will be auto-filled by a fixed date format, that format depends on the language of the company's partner. Task: 3930358
Resolved issues and error corrections
This update fixes a technical issue that occurred when upgrading the Belgium and Hong Kong payroll modules with demo data. The leave type records are now marked as non-updatable to prevent constraint violations during module upgrades, ensuring smoother system updates for users in these regions.
Original PR description
The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field. There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records. To reproduce: - Install `l10n_hk_hr_payroll` with demo data - Upgrade the module Forward-Port-Of: odoo/enterprise#71844
This fix prevents duplicate accounting records from being created when setting up companies with parent-subsidiary relationships. The system now loads the chart of accounts from parent companies first during initialization and migration, ensuring clean and accurate financial data structures across all localization modules.
Original PR description
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records
This update resolves a crash that occurred when users tried to print or export the trial balance report to Excel. The issue was caused by a recent code change that didn't properly handle certain data conditions, resulting in an error message instead of a successful export. Users can now export trial balance reports without encountering errors.
Original PR description
before this commit, on printing trial balance report in excel, raises an exception when the level is None it cannot be compared with >= and thus exception is shown: elif level >= 3: TypeError: '>=' not supported between instances of 'NoneType' and 'int'  introduced in the commit: https://github.com/odoo/enterprise/commit/9d1f27082cc2e837951a3a5c3337cc90531de04a after this commit, no error wont be shown when printing trial balance in excel Forward-Port-Of: odoo/enterprise#71846
This fix prevents helpdesk timesheets from being incorrectly merged together when tracking time on different helpdesk tickets. Previously, when users tracked time on different tickets within the same helpdesk project, the system would combine them into a single timesheet entry instead of creating separate ones. This update ensures each ticket gets its own timesheet record, improving time tracking accuracy for helpdesk teams.
Original PR description
Steps to reproduce: - Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting - Timesheets app > Start timer - Set your helpdesk project and any task (Do not add a description) - Stop timer >…
Steps to reproduce: - Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting - Timesheets app > Start timer - Set your helpdesk project and any task (Do not add a description) - Stop timer > Do it again with same the project and a different task - Stop timer > Time is added to previous timesheet The expected behavior would be to create a new timesheet since the task is different. The reason both timesheets are merged is that we check 'task_id' for redundance while helpdesk 'tasks' are instead recorded in the 'helpdesk_ticket_id'. Since it is forbidden for a timesheet to have both a 'task_id' and 'helpdesk_ticket_id', it is guaranteed that task_id will be False for both of our entries, leading to a merge. Similarily we can use that property since adding helpdesk_ticket_id to the domain won't change the usual behavior (the field will always be False if the project is not from Helpdesk) to add an extra condition here. Source: we have a contraint '_check_no_link_task_and_ticket' which ensures that. opw-4203678
This fix improves the default configuration for document projects by automatically setting the correct group assignment. Previously, users could easily forget to configure the proper group settings, leading to incorrect access permissions. This change reduces manual configuration errors and ensures documents are properly organized from the start.
Original PR description
It’s too easy to forget to set the right group opw-4206894 Forward-Port-Of: odoo/enterprise#70894
Fixed a system error that occurred when calculating taxes on invoices with multiple product lines using different cost centers, where the same tax applied to each line. The system now properly handles multiple tax lines for the same tax by distributing any rounding differences evenly across all affected lines, preventing calculation failures.
Original PR description
Set up Avatax environment Create an Invoice with 2 lines: - Prod A, Analytic Account A - Prod B, Analytic Account B Compute taxes Now open one of the newly added taxes On the repartition line click on the 3 dots menu, show 'Tax Closing Entry' Disable 'Tax Closing Entry' on the invoice repartition line Now go back to the invoice Compute taxes again Issue: Traceback will raise 'ValueError: Expected singleton: account.move.line(...' This occurs because, with this tax configuration, on the move we will have 2 tax lines for the same tax, as the lines needs a different analytic account and cannot be grouped together. When we compare the amount per tax we'll have a recordset and it will raise an error. A solution is to acknowledge that we might have more than 1 line and split the possible difference evenly on the tax lines opw-3976597
This fix resolves an issue where users received a CSRF error when uploading documents through the document request feature. The problem was caused by JavaScript files loading in the wrong order, preventing security tokens from being properly added. The fix reorders the file loading sequence to ensure all necessary components are available before they're needed.
Original PR description
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_public_pages.js) could not be loaded due to an error caused by website_sale_renting: `TypeError: odoo.define is not a function` The mixin file was loaded before the odoo module loader. Caused by: https://github.com/odoo/enterprise/commit/93d09071a08bd5de948886729d827b1c46e907d9 Fix: --- Put js code from website_sale_renting before owl.js which is right after assets_frontend_minimal, containing module_loader.js opw-4138333
This fix resolves a problem where the real-time connection breaks when users delete and recreate a spreadsheet in different browser tabs. The system now properly checks if a spreadsheet exists before attempting to update it, preventing connection failures when working with spreadsheets.
Original PR description
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590
This update resolves two critical issues that prevented users from generating Mexican electronic invoices (CFDI) when using the Autozone Addenda feature with sales orders. The fix ensures that date information is properly formatted and handles cases where invoices are created from multiple sales orders, allowing the invoice generation process to complete successfully.
Original PR description
This commit targets to fix two errors: 1.- When trying to create the EDI document for an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. ### Cause:…
This commit targets to fix two errors:
1.- When trying to create the EDI document for
an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared.
### Cause:
In attribute t-att-PODATE for the Autozone Addenda we are sending a datetime object
to the strptime function of datetime which in reality it needs to receive a string
object instead. This raises a TypeError
### Solution:
Since the objective is to set a string date, we convert the date_order into a string date
using strftime function from datetime module
### Steps to reproduce:
- Install 'Sales' application and 'l10n_mx_edi' module
- In a company with mexican localization selected go to Sales > Quotations and create a new Order
- Select a contact with the Addenda Autozone selected
- Confirm it and create the corresponding invoice
- Confirm the invoice and generate the CFDI
***
2.- When creating an invoice from multiple sale orders with contact with Addenda Autozone selected, a traceback is raised
### Steps to reproduce:
- Install 'Sales' application and 'l10n_mx_edi' module
- In a company with mexican localization selected go to Sales > Quotations
- Create two orders at least with a contact with Addenda Autozone selected and confirmed them
- In tree view select created orders and click on Create Invoices
- Go to Created Invoice and confirm it and generate the CFDI
### Cause:
In attribute t-att-PODATE for the Autozone Addenda is not expecting a recordset when initializing the
value of sale_id, this causes a ValueError: expected singleton error when retrieving value of date_order
when we create a invoice for multiple sale orders
### Solution:
Initialize sale_id with the first order retrieved to use it