Tuesday, June 18, 2024
25 changes · 17.0
Resolved issues and error corrections
The livechat button now automatically moves upward when visitors reach the bottom of a website page, restoring behavior that was lost after a previous redesign. This helps mobile users access footer links without the chat icon covering them, while keeping manual drag-and-drop positioning respected until the page state refreshes.
Original PR description
Previously, the floating icon wasn't an OWL component and has been refactored into an OWL component. When refactored he lost the auto move up top logic that came with the css classes…
Previously, the floating icon wasn't an OWL component and has been refactored into an OWL component. When refactored he lost the auto move up top logic that came with the css classes 'o_bottom_fixed_element' and 'o_bottom_fixed_element_move_up' This commit reintroduce this auto move up behavior by default within the OWL component by listening to the scroll event of the document and identifying whenever we reach the end of the document. It is useful so we ensure the users can click all links potentially present in the footer. If the icon is dragged and moved elsewhere, we prevent this smart behavior from happening until next refresh of the state. Commit introducing the drag & drop feature : https://github.com/odoo/odoo/commit/d9f07235484 Commit of the OWL refactoring : https://github.com/odoo/odoo/commit/20c1772d Steps to reproduce : - Install LiveChat - Toggle Mobile display - Scroll down to the bottom of page -> The livechat floating icon doesn't go up as it was before task-3946855 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where creating a credit note could remove the down payment reference from the related sales order line. Businesses can now keep clearer sales order records and avoid confusion when reviewing down payments and refunds.
Original PR description
Credit notes shoudn't make the down payment reference disappear from the matching down payment SO line. opw-3904918 See #168418 for further details
The payment screen now shows the correct logos for 7-Eleven, Cashalo, and Cebuana. This makes these payment options easier for customers to recognize and improves the checkout experience.
Original PR description
This commit adds 3 missing payment method logos: 7eleven, Cashalo and Cebuana. task-3994673 | Before | After | |--------|--------| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mobile self-ordering and kiosk setup now includes a setting to prevent users from creating new languages in that flow. This avoids an error that could interrupt customer ordering and helps keep the experience stable.
Original PR description
Add an option to restrict users from creating language on mobile self-order & kiosk mode. task - 3980908
When logged-in applicants update their phone number while applying for a job, the change now updates the correct phone field instead of overwriting their mobile number. This prevents contact records from being unintentionally changed in the wrong place and keeps applicant information accurate.
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
The attendance kiosk’s manual employee selection screen now handles long department lists without forcing users to resize the browser. Departments can scroll vertically, making it easier to reach employees when many departments are configured.
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
Updated timezone references in payment processing tests to use modern timezone names that are compatible with current Ubuntu systems. The system was using outdated timezone identifiers like "US/Pacific" which are no longer available, and these have been replaced with their current equivalents like "America/Los_Angeles" to ensure tests run reliably.
Original PR description
In ubuntu noble, some timezone where removed, like US/Pacific. Translate it to the equivalent: "America/Los_Angeles" runbot-67857 Forward-Port-Of: odoo/enterprise#64369
Code cleanup and technical improvements
The Peru tax authority's electronic invoicing provider has officially changed its name from Digiflow to Estela. This update changes all references to the provider name throughout the system while keeping all workflows and functionality exactly the same. This ensures the system accurately reflects the current provider name for Peruvian users.
Original PR description
Our OSE in Peru changed name from Digiflow to Estela, this commit is to change the name in all the code. All workflows remain unchanged. Variables were not modified.
Miscellaneous changes
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
In 92ed88a770893f57dcceff99d9239f130aa6112d, we added a fix and tests on hr.expense & hr.expense.sheet state fields. This commit forward ports these tests as they are interesting to keep in later versions. 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#164909
Original PR description
In 92ed88a770893f57dcceff99d9239f130aa6112d, we added a fix and tests on hr.expense & hr.expense.sheet state fields. This commit forward ports these tests as they are interesting to keep in later versions. 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#164909
**Steps to reproduce:** - Install sale_project, E-Commerce module - Create a service product and put its invoicing policy as 'Based on milestones' - Go to website as Public user and try to add the product you created to the cart **Current behavior before PR:** A traceback is happening when a public user try to add a product -that has Based on milestones as invoicing policy- to the cart. This is happening because we check if the user has 'group_project_milestone' https://github.com/odoo
Original PR description
**Steps to reproduce:** - Install sale_project, E-Commerce module - Create a service product and put its invoicing policy as 'Based on milestones' - Go to website as Public user and try to add the product you created to the cart **Current behavior before PR:** A traceback is happening when a public user try to add a product -that has Based on milestones as invoicing policy- to the cart. This is happening because we check if the user has 'group_project_milestone' https://github.com/odoo/odoo/blob/17.0/addons/sale_project/models/product.py#L18 and if the user is not signed in he won't have this group. **Desired behavior after PR is merged:** The public user should be able to add this products. As we are now checking if the user is a public one and if the SUPERUSER has the 'group_project_milestone'. opw-3956165 Forward-Port-Of: odoo/odoo#167810
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
In Point of Sale > Configuration > Settings enable 'Global Discounts' Create a tax [TAX A] included in price Create a tax [TAX G] as group of taxes, including only [TAX A] Configure a product [PROD] with [TAX G] Open POS session Add [PROD], hit 'Discount' button, add 50% discount Issue: Tax will not be included in the discount This occurs because the system does not take into account the tax group opw-3576452 Forward-Port-Of: odoo/odoo#169047 Forward-Port-Of: odoo/odoo#146337
Original PR description
In Point of Sale > Configuration > Settings enable 'Global Discounts' Create a tax [TAX A] included in price Create a tax [TAX G] as group of taxes, including only [TAX A] Configure a product [PROD] with [TAX G] Open POS session Add [PROD], hit 'Discount' button, add 50% discount Issue: Tax will not be included in the discount This occurs because the system does not take into account the tax group opw-3576452 Forward-Port-Of: odoo/odoo#169047 Forward-Port-Of: odoo/odoo#146337
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
This commit is a followup [1], where we (tried to) clear changes on x2many fields once the record was saved. However, due to a typo, it only worked on existing records (when saving), not when creating new records. This commit fixes the issue. [1] https://github.com/odoo/odoo/pull/123274 Closes https://github.com/odoo/odoo/pull/157673 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have s
Original PR description
This commit is a followup [1], where we (tried to) clear changes on x2many fields once the record was saved. However, due to a typo, it only worked on existing records (when saving), not when creating new records. This commit fixes the issue. [1] https://github.com/odoo/odoo/pull/123274 Closes https://github.com/odoo/odoo/pull/157673 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#169777 Forward-Port-Of: odoo/odoo#169641
**Steps to reproduce:** - Install Sale and Project modules - Create a project with 1 or 2 stages - Create more than 1 task in this project - Assign those tasks to a Sale order - Go to this sale order and click on tasks smart button **Current behavior before PR:** When clicking on the task smart button in a sale order you will see lots of stages that are not associated with the shown tasks' project. This is happening because the value assigned to default_project_id in the context is
Original PR description
**Steps to reproduce:** - Install Sale and Project modules - Create a project with 1 or 2 stages - Create more than 1 task in this project - Assign those tasks to a Sale order - Go to this sale order and click on tasks smart button **Current behavior before PR:** When clicking on the task smart button in a sale order you will see lots of stages that are not associated with the shown tasks' project. This is happening because the value assigned to default_project_id in the context is False. https://github.com/odoo/odoo/blob/saas-16.4/addons/sale_project/models/sale_order.py#L166 **Desired behavior after PR is merged:** We are now just showing the stages associated with the shown tasks' project by assigning those tasks' project id to the default_project_id value in context. opw-3929012 Forward-Port-Of: odoo/odoo#168035
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
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#169385This is a missing test for odoo/odoo#165753. It also checks the first condition from the `_get_default_dest_location` method, since the test for it was also missing. 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#168172 Forward-Port-Of: odoo/odoo#167955
Original PR description
This is a missing test for odoo/odoo#165753. It also checks the first condition from the `_get_default_dest_location` method, since the test for it was also missing. 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#168172 Forward-Port-Of: odoo/odoo#167955
The "Reload Chart Template" button currently doesn't work with the argentinian localization. It is due to some python constrains that don't allow to modify some fields if there are accounting entries. The issue is that the constrains will be raised, when any writing on those fields is done, even if the new value is the same as the old one. When reloading the chart template it is re-writing the values, but they are not different, so no exception should be raised. The fix here is
Original PR description
The "Reload Chart Template" button currently doesn't work with the argentinian localization. It is due to some python constrains that don't allow to modify some fields if there are accounting entries. The issue is that the constrains will be raised, when any writing on those fields is done, even if the new value is the same as the old one. When reloading the chart template it is re-writing the values, but they are not different, so no exception should be raised. The fix here is to move those constrains into the `def write` override, where there's more control (as we have the new values as argument). task-3878511 Forward-Port-Of: odoo/odoo#166537
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
**Current behavior:** Switching from manual to automated valuation on a product that has a negative quantity will create entries in the valuation journal with incorrect debit/credit figures. **Expected behavior:** The lines generated in this manner should look like ones created when the valuation is generated for a product that was already valuated with the automated option. **Steps to reproduce:** 1. Create a product category with the default manual valuation method, create a storable
Original PR description
**Current behavior:** Switching from manual to automated valuation on a product that has a negative quantity will create entries in the valuation journal with incorrect debit/credit figures.…
**Current behavior:**
Switching from manual to automated valuation on a product that has a negative quantity will create entries in the valuation journal with incorrect debit/credit figures.
**Expected behavior:**
The lines generated in this manner should look like ones created when the valuation is generated for a product that was already valuated with the automated option.
**Steps to reproduce:**
1. Create a product category with the default manual valuation method, create a storable product that belongs to it
2. Sell some quantity of the new product without adding any on-hand quantity (so that the qty is negative), confirm the order and generate the invoice
3. Swap to automated valuation in the product category that was created in step 1
4. In the entries for the stock valuation journal, observe that:
A) the stock valuation account is getting *debited* instead of credited, and
B) the other entry generated is for the stock input account
instead of stock output, and
C) the debit/credit amounts should be swapped here as well
**Cause of the issue:**
The negative quantity case is not considered when we do the empty/replenish sequence on valuation method change.
**Fix:**
Add an explicit check for negative quantity in the replenish step of changing valuation method.
opw-3810779
Forward-Port-Of: odoo/odoo#168813
Forward-Port-Of: odoo/odoo#165179Before 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
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