Thursday, January 2, 2025
17 changes · saas-17.2
Miscellaneous changes
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
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#76298 Forward-Port-Of: odoo/enterprise#76290
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#57781
Original PR description
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#57781
Forward-Port-Of: odoo/enterprise#76056 Forward-Port-Of: odoo/enterprise#75991
Original PR description
Forward-Port-Of: odoo/enterprise#76056 Forward-Port-Of: odoo/enterprise#75991
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
Since [1], this flow is broken: 1. Install website_helpdesk => You have a "Help" menu with an helpdesk team as url (/helpdesk/customer-care-1) which is created 2. Check: if you publish or unpublish your team, that menu is visible or invisible as a public user. 3. Create a new menu for your website, with that same URL (/helpdesk/customer-care-1) 4. Check: that menu is always invisible as a public user. Even if you remove the first menu. Multiple mistakes were made with [1]: - Th
Original PR description
Since [1], this flow is broken: 1. Install website_helpdesk => You have a "Help" menu with an helpdesk team as url (/helpdesk/customer-care-1) which is created 2. Check: if you publish or unpublish…
Since [1], this flow is broken: 1. Install website_helpdesk => You have a "Help" menu with an helpdesk team as url (/helpdesk/customer-care-1) which is created 2. Check: if you publish or unpublish your team, that menu is visible or invisible as a public user. 3. Create a new menu for your website, with that same URL (/helpdesk/customer-care-1) 4. Check: that menu is always invisible as a public user. Even if you remove the first menu. Multiple mistakes were made with [1]: - The website menu visibility override code was added twice in two different files. - The override advertises that this is for "always showing the helpdesk team menus even if they are unpublished" but it is actually meant to be the exact opposite of that. - The implementation is based on the menu that are linked to the helpdesk teams, not on their URL **. - The implementation actually bypass the normal visibility computation for all menu URL that start with "/helpdesk", meaning a custom page "/helpdesk-hello" from the user is just broken, so as existing controllers not linked to an helpdesk team (such as /helpdesk/rating). **: actually this could mean that this feature is just not meant to be given the current state of the codebase: creating a menu with a team URL should just make it so it is forcefully linked to that team or should be prevented if it cannot (?). [1]: https://github.com/odoo/enterprise/commit/a888fb57ebd2458bc8479e187088cb2e96b811fa opw-3931376 Forward-Port-Of: odoo/enterprise#63105
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 cla
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#76147 Forward-Port-Of: odoo/enterprise#75106
**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