Tuesday, June 18, 2024
25 changes · saas-17.2
Resolved issues and error corrections
The live chat bot flow has been fixed so portal users can be forwarded to an operator without the conversation failing. This improves the customer support experience by ensuring logged-in portal customers can complete automated chat handoffs reliably.
Original PR description
Before this PR, the "forward_operator" chat bot step would fail when logged in as a portal user. Indeed, this step post a message which requires reading the partner of the operator but portal users are not allowed to do so. This PR fixes the issue. opw-3987375
This change fixes an issue where some mail-related automated tests could get stuck indefinitely after an error. It improves the reliability of the testing process, helping developers detect issues faster and maintain product quality.
Original PR description
Before this PR, a test could hang indefinitely if an error occured. The flow is the following: - error occurs - the contains helper reset his internal `hasUsedContainsPositively` following the `after` callback - an error occurs if the pending contains is a negative assertion (count=0) - hoot never keeps going The `hasUsedContainsPositively` variable should not be cleaned by the contains instances. It should only be cleaned once when the test is done.
Miscellaneous changes
Steps to reproduce: - create a new db `--without-demo=True -i l10n_ar` - Load demo data Issue: Everything goes wild Cause: When we instantiate a database without demo data with l10n_ar, the res_partner(1) has the l10n_latam_identification_type_id field set to 'CUIT'. When loading demo data, a VAT number is assigned to res.partner(1)(*), which triggers a constraint error: https://github.com/odoo/odoo/blob/69e31db6ac90874ed6329599fca8f09709efd119/addons/l10n_ar/models/res_partner.py#L6
Original PR description
Steps to reproduce: - create a new db `--without-demo=True -i l10n_ar` - Load demo data Issue: Everything goes wild Cause: When we instantiate a database without demo data with l10n_ar, the…
Steps to reproduce: - create a new db `--without-demo=True -i l10n_ar` - Load demo data Issue: Everything goes wild Cause: When we instantiate a database without demo data with l10n_ar, the res_partner(1) has the l10n_latam_identification_type_id field set to 'CUIT'. When loading demo data, a VAT number is assigned to res.partner(1)(*), which triggers a constraint error: https://github.com/odoo/odoo/blob/69e31db6ac90874ed6329599fca8f09709efd119/addons/l10n_ar/models/res_partner.py#L60-L61 Since res.partner(1) has the CUIT identification type, its VAT will be checked for correctness here: https://github.com/odoo/odoo/blob/69e31db6ac90874ed6329599fca8f09709efd119/addons/l10n_ar/models/res_partner.py#L106 The dummy VAT added with this PR causes the constraint error: https://github.com/odoo/odoo/commit/a171597d1904de992bcf0e0f606b4c6a4b70b725 (*)By default (even without demo data) there is a "MyCompany" partner: https://github.com/odoo/odoo/blob/7e58f5c5ee772f2a6b4dff7ad3279dc9242ea2b3/odoo/addons/base/data/res_partner_data.xml#L4-L13 Solution: For 'main_partner' we don't set any vat number. Since some irregularities might happen, if the vat is necesarry for it, adding it to the specific module might be a better choice commit:https://github.com/odoo/odoo/commit/a171597d1904de992bcf0e0f606b4c6a4b70b725 opw-3907520 Forward-Port-Of: odoo/odoo#169305 Forward-Port-Of: odoo/odoo#167062
In commit [1], a missing semicolon breaks the neutralization of a database. This commit fixes the issue. task-3895772 [1]: https://github.com/odoo/odoo/commit/44ecef1c6a22afba3e5151fa857fe550ed5d4f8c Forward-Port-Of: odoo/odoo#169598
Original PR description
In commit [1], a missing semicolon breaks the neutralization of a database. This commit fixes the issue. task-3895772 [1]: https://github.com/odoo/odoo/commit/44ecef1c6a22afba3e5151fa857fe550ed5d4f8c Forward-Port-Of: odoo/odoo#169598
Steps to reproduce: [phonenumbers] - Create a customer from Malaysia and add a phone number '123456789' -> it will be formatted '+60 12-345 6789' - Create an invoice - Confirm - Click on Process Now Issue: There will be a warning "The Buyer’s contact phone number (BT-57) shall start with “0“ or “+”, followed by a maximum of 15 number and minimum 4 character after the “+“ or “0“ , if exist." Solution: Only keep digits and the "+" symbol note: The test has changed in order to be m
Original PR description
Steps to reproduce: [phonenumbers] - Create a customer from Malaysia and add a phone number '123456789' -> it will be formatted '+60 12-345 6789' - Create an invoice - Confirm - Click on Process Now…
Steps to reproduce: [phonenumbers] - Create a customer from Malaysia and add a phone number '123456789' -> it will be formatted '+60 12-345 6789' - Create an invoice - Confirm - Click on Process Now Issue: There will be a warning "The Buyer’s contact phone number (BT-57) shall start with “0“ or “+”, followed by a maximum of 15 number and minimum 4 character after the “+“ or “0“ , if exist." Solution: Only keep digits and the "+" symbol note: The test has changed in order to be more realistic. That is, if I have a foreign contact I will: - or use/set the correct format manually (if not, it should raise an error from the third-party api) - or install `phonenumbers` to automatically format it (if not on a saas) `phone_validation` is in 'auto_intsall' whenever `base` and `mail` are installed (and if the library `phonenumbers` is installed) and works as followed: ``` >>> import phonenumbers >>> raw_phone = '(870)-931-0505' >>> parsed_number = phonenumbers.parse(raw_phone, "US") >>> phonenumbers.format_number(parsed_number, phonenumbers.PhoneNumberFormat.INTERNATIONAL) '+1 870-931-0505' ``` opw-3912128 Forward-Port-Of: odoo/odoo#164717
step: -install l10n_it and account_peppol without demo data -setup a peppol demo account -give your company a codigo fiscal -settings > Italian Electronic Invoicing > check "Allow Odoo to process invoices" -> constraint This happens because when creating demo edi, the id_client is set as "demo{company_id}", but the id_client must be unique so when registering two edi services for the same company, there is a collision. After this PR, we avoid the collision by adding the proxy_type to t
Original PR description
step:
-install l10n_it and account_peppol without demo data -setup a peppol demo account
-give your company a codigo fiscal
-settings > Italian Electronic Invoicing > check "Allow Odoo to process invoices"
-> constraint
This happens because when creating demo edi, the id_client is set as "demo{company_id}", but the id_client must be unique so when registering two edi services for the same company, there is a collision.
After this PR, we avoid the collision by adding the proxy_type to the demo id_client.
opw-3983974
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#169385For a logged user, when applying to a job position, the phone number is filled with phone but updates mobile on submission (instead of phone field) Steps to reproduce: 1.Navigate to jobs > /jobs in the url. 2.Log as an existing user > the phone number is pre filled in the job form based on the user's phone field (can be seen in the contact view). 3.Change the phone number in the job form. 4.Apply to the job position > click on the "i'm feeling lucky" button. 5.Navigate to contact > search
Original PR description
For a logged user, when applying to a job position, the phone number is filled with phone but updates mobile on submission (instead of phone field) Steps to reproduce: 1.Navigate to jobs > /jobs in the url. 2.Log as an existing user > the phone number is pre filled in the job form based on the user's phone field (can be seen in the contact view). 3.Change the phone number in the job form. 4.Apply to the job position > click on the "i'm feeling lucky" button. 5.Navigate to contact > search for the user 6.The given phone number will overwrite the mobile field of the user view Cause: partner_mobile field was been used. Solution: use partner_phone field from hr_applicant model opw-3964062 Forward-Port-Of: odoo/odoo#168745
__Explanation of the issue:__ Creating an allocation for multiple employees create children allocations for each individual employee concerned by that allocation. However, before this commit, refusing a parent allocation would refuse the children allocation, and validating it again would still create new children regardless. This behaviour is reminescent from the draft state which was the only way to modify an allocation __Reproduce the issue:__ - Create a multiple-employee allocation - Va
Original PR description
__Explanation of the issue:__ Creating an allocation for multiple employees create children allocations for each individual employee concerned by that allocation. However, before this commit,…
__Explanation of the issue:__ Creating an allocation for multiple employees create children allocations for each individual employee concerned by that allocation. However, before this commit, refusing a parent allocation would refuse the children allocation, and validating it again would still create new children regardless. This behaviour is reminescent from the draft state which was the only way to modify an allocation __Reproduce the issue:__ - Create a multiple-employee allocation - Validate it - Refuse it - Validate it again - Refuse it again - An error should appear, saying: "Allocation request must be confirmed or validated in order to refuse it." __How the issue was fixed:__ This commit synchronizes both parent and children allocations upon the write of the parent one, which will also update the children. Additionally, validating those parent allocations will now check if children allocations are present beforehand to avoid duplicating them. task-3935358 Forward-Port-Of: odoo/odoo#165990
Issue: ------ With many departments (for example 40), in the kiosk mode, when we identify ourselves manually, we are obliged to reduce the screen size in order to access the employees. Solution: --------- Force a max height for the section with the departments. This enables the `overflow-auto` class to take effect. It is now possible to scroll along the Y axis. opw-3956359 Forward-Port-Of: odoo/odoo#169616
Original PR description
Issue: ------ With many departments (for example 40), in the kiosk mode, when we identify ourselves manually, we are obliged to reduce the screen size in order to access the employees. Solution: --------- Force a max height for the section with the departments. This enables the `overflow-auto` class to take effect. It is now possible to scroll along the Y axis. opw-3956359 Forward-Port-Of: odoo/odoo#169616
When using the action_view_opportunity for assigned partners we should be able to see the lost leads when filtering by 'Lost', but if we don't set the active_test to False for the context we won't be able to see them in this view. So since we retrieve the leads with `self.env['crm.lead'].with_context(**action_context_origin)` we need to make sure the active_test is False to get all the leads related to the partner. ## Steps to reproduce: 1. Install website_crm_partner_assign. 2. Create at
Original PR description
When using the action_view_opportunity for assigned partners we should be able to see the lost leads when filtering by 'Lost', but if we don't set the active_test to False for the context we won't be able to see them in this view. So since we retrieve the leads with `self.env['crm.lead'].with_context(**action_context_origin)` we need to make sure the active_test is False to get all the leads related to the partner. ## Steps to reproduce: 1. Install website_crm_partner_assign. 2. Create at least 2 leads (one active and one lost) for a new partner. 3. Make sure we have set this partner as assigned partner. 4. Now on the partner form go to the leads action to see the leads related to the partner. opw-3903070 Forward-Port-Of: odoo/odoo#166832
The main goal of this PR is to ensure that the `X` button or `Esc` shortcut (Dismiss feature) of the confirmation dialog is allowed to have a different behavior than the `Cancel` button. At present, it performs the same action as the `Cancel` button but there might be cases when the dialog does not have a `Cancel` button and we still want to handle the dialog dismiss action. To enable this, this PR adds an optional callback for `dismiss` operation to the dialogData.dismiss that will
Original PR description
The main goal of this PR is to ensure that the `X` button or `Esc` shortcut (Dismiss feature) of the confirmation dialog is allowed to have a different behavior than the `Cancel` button. At present,…
The main goal of this PR is to ensure that the `X` button or `Esc` shortcut (Dismiss feature) of the confirmation dialog is allowed to have a different behavior than the `Cancel` button. At present, it performs the same action as the `Cancel` button but there might be cases when the dialog does not have a `Cancel` button and we still want to handle the dialog dismiss action. To enable this, this PR adds an optional callback for `dismiss` operation to the dialogData.dismiss that will only be executed when a dialog is closed via of the `X` button or the `Escape` shortcut. Otherwise, it will execute the callback for `cancel` operation, if any. This PR also adds/modifies some tests in `confirmation_dialog_tests.js` and `list_view_tests.js` to ensure that this new feature works as intended. **Example Use Case:** - Go to list view or kanban view. - Select the document to preview in the inspector. - Clear the input value of a required field (here, Name or Workspace), and click out or press 'Enter'. - Dismiss the alert dialog via the "X" button or the "Esc" shortcut. **Issue:** An alert dialog indicating a validation error is shown when a field value is cleared. Yet, on closing the dialog, the unnamed document is saved as is. Instead, the changes should be reverted. **Cause:** The dismiss operation is never handled in case of alert dialog for invalid selection. Hence, by default, it applies the changes made to the field. **Fix:** The alert dialog for invalid selection is different from the ones which are simply used to display warnings or alert messages because they do not need to perform any action upon dismissing the dialog. In this case, we want to prevent any invalid changes from being applied. It is achieved by calling the `leaveEditMode` method which discards them and switches the config mode. Hence, we do something similar to what is done on the click of `OK` button, on dismissing the dialog as well. This behavior is introduced because even if the user discards the dialog, any change that is not valid should not be applied. Task: [3799280](https://www.odoo.com/web#id=3799280&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#169129 Forward-Port-Of: odoo/odoo#166103
In this PR fixes the following issue ---------------------------------------------------------- - The pull request addresses a mobile view issue where the context 'show_project_update' is False so the showProjectUpdate method will not be called and the missing record error will not appear. - As part of this pull request, the visible property will be set for the x and y so that the scroll bar will appear at the bottom when fever records are displayed. task-3681318 Forward-Port-Of
Original PR description
In this PR fixes the following issue ---------------------------------------------------------- - The pull request addresses a mobile view issue where the context 'show_project_update' is False so the showProjectUpdate method will not be called and the missing record error will not appear. - As part of this pull request, the visible property will be set for the x and y so that the scroll bar will appear at the bottom when fever records are displayed. task-3681318 Forward-Port-Of: odoo/odoo#151377
This fixes a bug introduced in 96638eb, where lines with discount apply it twice. Backport of https://github.com/odoo/odoo/pull/168212 cc @robinengels --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168819
Original PR description
This fixes a bug introduced in 96638eb, where lines with discount apply it twice. Backport of https://github.com/odoo/odoo/pull/168212 cc @robinengels --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168819
Versions -------- - 16.0+ Steps ----- 1. Enable lock SO on confirmation; 2. enable wire transfer as payment provider' 3. go to website; 4. buy a product using wire transfer; 5. confirm the generated SO in the back-end; 6. front-end says payment has been confirmed. Issue ----- The confirmation status of the SO doesn't reflect the confirmation status of the payment. Cause ----- The `action_lock` method looks at any relevant wire transfers that are pending, and confirms them.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable lock SO on confirmation; 2. enable wire transfer as payment provider' 3. go to website; 4. buy a product using wire transfer; 5. confirm the generated SO in the back-end; 6. front-end says payment has been confirmed. Issue ----- The confirmation status of the SO doesn't reflect the confirmation status of the payment. Cause ----- The `action_lock` method looks at any relevant wire transfers that are pending, and confirms them. Solution -------- Decouple wire transfer confirmation from the locking of sale orders. opw-3751481 Forward-Port-Of: odoo/odoo#169369 Forward-Port-Of: odoo/odoo#169135
Currently people wanting to use a bank journal for their credit card transactions have to use a hack to set the default account as a credit card account, since the domain does not allow this. To make the life of people easier, we now allow selecting a credit card account on bank journals. [task-3891250](https://www.odoo.com/web#id=3891250&model=project.task) Forward-Port-Of: odoo/odoo#167188 Forward-Port-Of: odoo/odoo#163947
Original PR description
Currently people wanting to use a bank journal for their credit card transactions have to use a hack to set the default account as a credit card account, since the domain does not allow this. To make the life of people easier, we now allow selecting a credit card account on bank journals. [task-3891250](https://www.odoo.com/web#id=3891250&model=project.task) Forward-Port-Of: odoo/odoo#167188 Forward-Port-Of: odoo/odoo#163947
This is a follow-up of [1]. The ability to duplicate from the list view appeared with version 17.0 and was not taken into account during the forward-port. [1]: https://github.com/odoo/odoo/commit/1688a19266809d23f525563dbbb20175cbd8da83 Forward-Port-Of: odoo/odoo#167031
Original PR description
This is a follow-up of [1]. The ability to duplicate from the list view appeared with version 17.0 and was not taken into account during the forward-port. [1]: https://github.com/odoo/odoo/commit/1688a19266809d23f525563dbbb20175cbd8da83 Forward-Port-Of: odoo/odoo#167031
Steps : * Create a loyalty program of any type * Create 2 or more rewards * Create a sale order and use the loyalty program and reward we just created * Go back to the loyalty program and try to delete that reward Issue : The record cannot be deleted as another model requires the record being deleted Fix : Changed the unlink method to delete the record if this record id is not required by another model and archive the record if it is required opw : 3879031 --- I confirm I hav
Original PR description
Steps : * Create a loyalty program of any type * Create 2 or more rewards * Create a sale order and use the loyalty program and reward we just created * Go back to the loyalty program and try to delete that reward Issue : The record cannot be deleted as another model requires the record being deleted Fix : Changed the unlink method to delete the record if this record id is not required by another model and archive the record if it is required opw : 3879031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164293
Issue ---- When uploading a file, the chatter is unmounted from the right side of the screen then remounted to the bottom as soon as the file is uploaded to preview. For multiple files, the `onUploaded` hook is called before the re-mounted chatter root element becomes accessible to the component. This results in dereferencing `null` in `onUploaded`. Steps ----- - Create a new bill. - Upload multiple attachments. Make sure that: - There are no attachments when you upload. - The
Original PR description
Issue ---- When uploading a file, the chatter is unmounted from the right side of the screen then remounted to the bottom as soon as the file is uploaded to preview. For multiple files, the `onUploaded` hook is called before the re-mounted chatter root element becomes accessible to the component. This results in dereferencing `null` in `onUploaded`. Steps ----- - Create a new bill. - Upload multiple attachments. Make sure that: - There are no attachments when you upload. - The attachments are large enough so the second attachment is uploaded just after the first is previewed (and the chatter is unmounted from the right). opw-3985584 Forward-Port-Of: odoo/odoo#169095
Before this commit: - the tooltip is mismatched to the conditions of service_tracking_type. After this commit: - fixes the tooltip of the product in `task_in_project` and `project_only` fields. ref PR: https://github.com/odoo/odoo/pull/103974 task-3964655 Forward-Port-Of: odoo/odoo#167830
Original PR description
Before this commit: - the tooltip is mismatched to the conditions of service_tracking_type. After this commit: - fixes the tooltip of the product in `task_in_project` and `project_only` fields. ref PR: https://github.com/odoo/odoo/pull/103974 task-3964655 Forward-Port-Of: odoo/odoo#167830
**Steps to reproduce:** - Install Point of Sale module - Create an order through the PoS day and time X - Re-print the receipt/ticket another day **Current behavior before PR:** When reprint an order's receipt in a day different than the order creation date you will have the current date at the end of the receipt. This is happening because when exporting the data of the order to print the receipt we are setting the date to be printed equals to the receipt date which is the current time
Original PR description
**Steps to reproduce:** - Install Point of Sale module - Create an order through the PoS day and time X - Re-print the receipt/ticket another day **Current behavior before PR:** When reprint an order's receipt in a day different than the order creation date you will have the current date at the end of the receipt. This is happening because when exporting the data of the order to print the receipt we are setting the date to be printed equals to the receipt date which is the current time. https://github.com/odoo/odoo/blob/17.0/addons/point_of_sale/static/src/app/store/models.js#L1610 https://github.com/odoo/odoo/blob/17.0/addons/point_of_sale/static/src/app/store/models.js#L1625 **Desired behavior after PR is merged:** We are now passing the order date instead of the receipt date. opw-3979454 Forward-Port-Of: odoo/odoo#169265
This error occurs when we create a new sales order, then proceed to create an invoice within that sales order, and finally attempt to open the ``Accrued Revenue Entry`` from the action button. Steps to reproduce: - Install the ``sale_management`` and ``account_accountant`` modules - Create new sales orders > ``Confirm`` > ``Create Invoice`` button > Down Payment in % > ``Confirm`` > ``Sale Order`` smart button - Go to action button > ``Accrued Revenue Entry`` Traceback : ``Asse
Original PR description
This error occurs when we create a new sales order, then proceed to create an invoice within that sales order, and finally attempt to open the ``Accrued Revenue Entry`` from the action button. Steps…
This error occurs when we create a new sales order, then proceed to create an invoice within that sales order, and finally attempt to open the ``Accrued Revenue Entry`` from the action button. Steps to reproduce: - Install the ``sale_management`` and ``account_accountant`` modules - Create new sales orders > ``Confirm`` > ``Create Invoice`` button > Down Payment in % > ``Confirm`` > ``Sale Order`` smart button - Go to action button > ``Accrued Revenue Entry`` Traceback : ``AssertionError precision_rounding must be positive, got 0.0`` At [1] within ``o.order_line``, we are encountering an issue where ``precision_rounding`` is being retrieved as zero. This is leading to an error. This commit will fix the above error by implementing a check for the ``is_downpayment`` in the order line. [1]: https://github.com/odoo/odoo/blob/34b651de35b986db404a3950866bed7bc7e1fae2/addons/account/wizard/accrued_orders.py#L174 sentry-4857910663 Forward-Port-Of: odoo/odoo#165014
Some part of the `action_send_chat_request` method has been wrongly indented in [1]. As a result, this block is executed as part of a loop while it should not. This PR put the block of code out of the loop. [1]: https://github.com/odoo/odoo/pull/129770 Forward-Port-Of: odoo/odoo#169454 Forward-Port-Of: odoo/odoo#169379
Original PR description
Some part of the `action_send_chat_request` method has been wrongly indented in [1]. As a result, this block is executed as part of a loop while it should not. This PR put the block of code out of the loop. [1]: https://github.com/odoo/odoo/pull/129770 Forward-Port-Of: odoo/odoo#169454 Forward-Port-Of: odoo/odoo#169379
When leaving the table mode, the filter should be removed to show all products again. taskId: 3989229 Forward-Port-Of: odoo/odoo#169642 Forward-Port-Of: odoo/odoo#169416
Original PR description
When leaving the table mode, the filter should be removed to show all products again. taskId: 3989229 Forward-Port-Of: odoo/odoo#169642 Forward-Port-Of: odoo/odoo#169416
When scanning a barcode, the search should return only one partner if the barcode is an exact match. This is the case for example when scanning a membership card. taskId: 3987605 Forward-Port-Of: odoo/odoo#169695 Forward-Port-Of: odoo/odoo#169603
Original PR description
When scanning a barcode, the search should return only one partner if the barcode is an exact match. This is the case for example when scanning a membership card. taskId: 3987605 Forward-Port-Of: odoo/odoo#169695 Forward-Port-Of: odoo/odoo#169603
Steps to reproduce: - install point of sale and HR - create some data in the point of sale app - switch the user language to arabic - open the point of sale dashboard => some cells are in error, the date cannot be recognised. The reason is that `formatDateTime` returns the date with arabic numbers, which can't be parsed by the spreadsheet engine. The option `numberingSystem` is ignored by `formatDateTime`. With this commit, we change the date numbering system before. opw-3992621
Original PR description
Steps to reproduce: - install point of sale and HR - create some data in the point of sale app - switch the user language to arabic - open the point of sale dashboard => some cells are in error, the date cannot be recognised. The reason is that `formatDateTime` returns the date with arabic numbers, which can't be parsed by the spreadsheet engine. The option `numberingSystem` is ignored by `formatDateTime`. With this commit, we change the date numbering system before. opw-3992621 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169627