Daily updates from Odoo
Tuesday, February 6, 2024
18 changes · master
Enhancements to existing features
Creating a Helpdesk team with the same name as an existing team no longer fails because of a duplicate email alias. The system now automatically adjusts the new team's email alias, reducing setup interruptions for support teams.
Original PR description
Currently, creating a helpdesk team with an existing name results in an error due to the limitation of using identical email aliases for separate teams. This PR introduces a change: If a team's creation generates an already-used email alias, the system will add '2' to the new alias. task-3450431
Resolved issues and error corrections
This fix prevents an error that could occur when users click detected fields after OCR processing a vendor bill. It helps keep the invoice upload and review flow stable for accounting users using document recognition.
Original PR description
This commit addresses the missing props declaration in the BoxLayer component. The following changes were made: - Added the previously omitted onClickBoxCallback props definition. - Corrected the validation method for the pageLayer props. Steps to reproduce: 1. Open Accounting with an IAP OCR setup in debug mode. 2. Navigate to Vendor Bills > Upload (Choose a scanned PDF or picture). 3. Wait for the OCR process to complete. 4. Click inside a detected field => Traceback.
A field service test tour now accounts for the setup prompt that appears when no worksheet templates exist. This prevents automated checks from failing in empty or freshly configured databases, improving reliability without changing normal user workflows.
Original PR description
…template Steps to reproduce: - start TestIndustryFsmUi python test after removing all your worksheet templates. Source: - A wizard was added to create a worksheet template if there is no worksheet template. So this wizard doesn't usually appear and when it appears there is no step in the tour to handle it. Fix: - An additional step was added to the tour to verify if the wizard exist and choose to create a new template. task-3716386 X-original-commit: https://github.com/odoo/enterprise/commit/2b1c2af82d1fbb4286d4eb16f156f5e1092c17b8
Code cleanup and technical improvements
The spreadsheet pivot setup has been adjusted to use a newer internal definition format. This keeps pivot insertion and related spreadsheet features aligned with platform changes, helping maintain reliability without changing the user workflow.
Miscellaneous changes
Sending a CANCEL request while a SIP session is being established will result in a 487 Request Terminated response to the pending INVITE request. Prior to this commit, cancelling a SIP session would cause the session to be deleted twice: once immediately after the CANCEL request was sent, then a second time after the response to the INVITE request was received, resulting in a crash the second time because the session had already been deleted. After this commit, 487 Request Terminated respo
Original PR description
Sending a CANCEL request while a SIP session is being established will result in a 487 Request Terminated response to the pending INVITE request. Prior to this commit, cancelling a SIP session would cause the session to be deleted twice: once immediately after the CANCEL request was sent, then a second time after the response to the INVITE request was received, resulting in a crash the second time because the session had already been deleted. After this commit, 487 Request Terminated responses are ignored, preventing the code from attempting to delete the already deleted session and causing a crash. opw-3702140 Forward-Port-Of: odoo/enterprise#55842
Following commit 1b2977811516cce4830ceaf1a7585c8f7061243a we now send the stock inventory for all the products linked to an Amazon offer. At the time, it was decided to send FBA and FBM updates at the same time because: - The Amazon documentation didn't say anything about it - It avoided the problem of a strange configuration of the customer where a product in FBM could be placed in the Amazon location, as nothing ensure that everything placed there is, indeed, a FBA product, even if this is t
Original PR description
Following commit 1b2977811516cce4830ceaf1a7585c8f7061243a we now send the stock inventory for all the products linked to an Amazon offer. At the time, it was decided to send FBA and FBM updates at…
Following commit 1b2977811516cce4830ceaf1a7585c8f7061243a we now send the stock inventory for all the products linked to an Amazon offer. At the time, it was decided to send FBA and FBM updates at the same time because: - The Amazon documentation didn't say anything about it - It avoided the problem of a strange configuration of the customer where a product in FBM could be placed in the Amazon location, as nothing ensure that everything placed there is, indeed, a FBA product, even if this is the recommended setting. - After testing the synchronization of the FBM stock, we couldn't see any changes in the Amazon backend, which lead us to think that we couldn't, in fact, update the stock of a FBA product as Amazon would ensure the stock used would be the one in their warehouse. Recently, we got some problem with FBA order that Amazon considered being FBM. After investigation, it was found that the stock send for FBA would be set as having a "DEFAULT" fulfilment channel, but this wasn't shown anywhere on Amazon backend, only in their DB. So from time to time, instead of using the set fulfilment channel of a product, Amazon would use that default one, with a separate, virtual, stock. With this fix, we ensure that this "default" channel is now filled with a quantity of 0 instead, for FBA product. We assume the set-up of the Amazon account on Odoo is correctly made and all products in the Amazon location are FBA. task-3693853 Forward-Port-Of: odoo/enterprise#54737
Previously, we were always returning a box in the validation request, even when no box was clicked by the user. Now, the box will only be part of the request if it was indeed clicked by the user and that its text matches the text of the field. This has little impact on the learning of the AI model as it was mostly relying on the text of the validated value, not its box. Forward-Port-Of: odoo/enterprise#55783 Forward-Port-Of: odoo/enterprise#55643
Original PR description
Previously, we were always returning a box in the validation request, even when no box was clicked by the user. Now, the box will only be part of the request if it was indeed clicked by the user and that its text matches the text of the field. This has little impact on the learning of the AI model as it was mostly relying on the text of the validated value, not its box. Forward-Port-Of: odoo/enterprise#55783 Forward-Port-Of: odoo/enterprise#55643
Step to reproduce: - have two products - add one quant of each in the same package - create a out stock move - scan 1 item - scan the package Issue: A high volume of product arrivals with multiple barcodes per item can lead to occasional errors in scanning the wrong barcode (package). Time consuming to redo everything. Solution: Whenever one or multiple item have already been scanned, we ask the user a confirmation if they scan a package barcode. opw-3610819 Forward-Port-Of: odo
Original PR description
Step to reproduce: - have two products - add one quant of each in the same package - create a out stock move - scan 1 item - scan the package Issue: A high volume of product arrivals with multiple barcodes per item can lead to occasional errors in scanning the wrong barcode (package). Time consuming to redo everything. Solution: Whenever one or multiple item have already been scanned, we ask the user a confirmation if they scan a package barcode. opw-3610819 Forward-Port-Of: odoo/enterprise#55748 Forward-Port-Of: odoo/enterprise#54389
Backport of https://github.com/odoo/enterprise/pull/48385 Forward-Port-Of: odoo/enterprise#55718 Forward-Port-Of: odoo/enterprise#55444
Original PR description
Backport of https://github.com/odoo/enterprise/pull/48385 Forward-Port-Of: odoo/enterprise#55718 Forward-Port-Of: odoo/enterprise#55444
Before this commit, when the load is slow and the user does not wait the load method be executed and launches another search, the section, row and column ids could be altered by the both load are currently executed (the current one and the previous one whom is not yet finished). The problem with that is the section, row and column id is a global variable in the file and so the id is incremented by the both loads once a section, row or column is created and so the user could see a big gap between
Original PR description
Before this commit, when the load is slow and the user does not wait the load method be executed and launches another search, the section, row and column ids could be altered by the both load are currently executed (the current one and the previous one whom is not yet finished). The problem with that is the section, row and column id is a global variable in the file and so the id is incremented by the both loads once a section, row or column is created and so the user could see a big gap between the grid header and his first result displayed because the row id could be for instance 21 instead of 1. This commit fixes the issue by removing the global variable and define the attributes to increment for section, row and column id into `GridDataPoint` to be sure the id will only be incremented by only one load. Forward-Port-Of: odoo/enterprise#55361
When the user tries to send a conversational WhatsApp message, it fails saying that the phone number is blacklisted. Problem:- By default, the archived records are not searched in `.search()` unless `active_test` is given `False` in context. Here while searching blacklisted numbers in `_send_message`, the `False` value is obtained for `active_test` in context due to which archived blacklisted numbers are also being searched. This context is obtained from the `mail_message_post` controller.
Original PR description
When the user tries to send a conversational WhatsApp message, it fails saying that the phone number is blacklisted. Problem:- By default, the archived records are not searched in `.search()` unless `active_test` is given `False` in context. Here while searching blacklisted numbers in `_send_message`, the `False` value is obtained for `active_test` in context due to which archived blacklisted numbers are also being searched. This context is obtained from the `mail_message_post` controller. https://github.com/odoo/odoo/blob/46d94c4bdaec287615e47aac6597f36f498cf8de/addons/mail/controllers/thread.py#L96 Solution:- We will forcefully pass the `active_test` with `True` while searching blacklisted phone numbers. Due to this archived records will not be searched and it will let the user send the WhatsApp message using the discuss channel. Task - 3698511 Forward-Port-Of: odoo/enterprise#55399
When grouping by analytic plan and/or account in a report, clicking the amount always opened an empty tree view, except for the default "Projects" plan which properly displayed the analytic lines making the amount. This was due to the fact the domain was built using field account_id of account.analytic.line, which is only used for the default plan (other plans dynamically create fields on account.analytic.line to store their chosen account). auto_account_id is overridden in the model to allow
Original PR description
When grouping by analytic plan and/or account in a report, clicking the amount always opened an empty tree view, except for the default "Projects" plan which properly displayed the analytic lines making the amount. This was due to the fact the domain was built using field account_id of account.analytic.line, which is only used for the default plan (other plans dynamically create fields on account.analytic.line to store their chosen account). auto_account_id is overridden in the model to allow searching on all plans, and should hence be used in this context. Forward-Port-Of: odoo/enterprise#50893
Steps (from customer DB): - Setup automation rules that send mail - Run the rules No precise steps found, running the existing code in SA is enough too trigger an issue ``` Partner = env['res.partner'] Partner._parse_partner_name('johndoe@example.com') ``` Actual result: - Traceback due to missing attribute for partner - _parse_partner_name definition has been removed in 17.0, still exist in 16.4 Expected result: - no traceback, mail send - email is parse to name opw-369312
Original PR description
Steps (from customer DB):
- Setup automation rules that send mail
- Run the rules
No precise steps found, running the existing code in SA is enough too trigger an issue
```
Partner = env['res.partner']
Partner._parse_partner_name('johndoe@example.com')
```
Actual result:
- Traceback due to missing attribute for partner
- _parse_partner_name definition has been removed in 17.0, still exist in 16.4
Expected result:
- no traceback, mail send
- email is parse to name
opw-3693124
task-2612945
Forward-Port-Of: odoo/enterprise#54690Fix a decimal issue on reconciliation. Steps: - Set a reconciliation model with payment tolerance of 2% - Create an invoice for $1210 - Create a bank stmt with a line for $1185.80 -> Reconciliation model is not apply This is because of a decimal issue when calculating the residual balance after reconciliation, leading to the difference being 2.000000000000004% instead of 2%. opw-3672092 Forward-Port-Of: odoo/enterprise#55615
Original PR description
Fix a decimal issue on reconciliation. Steps: - Set a reconciliation model with payment tolerance of 2% - Create an invoice for $1210 - Create a bank stmt with a line for $1185.80 -> Reconciliation model is not apply This is because of a decimal issue when calculating the residual balance after reconciliation, leading to the difference being 2.000000000000004% instead of 2%. opw-3672092 Forward-Port-Of: odoo/enterprise#55615
Since odoo/odoo@f0cb56f3651da487c1f4fe34adc25e7401678703 we check rules domains. This has the side effect of making rules in data_merge fail because they may pertain models that are yet to be loaded by the ORM. Steps to reproduce: 1. Install `crm` and `data_merge` on a new DB 2. Run data merge for `crm.leads` Data Cleaning > Configuration > Deduplication Rules > Lead/Opportunity > DEDUPLICATE 3. Try to install data_merge module `./odoo-bin ... -i data_merge` We get a `ParseError`: ```
Original PR description
Since odoo/odoo@f0cb56f3651da487c1f4fe34adc25e7401678703 we check rules domains. This has the side effect of making rules in data_merge fail because they may pertain models that are yet to be loaded…
Since odoo/odoo@f0cb56f3651da487c1f4fe34adc25e7401678703 we check rules domains. This has the side effect of making rules in data_merge fail because they may pertain models that are yet to be loaded by the ORM.
Steps to reproduce:
1. Install `crm` and `data_merge` on a new DB
2. Run data merge for `crm.leads` Data Cleaning > Configuration > Deduplication Rules > Lead/Opportunity > DEDUPLICATE
3. Try to install data_merge module `./odoo-bin ... -i data_merge`
We get a `ParseError`:
```
...
File "/home/odoo/src/odoo/15.0/odoo/tools/convert.py", line 694, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/15.0/data_merge/security/security.xml:4
Invalid domain: 'crm.lead'
```
This issue happens during upgrades 14.0->15.0
The actual reason for the failure is that this line https://github.com/odoo/odoo/blob/dbd37953957b94a2e05908d96cf8e4d7dea42d72/odoo/addons/base/models/ir_rule.py#L79 eventually gets into
https://github.com/odoo/enterprise/blob/0db3d7c9473034da0714f96fe915a7dedb7b667e/data_merge/models/data_merge_record.py#L101 and this causes a `KeyError` because `crm.lead` is not loaded yet.
This error didn't happen before because at XML load there was no attempt to generate a `Query` from a domain expression. After the linked commit above we now force the parse of such queries. That involves the call to `_search_company_id` for `data_merge.record` entries.
The patch proposed here skips `ValidationError`s at install of `data_merge`. This still keeps the validation active for usual DB operations.
X-original-commit: 5a64974501b5be231e2eed941f42ae6dfe110f18
Forward-Port-Of: odoo/enterprise#55847When totals below section option is set, there is a redundancy in the display of data. Indeed, the amount will be displayed once on the line itself and once again in the total line. For now on, if the total below section is set and the total line is displayed (unfolded), the amount will only on the total line. task-3642826 Forward-Port-Of: odoo/enterprise#55619 Forward-Port-Of: odoo/enterprise#52966
Original PR description
When totals below section option is set, there is a redundancy in the display of data. Indeed, the amount will be displayed once on the line itself and once again in the total line. For now on, if the total below section is set and the total line is displayed (unfolded), the amount will only on the total line. task-3642826 Forward-Port-Of: odoo/enterprise#55619 Forward-Port-Of: odoo/enterprise#52966
Steps to Produce: - Navigate to the 'Project' form view on a mobile device. - Go to the 'Documents & Analytics' section in the 'Default Tags.' - When you try to create new tags in the 'Category' field, observe that it shows existing tags. Issue: - 'name_search' is not work for kanban view of mobile. Solution: - To resolve the issue, we need to add the missing domain to the 'facet_id' field. task-3549328 Forward-Port-Of: odoo/enterprise#55825 Forward-Port-Of: odoo/enterprise#49586
Original PR description
Steps to Produce: - Navigate to the 'Project' form view on a mobile device. - Go to the 'Documents & Analytics' section in the 'Default Tags.' - When you try to create new tags in the 'Category' field, observe that it shows existing tags. Issue: - 'name_search' is not work for kanban view of mobile. Solution: - To resolve the issue, we need to add the missing domain to the 'facet_id' field. task-3549328 Forward-Port-Of: odoo/enterprise#55825 Forward-Port-Of: odoo/enterprise#49586
This PR addresses a traceback issue in the l10n_in_reports_gstr module when attempting to match data without existing JSON. The fix includes the implementation of error handling to display a user-friendly message when JSON data is not available. Forward-Port-Of: odoo/enterprise#54007
Original PR description
This PR addresses a traceback issue in the l10n_in_reports_gstr module when attempting to match data without existing JSON. The fix includes the implementation of error handling to display a user-friendly message when JSON data is not available. Forward-Port-Of: odoo/enterprise#54007