Thursday, January 2, 2025
61 changes
11 changes
Miscellaneous changes
Some accounts got the wrong code, while the id rightly changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191844 Forward-Port-Of: odoo/odoo#191826
Original PR description
Some accounts got the wrong code, while the id rightly changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191844 Forward-Port-Of: odoo/odoo#191826
Description of the issue/feature this PR addresses: This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements. The issue it can solve happens when 2 different commercial entities use the same paying partner (ie a partner that is not a subcontact) to pay their invoices. When an invoice is paid by the paying partner, Odoo will store the account number that was used for the transfer on account.bank.statement.line. When this statem
Original PR description
Description of the issue/feature this PR addresses: This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements. The issue it can solve…
Description of the issue/feature this PR addresses: This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements. The issue it can solve happens when 2 different commercial entities use the same paying partner (ie a partner that is not a subcontact) to pay their invoices. When an invoice is paid by the paying partner, Odoo will store the account number that was used for the transfer on account.bank.statement.line. When this statement line is reconciled with an invoice, if the bank account was not stored on the partner previously, a res.partner.bank will be created automatically. When another payment is coming from the same bank account, Odoo will then select the partner linked to the bank account that it did store previously, even if the payment was for an invoice linked to another partner, and it will not propose the proper invoice in the reconciliation widget, even if it uses an exact match on the payment reference number. Having a parameter allowing to skip creation of the bank account in Odoo will allow the reconciliation to be based striclty on the reference number. Current behavior before PR: Bank account is stored and wrong invoices are proposed by the reconciliation widget Desired behavior after PR is merged: Allow to avoid storing bank account and having wrong invoices are proposed by the reconciliation widget --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173351 Forward-Port-Of: odoo/odoo#168029
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task without any project set). This commit adds a default value inside the context of the main action used in To-Do to make sure the default value for `project_id` field in To-Do is false and nothing else. Steps to reproduce ================== 1. Install Project app 2. Go to Project app 3. Sel
Original PR description
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task…
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task without any project set). This commit adds a default value inside the context of the main action used in To-Do to make sure the default value for `project_id` field in To-Do is false and nothing else. Steps to reproduce ================== 1. Install Project app 2. Go to Project app 3. Select/create a project 4. Select/create and edit a task inside 5. Enable the debug mode 6. Click on debug menu and select `Set Default Values` 7. Apply `project = <your project selected/created>` and save 8. Go to To-Do app 9. Create a to-do Expected Behavior ----------------- A to-do should be created without any issue in the kanban view. Current Behavior ---------------- A form view will be displayed inside a modal to create the to-do but the form view is in fact the one used in Project app and the project set is the one set as default value instead of having no project since the user is creating a to-do and not a task inside that project. Forward-Port-Of: odoo/odoo#191583
The context variable is missing in current thread when using the shell command. see d19478eb03d2 Description of the issue this PR addresses: Use the `odoo shell -d dbname` command ``` Current behavior before PR: Traceback (most recent call last): File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 87, in __new__ return cls.registries[db_name] ~~~~~~~~~~~~~~^^^^^^^^^ File "/home/bfontaine/Bureau/local/venv17/lib/python3.11/site-packages/decor
Original PR description
The context variable is missing in current thread when using the shell command. see d19478eb03d2 Description of the issue this PR addresses: Use the `odoo shell -d dbname` command ``` Current…
The context variable is missing in current thread when using the shell command.
see d19478eb03d2
Description of the issue this PR addresses:
Use the `odoo shell -d dbname` command
```
Current behavior before PR:
Traceback (most recent call last):
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 87, in __new__
return cls.registries[db_name]
~~~~~~~~~~~~~~^^^^^^^^^
File "/home/bfontaine/Bureau/local/venv17/lib/python3.11/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
~~~~~~^^^^^
KeyError: 'db_test'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 110, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/bfontaine/Bureau/odoo17/addons/phyto_base/loader.py", line 13, in load_modules
report = odoo.registry()._assertion_report
^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/__init__.py", line 105, in registry
database_name = threading.current_thread().dbname
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: '_MainThread' object has no attribute 'dbname'
Traceback (most recent call last):
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 87, in __new__
return cls.registries[db_name]
~~~~~~~~~~~~~~^^^^^^^^^
File "/home/bfontaine/Bureau/local/venv17/lib/python3.11/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
~~~~~~^^^^^
KeyError: 'db_test'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/bfontaine/.local/bin/odoo17", line 246, in <module>
main()
File "/home/bfontaine/.local/bin/odoo17", line 242, in main
run()
File "/home/bfontaine/.local/bin/odoo17", line 233, in run
odoo.cli.main()
File "/home/bfontaine/Bureau/odoo/17.0/odoo/cli/command.py", line 66, in main
o.run(args)
File "/home/bfontaine/Bureau/odoo/17.0/odoo/cli/shell.py", line 123, in run
self.shell(config['db_name'])
File "/home/bfontaine/Bureau/odoo/17.0/odoo/cli/shell.py", line 109, in shell
registry = odoo.registry(dbname)
^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/__init__.py", line 106, in registry
return modules.registry.Registry(database_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 89, in __new__
return cls.new(db_name)
^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/local/venv17/lib/python3.11/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 110, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/bfontaine/Bureau/odoo17/addons/phyto_base/loader.py", line 13, in load_modules
report = odoo.registry()._assertion_report
^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/__init__.py", line 105, in registry
database_name = threading.current_thread().dbname
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: '_MainThread' object has no attribute 'dbname'. Did you mean: '_name'?
```
Desired behavior after PR is merged:
shell command works
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#192038Before this commit, when a time off request based on extra hours was set to draft, a new overtime record with negative duration was created. This commit makes sure that the record is only created when the time off request is in the state confirm or validate. task-4096548 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189711 Forward-Port-Of: odoo/odoo#185962
Original PR description
Before this commit, when a time off request based on extra hours was set to draft, a new overtime record with negative duration was created. This commit makes sure that the record is only created when the time off request is in the state confirm or validate. task-4096548 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189711 Forward-Port-Of: odoo/odoo#185962
In case an extra dependency is added to the api.depends decorator of account.move._compute_journal_id, account.payment.partner_bank_id is going to be recomputed, potentially overwriting existing value. Steps to reproduce: 1. Install a module adding a dependency to account.move._compute_journal_id 2. Create a vendor bill with a partner having more than one bank account 3. Register payment using another bank account than the first one The created payment would then have its bank account r
Original PR description
In case an extra dependency is added to the api.depends decorator of account.move._compute_journal_id, account.payment.partner_bank_id is going to be recomputed, potentially overwriting existing value. Steps to reproduce: 1. Install a module adding a dependency to account.move._compute_journal_id 2. Create a vendor bill with a partner having more than one bank account 3. Register payment using another bank account than the first one The created payment would then have its bank account recomputed. By testing for an existing value in the compute function before assigning the first bank account of the partner, we ensure any manually defined value will not be overwritten through unwanted recomputation. For context: https://github.com/OCA/sale-workflow/pull/3321 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181278
Three commits are included in this PR. - One adds a base module for all Nilvera modules - One adds a module to handle sending and receiving E-Invoices and E-Archives to and from Nilvera. - One adds general improvements to UBL. task-3952234 Forward-Port-Of: odoo/odoo#180283
Original PR description
Three commits are included in this PR. - One adds a base module for all Nilvera modules - One adds a module to handle sending and receiving E-Invoices and E-Archives to and from Nilvera. - One adds general improvements to UBL. task-3952234 Forward-Port-Of: odoo/odoo#180283
When field widgets were ported to OWL in 48ef812a, a few ARIA attributes were not adapted correctly. For instance, in the statusbar widget, the title was ported as an `aria-label` attribute ("Current state" and "Not active state"), which overrides the actual status name. This commit fixes the above issue by removing the incorrect `aria-label` attributes and fixing logic for other ones like `aria-checked`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/s
Original PR description
When field widgets were ported to OWL in 48ef812a, a few ARIA attributes
were not adapted correctly. For instance, in the statusbar widget, the
title was ported as an `aria-label` attribute ("Current state" and "Not
active state"), which overrides the actual status name.
This commit fixes the above issue by removing the incorrect `aria-label`
attributes and fixing logic for other ones like `aria-checked`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#191431
Forward-Port-Of: odoo/odoo#183447**Issue:** in the Saudi Arabia localization, the delivery address is not displayed on invoices even if `Customer Addresses` is enabled. **Steps to reproduce:** 1. Go to settings and enable `Customer Addresses`. 2. Install the Saudi Arabia localization. 3. create an invoice with a delivery address other than the customer's. 4. Print the invoice. 5. notice that the delivery address is not displayed on the invoice. **Solution:** - Added the delivery address to the invoice report next t
Original PR description
**Issue:** in the Saudi Arabia localization, the delivery address is not displayed on invoices even if `Customer Addresses` is enabled. **Steps to reproduce:** 1. Go to settings and enable `Customer Addresses`. 2. Install the Saudi Arabia localization. 3. create an invoice with a delivery address other than the customer's. 4. Print the invoice. 5. notice that the delivery address is not displayed on the invoice. **Solution:** - Added the delivery address to the invoice report next to the QR code. opw-4337379 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190976
Authentication data was accidentally logged when sending requests to the Authorize API. This change stops logging such data to avoid security breaches. opw-4311870 Forward-Port-Of: odoo/odoo#191219
Original PR description
Authentication data was accidentally logged when sending requests to the Authorize API. This change stops logging such data to avoid security breaches. opw-4311870 Forward-Port-Of: odoo/odoo#191219
**Problem**: When destroying a snippet, listeners are not cleared. As a result, when focusing on a new instance of `ReplaceMedia`, the previous listeners remain active with stale context (old `$target`), which no longer has a parent since it was removed during the `img` change. **Solution**: Clear listeners during the `destroy` process. **Steps to reproduce**: 1. Open the website. 2. Add items. 3. Change an image. 4. Unlink that image. 5. Observe a traceback. opw-4412300 ---
Original PR description
**Problem**: When destroying a snippet, listeners are not cleared. As a result, when focusing on a new instance of `ReplaceMedia`, the previous listeners remain active with stale context (old `$target`), which no longer has a parent since it was removed during the `img` change. **Solution**: Clear listeners during the `destroy` process. **Steps to reproduce**: 1. Open the website. 2. Add items. 3. Change an image. 4. Unlink that image. 5. Observe a traceback. opw-4412300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191142
11 changes
Miscellaneous changes
**Problem**: When destroying a snippet, listeners are not cleared. As a result, when focusing on a new instance of `ReplaceMedia`, the previous listeners remain active with stale context (old `$target`), which no longer has a parent since it was removed during the `img` change. **Solution**: Clear listeners during the `destroy` process. **Steps to reproduce**: 1. Open the website. 2. Add items. 3. Change an image. 4. Unlink that image. 5. Observe a traceback. opw-4412300 ---
Original PR description
**Problem**: When destroying a snippet, listeners are not cleared. As a result, when focusing on a new instance of `ReplaceMedia`, the previous listeners remain active with stale context (old `$target`), which no longer has a parent since it was removed during the `img` change. **Solution**: Clear listeners during the `destroy` process. **Steps to reproduce**: 1. Open the website. 2. Add items. 3. Change an image. 4. Unlink that image. 5. Observe a traceback. opw-4412300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191142
Before this commit, when a time off request based on extra hours was set to draft, a new overtime record with negative duration was created. This commit makes sure that the record is only created when the time off request is in the state confirm or validate. task-4096548 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185962
Original PR description
Before this commit, when a time off request based on extra hours was set to draft, a new overtime record with negative duration was created. This commit makes sure that the record is only created when the time off request is in the state confirm or validate. task-4096548 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185962
Authentication data was accidentally logged when sending requests to the Authorize API. This change stops logging such data to avoid security breaches. opw-4311870 Forward-Port-Of: odoo/odoo#191219
Original PR description
Authentication data was accidentally logged when sending requests to the Authorize API. This change stops logging such data to avoid security breaches. opw-4311870 Forward-Port-Of: odoo/odoo#191219
**Issue:** in the Saudi Arabia localization, the delivery address is not displayed on invoices even if `Customer Addresses` is enabled. **Steps to reproduce:** 1. Go to settings and enable `Customer Addresses`. 2. Install the Saudi Arabia localization. 3. create an invoice with a delivery address other than the customer's. 4. Print the invoice. 5. notice that the delivery address is not displayed on the invoice. **Solution:** - Added the delivery address to the invoice report next t
Original PR description
**Issue:** in the Saudi Arabia localization, the delivery address is not displayed on invoices even if `Customer Addresses` is enabled. **Steps to reproduce:** 1. Go to settings and enable `Customer Addresses`. 2. Install the Saudi Arabia localization. 3. create an invoice with a delivery address other than the customer's. 4. Print the invoice. 5. notice that the delivery address is not displayed on the invoice. **Solution:** - Added the delivery address to the invoice report next to the QR code. opw-4337379 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190976
[FIX] portal, point_of_sale: return new instance of fields list This commit contains a backport of https://github.com/odoo/odoo/commit/1e39d5c2e5f4d4c77b0190ea1eb4781e2143657f to fix the following issue: In the l10n_mx localization, the field RFC(VAT) and zipcode should be required to prevent the field from being defaulted to "public en general". How to reproduce: -Install l10n_mx -Go to POS and sell an article to generate the ticket -Go to the POS portal to request an invoice -Fill
Original PR description
[FIX] portal, point_of_sale: return new instance of fields list This commit contains a backport of https://github.com/odoo/odoo/commit/1e39d5c2e5f4d4c77b0190ea1eb4781e2143657f to fix the following issue: In the l10n_mx localization, the field RFC(VAT) and zipcode should be required to prevent the field from being defaulted to "public en general". How to reproduce: -Install l10n_mx -Go to POS and sell an article to generate the ticket -Go to the POS portal to request an invoice -Fill all the fields except for RFC -Odoo does not request this field and allows the client to submit the information -The invoice will be generated to "public en general" and not to the client requesting the invoice (Expected when there is no RFC) opw-4332357 enterprise pr: https://github.com/odoo/enterprise/pull/74072 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187674
The context variable is missing in current thread when using the shell command. see d19478eb03d2 Description of the issue this PR addresses: Use the `odoo shell -d dbname` command ``` Current behavior before PR: Traceback (most recent call last): File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 87, in __new__ return cls.registries[db_name] ~~~~~~~~~~~~~~^^^^^^^^^ File "/home/bfontaine/Bureau/local/venv17/lib/python3.11/site-packages/decor
Original PR description
The context variable is missing in current thread when using the shell command. see d19478eb03d2 Description of the issue this PR addresses: Use the `odoo shell -d dbname` command ``` Current…
The context variable is missing in current thread when using the shell command.
see d19478eb03d2
Description of the issue this PR addresses:
Use the `odoo shell -d dbname` command
```
Current behavior before PR:
Traceback (most recent call last):
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 87, in __new__
return cls.registries[db_name]
~~~~~~~~~~~~~~^^^^^^^^^
File "/home/bfontaine/Bureau/local/venv17/lib/python3.11/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
~~~~~~^^^^^
KeyError: 'db_test'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 110, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/bfontaine/Bureau/odoo17/addons/phyto_base/loader.py", line 13, in load_modules
report = odoo.registry()._assertion_report
^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/__init__.py", line 105, in registry
database_name = threading.current_thread().dbname
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: '_MainThread' object has no attribute 'dbname'
Traceback (most recent call last):
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 87, in __new__
return cls.registries[db_name]
~~~~~~~~~~~~~~^^^^^^^^^
File "/home/bfontaine/Bureau/local/venv17/lib/python3.11/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
~~~~~~^^^^^
KeyError: 'db_test'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/bfontaine/.local/bin/odoo17", line 246, in <module>
main()
File "/home/bfontaine/.local/bin/odoo17", line 242, in main
run()
File "/home/bfontaine/.local/bin/odoo17", line 233, in run
odoo.cli.main()
File "/home/bfontaine/Bureau/odoo/17.0/odoo/cli/command.py", line 66, in main
o.run(args)
File "/home/bfontaine/Bureau/odoo/17.0/odoo/cli/shell.py", line 123, in run
self.shell(config['db_name'])
File "/home/bfontaine/Bureau/odoo/17.0/odoo/cli/shell.py", line 109, in shell
registry = odoo.registry(dbname)
^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/__init__.py", line 106, in registry
return modules.registry.Registry(database_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 89, in __new__
return cls.new(db_name)
^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/local/venv17/lib/python3.11/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 110, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/bfontaine/Bureau/odoo17/addons/phyto_base/loader.py", line 13, in load_modules
report = odoo.registry()._assertion_report
^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/__init__.py", line 105, in registry
database_name = threading.current_thread().dbname
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: '_MainThread' object has no attribute 'dbname'. Did you mean: '_name'?
```
Desired behavior after PR is merged:
shell command works
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#192038Steps to reproduce: - Install hr_timesheet (with demo data) - Navigate to portal > timesheet - Group by project Issue: When only the hr_timesheet module is installed and timesheets are grouped in the portal view, the column alignment is broken due to an incorrect colspan. Cause: When groupby is applied, the colspan is manually set to 4, causing misalignment between the header and row columns. Fix: This commit sets the last column's colspan to 2 when grouping is applied to fix th
Original PR description
Steps to reproduce: - Install hr_timesheet (with demo data) - Navigate to portal > timesheet - Group by project Issue: When only the hr_timesheet module is installed and timesheets are grouped in the portal view, the column alignment is broken due to an incorrect colspan. Cause: When groupby is applied, the colspan is manually set to 4, causing misalignment between the header and row columns. Fix: This commit sets the last column's colspan to 2 when grouping is applied to fix the alignment issue. task-4294780 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186532
Description of the issue/feature this PR addresses: This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements. The issue it can solve happens when 2 different commercial entities use the same paying partner (ie a partner that is not a subcontact) to pay their invoices. When an invoice is paid by the paying partner, Odoo will store the account number that was used for the transfer on account.bank.statement.line. When this statem
Original PR description
Description of the issue/feature this PR addresses: This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements. The issue it can solve…
Description of the issue/feature this PR addresses: This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements. The issue it can solve happens when 2 different commercial entities use the same paying partner (ie a partner that is not a subcontact) to pay their invoices. When an invoice is paid by the paying partner, Odoo will store the account number that was used for the transfer on account.bank.statement.line. When this statement line is reconciled with an invoice, if the bank account was not stored on the partner previously, a res.partner.bank will be created automatically. When another payment is coming from the same bank account, Odoo will then select the partner linked to the bank account that it did store previously, even if the payment was for an invoice linked to another partner, and it will not propose the proper invoice in the reconciliation widget, even if it uses an exact match on the payment reference number. Having a parameter allowing to skip creation of the bank account in Odoo will allow the reconciliation to be based striclty on the reference number. Current behavior before PR: Bank account is stored and wrong invoices are proposed by the reconciliation widget Desired behavior after PR is merged: Allow to avoid storing bank account and having wrong invoices are proposed by the reconciliation widget --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173351 Forward-Port-Of: odoo/odoo#168029
Versions 16.0+ Description of the issue/feature this PR addresses: The issue occurs when selecting a partner in an invoice, the sales team is not correctly computed. The problem arises because the default_team_id is not passed as a parameter to the context when the partner is selected, which works correctly in sales orders but fails in invoices. Current behavior before PR: When modifying the partner_id in an invoice, the sales team is not recomputed, leading to incorrect or missing
Original PR description
Versions 16.0+ Description of the issue/feature this PR addresses: The issue occurs when selecting a partner in an invoice, the sales team is not correctly computed. The problem arises because the…
Versions 16.0+ Description of the issue/feature this PR addresses: The issue occurs when selecting a partner in an invoice, the sales team is not correctly computed. The problem arises because the default_team_id is not passed as a parameter to the context when the partner is selected, which works correctly in sales orders but fails in invoices. Current behavior before PR: When modifying the partner_id in an invoice, the sales team is not recomputed, leading to incorrect or missing sales team assignment. Desired behavior after PR is merged: After this PR is merged, modifying the partner_id on an invoice will correctly recompute the sales team by passing the default_team_id in the context, ensuring consistent behavior between invoices and sales orders. I will now provide a short video demonstrating the error. This issue is replicable if none of the sales teams have any members assigned. https://drive.google.com/file/d/15mUpXvdlVpGZXW976PK7EVYH6X4sm2CJ/view?usp=sharing PR of v16 https://github.com/odoo/odoo/pull/180961 Forward-Port-Of: odoo/odoo#181244
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task without any project set). This commit adds a default value inside the context of the main action used in To-Do to make sure the default value for `project_id` field in To-Do is false and nothing else. Steps to reproduce ================== 1. Install Project app 2. Go to Project app 3. Sel
Original PR description
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task…
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task without any project set). This commit adds a default value inside the context of the main action used in To-Do to make sure the default value for `project_id` field in To-Do is false and nothing else. Steps to reproduce ================== 1. Install Project app 2. Go to Project app 3. Select/create a project 4. Select/create and edit a task inside 5. Enable the debug mode 6. Click on debug menu and select `Set Default Values` 7. Apply `project = <your project selected/created>` and save 8. Go to To-Do app 9. Create a to-do Expected Behavior ----------------- A to-do should be created without any issue in the kanban view. Current Behavior ---------------- A form view will be displayed inside a modal to create the to-do but the form view is in fact the one used in Project app and the project set is the one set as default value instead of having no project since the user is creating a to-do and not a task inside that project. Forward-Port-Of: odoo/odoo#191583
Some accounts got the wrong code, while the id rightly changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191844 Forward-Port-Of: odoo/odoo#191826
Original PR description
Some accounts got the wrong code, while the id rightly changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191844 Forward-Port-Of: odoo/odoo#191826
12 changes
Enhancements to existing features
Removed an unused piece of WhatsApp messaging code that was left over after a related interface change. This has no expected change for users, but keeps the codebase simpler and easier to maintain.
Original PR description
Since odoo/odoo#186084, the `hasSendButtonNonEditing` getter has been removed from the composer template. This commit removes that getter, as it's now dead code. Related to odoo/odoo#192103
The Field Service Tasks Analysis report was adjusted to match recent changes that removed an inactive-task filter. This keeps reporting views working correctly without requiring broader changes to field service or task analysis reports.
Original PR description
- Removed the inactive filter in the Tasks Analysis report, so we need to update the xpath accordingly. Technical: - If the `inactive` filter is added in the `project_task_view_search_fsm_base` view, it will require the removal of both the Task Analysis report and the FSM report. Hence, we should not include the `inactive` filter in the `project_task_view_search_fsm_base`. Related : https://github.com/odoo/odoo/pull/175518 task-4037091
Resolved issues and error corrections
When a quotation or sales order is deleted, its custom spreadsheet is now removed as well. This prevents order-specific spreadsheets from being reused accidentally in quotation templates, keeping sales documents cleaner and more accurate.
Original PR description
Currently, when deleting a quotation/SO with a custom `sale.order.spreadsheet`, the latter will see its field `order_id` empty and will become available to be linked to a quotation template. Since it's a custom spreadsheet for that specific SO, it makes no sense to keep it. opw-4385254
Code cleanup and technical improvements
This internal update aligns the Documents Kanban view with a related platform change by making required setup information explicit. Users should not notice a feature change, but it helps keep the Documents interface stable and easier to maintain.
Original PR description
This commit is the counterpart of odoo/odoo#191307.
Miscellaneous changes
To be more clear, we add the original amount from the statement we are to reconciliating on the open balance line. task-4194671 Forward-Port-Of: odoo/enterprise#76146 Forward-Port-Of: odoo/enterprise#70785
Original PR description
To be more clear, we add the original amount from the statement we are to reconciliating on the open balance line. task-4194671 Forward-Port-Of: odoo/enterprise#76146 Forward-Port-Of: odoo/enterprise#70785
This commit's purpose is to add a test for the full flow of the creation of a BOM/MO when they are linked to a project. This is to ensure that the aal generated are generated correctly and that the project profitability is then computing them into the correct section. community pr: https://github.com/odoo/odoo/pull/186607 task - 4184226 affetced version 18.0 - master Forward-Port-Of: odoo/enterprise#76157 Forward-Port-Of: odoo/enterprise#74398
Original PR description
This commit's purpose is to add a test for the full flow of the creation of a BOM/MO when they are linked to a project. This is to ensure that the aal generated are generated correctly and that the project profitability is then computing them into the correct section. community pr: https://github.com/odoo/odoo/pull/186607 task - 4184226 affetced version 18.0 - master Forward-Port-Of: odoo/enterprise#76157 Forward-Port-Of: odoo/enterprise#74398
When the `l10n_be_hr_payroll_sepa_salary_payment` context option is passed, an extra `<Ustrd>` gets generated with the Urgency SEPA flag. After the refactoring in odoo/enterprise#60393, when there is no recognized reference type in the default `_get_RmtInf()` generation[^1], we end up with 2 Ustrd elements like this: ```xml <RmtInf> <Ustrd>SPLIP/1234</Ustrd> <Ustrd>/A/ SPLIP/1234</Ustrd> </RmtInf> ``` The SEPA file then gets rejected by banks as invalid. Instead we should detect
Original PR description
When the `l10n_be_hr_payroll_sepa_salary_payment` context option is passed, an extra `<Ustrd>` gets generated with the Urgency SEPA flag. After the refactoring in odoo/enterprise#60393, when there is no recognized reference type in the default `_get_RmtInf()` generation[^1], we end up with 2 Ustrd elements like this: ```xml <RmtInf> <Ustrd>SPLIP/1234</Ustrd> <Ustrd>/A/ SPLIP/1234</Ustrd> </RmtInf> ``` The SEPA file then gets rejected by banks as invalid. Instead we should detect the pre-existing element and update it. [^1]: https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/account_iso20022/models/account_journal.py#L324-L326 Forward-Port-Of: odoo/enterprise#74692
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking
Original PR description
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the…
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking will cause a rollback of the entire batch on Odoo's side, pikcings might end up being processed on the carrier side but non validated on Odoo's side during batch validation. ### Steps to reproduce: - Configure sendcloud shipping method + website + payment providers - In your sendcloud configuration select sendcloud shipping product to not be able to handle products with a weight exceeding 10 kg e.g; bpost @home (0-10kg). - Create 2 storable products with respective weigth 1 and 100 kg. - Publish them on the website for sale. - Open a private window, make an order via the website for the 1kg product by filling your cart and use sendcloud as carrier. - Repeat the operation with the other product to generate a seconde SO. - Back to your main window > Inventory Overview > Delivery Orders - Select both deliveries > Action > Validate (in batch) #### > While the first delivery order was processed on carrier side (can be checked on sendcloud's website) #### > the UserError of the second DO rollbacked its validation in Odoo. ### Fix: As such, and since the carrier requests needs to happen after we have validated the pickings in Odoo, we should avoid any rollback of the transaction once any requests has already been successfully treated on the carrier side. ### Note: It is not possible restructure the code to use `senf.env.cr.savepoint` in a loop in order to reset the validation of pickings that are not valid on the carrier side because savepoints can't be used more than 64 times before the server crashes and hence can't be used in record loops. community: https://github.com/odoo/odoo/pull/190320 opw-4357325 Forward-Port-Of: odoo/enterprise#76244 Forward-Port-Of: odoo/enterprise#75502
Before this commit: Only `companyName` is included in shipping requests sent to FedEx. After this commit: `personName` is added to the request, same as `companyName`. According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different. Checked with FedEx support, and they said it is required to send the `personName` field always. opw-4415536 Forward-Port-Of: odoo/enterprise#76307
Original PR description
Before this commit: Only `companyName` is included in shipping requests sent to FedEx. After this commit: `personName` is added to the request, same as `companyName`. According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different. Checked with FedEx support, and they said it is required to send the `personName` field always. opw-4415536 Forward-Port-Of: odoo/enterprise#76307
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to
Original PR description
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice…
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to `17.0` https://github.com/odoo/enterprise/commit/56a2b66d84d8398ea870d559cd55cfeae44019d8 - In `17.0` we introduced this Extract method `_l10n_mx_edi_import_cfdi_get_tax_from_node` to refactor the `_l10n_mx_edi_import_cfdi_fill_invoice_line`. - We should have add the Exento checks in the new method however we mistakenly pushed code from `saas-16.4` to `17.0` without adapting it. - I removed the extra code introduced during the forward-porting. - Refactored the related code to ensure compatibility with the new changes in `17.0`. OPW-4198016 Forward-Port-Of: odoo/enterprise#76209 Forward-Port-Of: odoo/enterprise#74602
Issue: After posting content through Social Marketing on Instagram, the generated link redirects to a non-existent post or page. Steps to Reproduce: 1. Install the Social Marketing tool. 3. Set up an Instagram account connection. 3. Create a post and attempt to click on the generated link for redirection to the post on Instagram. Solution: The issue stems from using Instagram's internal post_id, which does not work for direct URL access to the post. To resolve this, we need to requ
Original PR description
Issue: After posting content through Social Marketing on Instagram, the generated link redirects to a non-existent post or page. Steps to Reproduce: 1. Install the Social Marketing tool. 3. Set up an Instagram account connection. 3. Create a post and attempt to click on the generated link for redirection to the post on Instagram. Solution: The issue stems from using Instagram's internal post_id, which does not work for direct URL access to the post. To resolve this, we need to request the permalink associated with the post rather than relying on the internal link. This will ensure accurate redirection. While using the shortcode is an alternative, requesting the permalink directly is a more reliable approach. opw-4243329 Forward-Port-Of: odoo/enterprise#72725
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4.…
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7. The document should be accepted, but TipoCambio has a rate of 1.000000. ### Explanation: During the creation of the Global Invoice, the rate is retrieved during `pos.order._prepare_tax_base_line_values` and, since no value is given through POS, the default value is used. https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1242 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1212-L1213 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1188-L1193 ### Fix reasoning: Adding test to make sure Foreign Currency can be used in Global Invoice for `pos.order` and rate is correctly set as well. Fix in Community opw-4302180 Forward-Port-Of: odoo/enterprise#75185
23 changes
New functionality added to Odoo
This change adds a new linked custom extension repository to the enterprise codebase. It helps include organization-specific Odoo 18 customizations as part of the project setup, with minimal direct impact on everyday users until those customizations are used.
Enhancements to existing features
This update improves performance in the Expenses app by making expense lines easier for the system to find by their related expense sheet. Users may notice faster loading or processing in areas that read, submit, or recalculate expense sheet information, especially as data volume grows.
Original PR description
## Why
- Inverse of the One2many `expense_line_ids`, the ORM will search on it to resolve the read on the field
- Used as a traversable dependency of a few compute methods (`@api. depends('sheet_id.xxx')`), index will be hit when ORM resolves the computation of dependencies to know what compute method to call when the dependency changed.
- Frequently used as the traversal field of related fields, index will be hit when reading on the field in SQL in `_traverse_related_sql`.
- Using Full index, as there aren't many `NULL`/`False` entries, as it's moslty pending expense lines that are pending for reporting. So a search on the NULL criteria (done in `get_expenses_to_submit`) will hit the index.
## Reference
task-3977983
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update changes the security support documentation to show that Odoo 15.0 is no longer actively supported. It helps customers and partners plan upgrades and understand which versions remain covered for security maintenance.
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
Resolved issues and error corrections
The tax form for Argentine withholding now shows the Minimum Threshold field for applicable perception taxes. This helps users correctly view and manage threshold settings without hidden information on the tax form.
Original PR description
It is needed to make not invisible "Minimum Treshold" on applied perceptions AR taxes. Task Adhoc side: 43625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The TDS Entry button is now shown for payments that have already been marked as paid, not only those still in process. This helps users complete or review withholding tax entries without needing the payment to remain in an intermediate state.
Original PR description
Before This Commit: - The TDS Entry button is visible only in `In Process` state. After This Commit: - The TDS Entry button is visible in both `In Process` and `Paid` state. Task: 4432364
This change prevents a sales-related automated test from failing when the broader sales management app is not installed. It improves reliability for Odoo.sh projects that use Sales features through custom modules without enabling the full Sales Management menu.
Original PR description
### Description of the issue this PR addresses: Test TestSaleComboConfigurator.test_sale_combo_configurator (introduced with #186645) depends on the Sale menu being shown, but it isn't if the sale_management module is not installed. This change skips this test in this case. ### Current behavior before PR: The test fails on odoo.sh with custom modules that only depend on sale and not sale_management. ### Desired behavior after PR is merged: The test succeeds in the condition mentionned above. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes an unnecessary hidden field from the French localization company form. It prevents a test failure on Odoo SH and helps keep the module compliant with Odoo view validation rules.
Original PR description
Description of the issue/feature this PR addresses: The field **is_france_country** was added to the **l10n_fr.res_company_form_l10n_fr** view with the invisible attribute set to 1. This caused an error on Odoo SH due to commit #162009. Since fields used in Python expressions are automatically added to the view, we do not need to keep it. Current behavior before PR: When you enable tests for the module l10n_fr, you have the following error : Please indicate why the always invisible fields are present in the view, or remove the field tag. Addons: 'l10n_fr' Views: ['res_company_form_l10n_fr'] Desired behavior after PR is merged: Pass the test test_uncommented_invisible_field --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in Firefox where users could not open the editing popover for button-styled links in the HTML editor. Users can now click and edit these links normally, improving reliability when preparing website or email content.
Original PR description
**Current behavior before PR:** - In Firefox, the user-select: none style disabled text selection and prevented the cursor from being placed inside a button. This caused the button click to fail in opening the link popover. **Desired behavior after PR is merged:** - The user-select property for the btn class is changed from none to auto. This allows users to place the cursor inside the button-styled link, enabling editing and ensuring the link popover can be opened as expected. task:4358091 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a quotation or sales order is deleted, its custom spreadsheet is now removed as well. This prevents order-specific spreadsheets from being reused accidentally in quotation templates, keeping sales data cleaner and more consistent.
Original PR description
Currently, when deleting a quotation/SO with a custom `sale.order.spreadsheet`, the latter will see its field `order_id` empty and will become available to be linked to a quotation template. Since it's a custom spreadsheet for that specific SO, it makes no sense to keep it. opw-4385254
The chat window header buttons are now slightly larger, making them easier to click on desktop. This reduces small interaction frustrations for users who frequently use chat quick actions.
Original PR description
Click on quick ation button in Chat window header was a bit tedious in desktop. This happens because the clickable area is 24px x 24px. This commit makes it easier by increasing to 28px x 28px, thanks to explicit `p-1` on buttons. This ain't much but this gives less frustration to use chat window quick actions. <img width="601" alt="Screenshot 2025-01-02 at 18 23 47" src="https://github.com/user-attachments/assets/b0c09d0c-906b-43b9-b8f7-6fb954c34998" />
Miscellaneous changes
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task without any project set). This commit adds a default value inside the context of the main action used in To-Do to make sure the default value for `project_id` field in To-Do is false and nothing else. Steps to reproduce ================== 1. Install Project app 2. Go to Project app 3. Sel
Original PR description
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task…
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task without any project set). This commit adds a default value inside the context of the main action used in To-Do to make sure the default value for `project_id` field in To-Do is false and nothing else. Steps to reproduce ================== 1. Install Project app 2. Go to Project app 3. Select/create a project 4. Select/create and edit a task inside 5. Enable the debug mode 6. Click on debug menu and select `Set Default Values` 7. Apply `project = <your project selected/created>` and save 8. Go to To-Do app 9. Create a to-do Expected Behavior ----------------- A to-do should be created without any issue in the kanban view. Current Behavior ---------------- A form view will be displayed inside a modal to create the to-do but the form view is in fact the one used in Project app and the project set is the one set as default value instead of having no project since the user is creating a to-do and not a task inside that project. Forward-Port-Of: odoo/odoo#191583
Some accounts got the wrong code, while the id rightly changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191844 Forward-Port-Of: odoo/odoo#191826
Original PR description
Some accounts got the wrong code, while the id rightly changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191844 Forward-Port-Of: odoo/odoo#191826
When field widgets were ported to OWL in 48ef812a, a few ARIA attributes were not adapted correctly. For instance, in the statusbar widget, the title was ported as an `aria-label` attribute ("Current state" and "Not active state"), which overrides the actual status name. This commit fixes the above issue by removing the incorrect `aria-label` attributes and fixing logic for other ones like `aria-checked`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/s
Original PR description
When field widgets were ported to OWL in 48ef812a, a few ARIA attributes
were not adapted correctly. For instance, in the statusbar widget, the
title was ported as an `aria-label` attribute ("Current state" and "Not
active state"), which overrides the actual status name.
This commit fixes the above issue by removing the incorrect `aria-label`
attributes and fixing logic for other ones like `aria-checked`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#191494
Forward-Port-Of: odoo/odoo#183447- edit the codition to check if the active model is HR to use the smae plan summary as the buttom rfom the employee from Task: 4237311 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#189480
Original PR description
- edit the codition to check if the active model is HR to use the smae plan summary as the buttom rfom the employee from Task: 4237311 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#189480
- Implemented proper validation logic for Uruguayan VAT numbers (RUT). - Now supports VAT numbers starting with '22', addressing previous validation issues. - Corrections in l10n_uy tests due to changes in logic. Task: 1292 adhoc-task-side: 45613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192058 Forward-Port-Of: odoo/odoo#191066
Original PR description
- Implemented proper validation logic for Uruguayan VAT numbers (RUT). - Now supports VAT numbers starting with '22', addressing previous validation issues. - Corrections in l10n_uy tests due to changes in logic. Task: 1292 adhoc-task-side: 45613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192058 Forward-Port-Of: odoo/odoo#191066
Authentication data was accidentally logged when sending requests to the Authorize API. This change stops logging such data to avoid security breaches. opw-4311870 Forward-Port-Of: odoo/odoo#191219
Original PR description
Authentication data was accidentally logged when sending requests to the Authorize API. This change stops logging such data to avoid security breaches. opw-4311870 Forward-Port-Of: odoo/odoo#191219
**Issue:** in the Saudi Arabia localization, the delivery address is not displayed on invoices even if `Customer Addresses` is enabled. **Steps to reproduce:** 1. Go to settings and enable `Customer Addresses`. 2. Install the Saudi Arabia localization. 3. create an invoice with a delivery address other than the customer's. 4. Print the invoice. 5. notice that the delivery address is not displayed on the invoice. **Solution:** - Added the delivery address to the invoice report next t
Original PR description
**Issue:** in the Saudi Arabia localization, the delivery address is not displayed on invoices even if `Customer Addresses` is enabled. **Steps to reproduce:** 1. Go to settings and enable `Customer Addresses`. 2. Install the Saudi Arabia localization. 3. create an invoice with a delivery address other than the customer's. 4. Print the invoice. 5. notice that the delivery address is not displayed on the invoice. **Solution:** - Added the delivery address to the invoice report next to the QR code. opw-4337379 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190976
**Problem**: When destroying a snippet, listeners are not cleared. As a result, when focusing on a new instance of `ReplaceMedia`, the previous listeners remain active with stale context (old `$target`), which no longer has a parent since it was removed during the `img` change. **Solution**: Clear listeners during the `destroy` process. **Steps to reproduce**: 1. Open the website. 2. Add items. 3. Change an image. 4. Unlink that image. 5. Observe a traceback. opw-4412300 ---
Original PR description
**Problem**: When destroying a snippet, listeners are not cleared. As a result, when focusing on a new instance of `ReplaceMedia`, the previous listeners remain active with stale context (old `$target`), which no longer has a parent since it was removed during the `img` change. **Solution**: Clear listeners during the `destroy` process. **Steps to reproduce**: 1. Open the website. 2. Add items. 3. Change an image. 4. Unlink that image. 5. Observe a traceback. opw-4412300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191142
Steps to reproduce : ------------------------- - Install the point_of_sale module. - Order something and go to payment page. - Apply multiple payment lines even with 0 amount. Issue : ------- The payment lines with 0 amount is also shown on receipt as well. Cause : ---------- We never checked for the amount of paymentline. Fix : ---- Updated the condition to remove 0 amount paymentline from the view. task - 4285705 Forward-Port-Of: odoo/odoo#185448
Original PR description
Steps to reproduce : ------------------------- - Install the point_of_sale module. - Order something and go to payment page. - Apply multiple payment lines even with 0 amount. Issue : ------- The payment lines with 0 amount is also shown on receipt as well. Cause : ---------- We never checked for the amount of paymentline. Fix : ---- Updated the condition to remove 0 amount paymentline from the view. task - 4285705 Forward-Port-Of: odoo/odoo#185448
To retrieve the radio button corresponding to the currently-selected status in the statusbar, selector is currently relying on the attribute `aria-label`, but such attribute is incorrect and will be removed. Better relying on the attribute `aria-checked`, which indicates if the radio button is actually checked. Forward-Port-Of: odoo/enterprise#76053 Forward-Port-Of: odoo/enterprise#72063
Original PR description
To retrieve the radio button corresponding to the currently-selected status in the statusbar, selector is currently relying on the attribute `aria-label`, but such attribute is incorrect and will be removed. Better relying on the attribute `aria-checked`, which indicates if the radio button is actually checked. Forward-Port-Of: odoo/enterprise#76053 Forward-Port-Of: odoo/enterprise#72063
Before this commit: Only `companyName` is included in shipping requests sent to FedEx. After this commit: `personName` is added to the request, same as `companyName`. According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different. Checked with FedEx support, and they said it is required to send the `personName` field always. opw-4415536 Forward-Port-Of: odoo/enterprise#76307
Original PR description
Before this commit: Only `companyName` is included in shipping requests sent to FedEx. After this commit: `personName` is added to the request, same as `companyName`. According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different. Checked with FedEx support, and they said it is required to send the `personName` field always. opw-4415536 Forward-Port-Of: odoo/enterprise#76307
Previously, when a customer was selected or input was entered, the onboarding tour failed to proceed to the next step. With this fix, the tour will correctly advance when the user provides input. Without demo data, the database does not have Deco, so I used admin. task-4372470 Forward-Port-Of: odoo/enterprise#75100
Original PR description
Previously, when a customer was selected or input was entered, the onboarding tour failed to proceed to the next step. With this fix, the tour will correctly advance when the user provides input. Without demo data, the database does not have Deco, so I used admin. task-4372470 Forward-Port-Of: odoo/enterprise#75100
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create Global Invoice and Confirm 5. Log as User without Admin Rights 6. Select Invoice 7. Receive access error: > Sorry, [user] doesn't have 'read' access to: > - Attachment (ir.attachment) ### Explanation: When creating a Global Invoice, `ir.attachment` is created as well and link
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create…
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create Global Invoice and Confirm 5. Log as User without Admin Rights 6. Select Invoice 7. Receive access error: > Sorry, [user] doesn't have 'read' access to: > - Attachment (ir.attachment) ### Explanation: When creating a Global Invoice, `ir.attachment` is created as well and linked to the Global Invoice `l10n_mx_edi.document`, but if the link from document to attachment is complete, the opposite is not the case. `ir.attachment.res_id` has a value of 0, and, when checking access rights for `ir.attachment`, we will use the `_search` method in which one of three conditions, two of them having a `res_id` check, must be fulfilled for `ir.attachment` to be considered available to the user. https://github.com/odoo/odoo/blob/afdfbc4041f167ba6d6ff6c17b8432eb531df6b1/odoo/addons/base/models/ir_attachment.py#L561-L570 A user that did not Create Global Invoice and without `base.group_system` in their `groups_id` fulfills none of those conditions. ### Fix reasoning: The issue lies more within `res_id` not being `l10n_mx_edi.document.id` rather than a flaw in `_search`. This change should only apply when creating a Global Invoice. When sending an Invoice to the CFDI through the regular `action_send_and_print` process, `ir.attachment` is linked to `account.move` instead. opw-4365535 Forward-Port-Of: odoo/enterprise#76023 Forward-Port-Of: odoo/enterprise#75031
4 changes
Resolved issues and error corrections
This update addresses a technical issue in the l10n_mx_edi module that caused reports to break when views were inherited. By adding names to specific view elements, the change ensures these views remain stable even with small updates, preventing disruptions to report generation. This improves the reliability of the Mexican EDI functionality.
Original PR description
There are currently some elements in views that are not reachable on a deterministic way when those views are inherited. That means, to reach them, positional selectors need to be used (e.g. `last()`). That causes inherited views to get broken when there are small changes in element position.
A good example of this is [1]:
<div class="digital-stamp">
<span>Extra Info</span>
</div>
Which can't be filtered by:
- Class, because there are several `<div>` elements with the same class
- Text content, because when content is translated, selector will fail
To solve the above, this change provides names for several elements, to make possible/easier to reach them on a safely manner.
[1] https://github.com/odoo/enterprise/blob/d6346ef8/l10n_mx_edi/views/l10n_mx_edi_report_invoice.xml#L123
Forward-Port-Of: odoo/enterprise#64604
Forward-Port-Of: odoo/enterprise#63957This update resolves an issue where spreadsheet templates couldn't correctly handle grouped date fields. The fix prevents incorrect assumptions about date granularity during template creation, ensuring accurate spreadsheet generation. This improves the reliability of reports and dashboards.
Original PR description
When creating a spreadsheet.template, we ensure the values of each groupbys are correctly ordered. Tthe current implementation assumes that the groupby will return values present in the tables and not values altered by a groupby with specific granularity (namely date fields) by adding the values to the search domain. Unfortunately, the search does not support dates with a granularity different than `day`. This revision ensures that we do not add such grouped values to the search domain. Task-4438631 Forward-Port-Of: odoo/enterprise#76290
This update corrects a minor typo in the system's notification process for employee contracts. The fix ensures that salary-related messages are correctly sent, preventing potential disruptions to payroll and contract management workflows. This ensures accurate and timely communication regarding contract details.
Original PR description
Forward-Port-Of: odoo/enterprise#75991
This update fixes a bug preventing the helpdesk onboarding tour from progressing when users provided input. The fix removed a hardcoded string check, allowing the tour to correctly advance based on user actions, improving the user experience.
Original PR description
Previously, when a customer was selected or input was entered, the onboarding tour failed to proceed to the next step. With this fix, the tour will correctly advance when the user provides input. Without demo data, the database does not have Deco.so i so I select the partner. When the user does not provide the ticket name 'SAP is bad, paid by Odoo,' the tour will not move to the next step because we had checked a fixed string. Therefore, I have removed it and checked the kanban class instead. task-4372470 Forward-Port-Of: odoo/enterprise#75106