Wednesday, August 14, 2024
20 changes · saas-17.1
Miscellaneous changes
Problem --------- Currently, when reversing a move, the current company is used as recipient bank. 1. Set a bank on a partner A 2. Go to Accounting 3. Set A as the customer of the invoice 4. Set a bank under 'recipient bank' in Other Info tab 5. Post the invoice 6. "Add Credit Note" 7. Fill in with wathever and press Reverse -> The Other Info tab of the reverse move has the company bank and not the customer's Objective --------- Obtain a similar behavior as when a credit note is
Original PR description
Problem --------- Currently, when reversing a move, the current company is used as recipient bank. 1. Set a bank on a partner A 2. Go to Accounting 3. Set A as the customer of the invoice 4. Set a bank under 'recipient bank' in Other Info tab 5. Post the invoice 6. "Add Credit Note" 7. Fill in with wathever and press Reverse -> The Other Info tab of the reverse move has the company bank and not the customer's Objective --------- Obtain a similar behavior as when a credit note is created directly: have the customer's bank set as recipient bank. Solution --------- Provide a default bank id that is set, if possible, to one of the customer's bank. opw-4035448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173640
Steps to reproduce: - Create a product - Update its quantity and set 4 in Stock - Create two MO that consume each 2 units of that product with the same scheduled date - Create a scrap order with 1 quantity of that product and validate it Issue: The unreserve will be done on the first MO. When going through the candidate move lines in the `_free_reservation()`, we sort them depending on their picking, their date if they have a move, or their id if they don't. The issue is that when
Original PR description
Steps to reproduce: - Create a product - Update its quantity and set 4 in Stock - Create two MO that consume each 2 units of that product with the same scheduled date - Create a scrap order with 1 quantity of that product and validate it Issue: The unreserve will be done on the first MO. When going through the candidate move lines in the `_free_reservation()`, we sort them depending on their picking, their date if they have a move, or their id if they don't. The issue is that when their related move have an equal date, then the order becomes underministic. Now, always sort by their id as a last resort, so we have a consistent order no matter what. opw-4046240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176399 Forward-Port-Of: odoo/odoo#174442
In versions v17 and up, a div with class `.o-discuss-CallInvitations` was causing issues by blocking the scrollbar's up arrow, preventing users from scrolling up. To address this, the display of the `.o-discuss-CallInvitations` div is now conditional, based on `store.discuss.ringingThreads.length > 0`. This ensures the div only appears when necessary, avoiding obstruction of the scrollbar and improving usability. opw-4108057 Forward-Port-Of: odoo/odoo#176608
Original PR description
In versions v17 and up, a div with class `.o-discuss-CallInvitations` was causing issues by blocking the scrollbar's up arrow, preventing users from scrolling up. To address this, the display of the `.o-discuss-CallInvitations` div is now conditional, based on `store.discuss.ringingThreads.length > 0`. This ensures the div only appears when necessary, avoiding obstruction of the scrollbar and improving usability. opw-4108057 Forward-Port-Of: odoo/odoo#176608
Steps to reproduce ================== - Edit a kanban view so that the default_group_by is a date field - Go to that view - Open studio => Granularity not set on a date(time) field Cause of the issue ================== `web_read_group` is called with a limit of 1 First a call to `read_group` is made Then in order to return the total number of groups when the limit is reached, a call to _read_group is made. Inside `read_group`, there is a compatibility layer that notably
Original PR description
Steps to reproduce ================== - Edit a kanban view so that the default_group_by is a date field - Go to that view - Open studio => Granularity not set on a date(time) field Cause of the issue ================== `web_read_group` is called with a limit of 1 First a call to `read_group` is made Then in order to return the total number of groups when the limit is reached, a call to _read_group is made. Inside `read_group`, there is a compatibility layer that notably add a default month granularity to date(time) fields. This isn't the case inside `_read_group`, which causes a crash Solution ======== Extract the compatibility layer related to the groupby from `read_group` and use that for both methods opw-4051657 Forward-Port-Of: odoo/odoo#174396
Commit 775c113382231 change the variable name from `i` to `picking` but the fw-port 9a3b2940da55f keeps the old name. Resulting on the access token is never found. 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#176560
Original PR description
Commit 775c113382231 change the variable name from `i` to `picking` but the fw-port 9a3b2940da55f keeps the old name. Resulting on the access token is never found. 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#176560
1) Start creating a tax 2) Set the 'Tax Computation' to 'Group of taxes' 3) In 'Definition' tab, select 'Add a line', choose to create a new tax 4) Jumpt to 2 Issue: Nested group of taxes are not allowed When adding the child tax users cannot choose group of taxes, but we can't block creation of just a specific type of taxes so we need to check the type afterward opw-4060955 Forward-Port-Of: odoo/odoo#176359 Forward-Port-Of: odoo/odoo#173889
Original PR description
1) Start creating a tax 2) Set the 'Tax Computation' to 'Group of taxes' 3) In 'Definition' tab, select 'Add a line', choose to create a new tax 4) Jumpt to 2 Issue: Nested group of taxes are not allowed When adding the child tax users cannot choose group of taxes, but we can't block creation of just a specific type of taxes so we need to check the type afterward opw-4060955 Forward-Port-Of: odoo/odoo#176359 Forward-Port-Of: odoo/odoo#173889
VAT validations for Costa Rica identification types according to: - CÉDULA FÍSICA: 9 digits - CÉDULA JURÍDICA: 10 digits - CÉDULA DIMEX: 11 or 12 digits - CÉDULA NITE: 10 digits Legal information is on [page 4](https://atv.hacienda.go.cr/ATV/ComprobanteElectronico/docs/esquemas/2016/v4/ANEXOS%20Y%20ESTRUCTURAS.pdf). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163923
Original PR description
VAT validations for Costa Rica identification types according to: - CÉDULA FÍSICA: 9 digits - CÉDULA JURÍDICA: 10 digits - CÉDULA DIMEX: 11 or 12 digits - CÉDULA NITE: 10 digits Legal information is on [page 4](https://atv.hacienda.go.cr/ATV/ComprobanteElectronico/docs/esquemas/2016/v4/ANEXOS%20Y%20ESTRUCTURAS.pdf). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163923
Adding a condition in _get_stock_account_property_field_names to avoid recomputing the property_stock_account_production_cost_id value. task-id: 3646156 enterprise: https://github.com/odoo/enterprise/pull/65904/ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171616
Original PR description
Adding a condition in _get_stock_account_property_field_names to avoid recomputing the property_stock_account_production_cost_id value. task-id: 3646156 enterprise: https://github.com/odoo/enterprise/pull/65904/ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171616
Specification: when creating a widget percentpie with Studio, the field's name has been added after percent pie, which is not user-friendly.  Expected behavior: The duplicate label should not be visible. Task-3942207 Forward-Port-Of: odoo/odoo#172046
Original PR description
Specification: when creating a widget percentpie with Studio, the field's name has been added after percent pie, which is not user-friendly.  Expected behavior: The duplicate label should not be visible. Task-3942207 Forward-Port-Of: odoo/odoo#172046
Before this commit: Invoices reconciled with a single payment appeared in a random order on the Payment Receipt. This was caused by the use of a set, which does not preserve the order of invoices. After this commit: Invoices are displayed in the order defined by the account.move model, ensuring a consistent and logical sequence. Steps to reproduce: - Create four invoices for the same customer on different dates. - Register a customer payment covering the total amount of the four invoic
Original PR description
Before this commit: Invoices reconciled with a single payment appeared in a random order on the Payment Receipt. This was caused by the use of a set, which does not preserve the order of invoices. After this commit: Invoices are displayed in the order defined by the account.move model, ensuring a consistent and logical sequence. Steps to reproduce: - Create four invoices for the same customer on different dates. - Register a customer payment covering the total amount of the four invoices. - Reconcile the payment with the invoices. - Print the Payment Receipt for the payment. opw-4096451 Forward-Port-Of: odoo/odoo#176536 Forward-Port-Of: odoo/odoo#176313
**Behaviour before PR:** When we try to add a link on an image through dialog box, image gets hidden and url is added as a link label instead. **Behaviour after PR:** Now, link can be added to the image without vanishing the image. task-4049730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176358 Forward-Port-Of: odoo/odoo#174211
Original PR description
**Behaviour before PR:** When we try to add a link on an image through dialog box, image gets hidden and url is added as a link label instead. **Behaviour after PR:** Now, link can be added to the image without vanishing the image. task-4049730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176358 Forward-Port-Of: odoo/odoo#174211
steps: - be connected as someone with no accrual - give accrual allocation to an employee - go to his time offs using the smart button on his employee profile -> no settings to set the date, has_accrual_allocation is false because our user's employee doesn't have accrual allocation expected -> see the date picker on the leave dashboard if the employee has accrual allocations, not the connected user Forward-Port-Of: odoo/odoo#175686
Original PR description
steps: - be connected as someone with no accrual - give accrual allocation to an employee - go to his time offs using the smart button on his employee profile -> no settings to set the date, has_accrual_allocation is false because our user's employee doesn't have accrual allocation expected -> see the date picker on the leave dashboard if the employee has accrual allocations, not the connected user Forward-Port-Of: odoo/odoo#175686
Combining purchase order line and product supplier info for orders with multiple pages results in inconsistent behavior: - products on first page shows the internal references and names - subsequent pages shows the supplier's codes and names. It is better to display the internals for the product field and keep the supplier codes and names for the description field. Therefore, the search has also been fixed accordingly. task: 4040598 (see also 3893787) see also https://github.com/odoo/
Original PR description
Combining purchase order line and product supplier info for orders with multiple pages results in inconsistent behavior: - products on first page shows the internal references and names - subsequent pages shows the supplier's codes and names. It is better to display the internals for the product field and keep the supplier codes and names for the description field. Therefore, the search has also been fixed accordingly. task: 4040598 (see also 3893787) see also https://github.com/odoo/odoo/pull/113527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175067
task-4104252 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#176493
Original PR description
task-4104252 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#176493
Problem: When the user duplicates a rental order from a list view in the rental app, the order lines of the rental order were not getting computed to True for field is_rental during compute_is_rental. The compute method was checking if the 'in_rental_app' was passed into the line's context, which is not the case during the duplication. Solution: If a line has rentable products and it is from a rental order, then the line should be considered is_rental, rather than basing it on the context of
Original PR description
Problem: When the user duplicates a rental order from a list view in the rental app, the order lines of the rental order were not getting computed to True for field is_rental during compute_is_rental. The compute method was checking if the 'in_rental_app' was passed into the line's context, which is not the case during the duplication. Solution: If a line has rentable products and it is from a rental order, then the line should be considered is_rental, rather than basing it on the context of the method being called from the Rental app. Steps to Reproduce on Runbot: 1. Install Rental app 2. View the rental orders in list view 3. Select a rental order with a status and duplicate 4. Observe that duped rental order has no rental_status when you confirm it opw-4055493 Forward-Port-Of: odoo/enterprise#67670
[FIX] l10n_in_asset: fix check_depreciation func dependencies `_check_depreciations` function is only called at creation and not afterwards We need to have it raised afterwards too task-id#3909619 Forward-Port-Of: odoo/enterprise#68374
Original PR description
[FIX] l10n_in_asset: fix check_depreciation func dependencies `_check_depreciations` function is only called at creation and not afterwards We need to have it raised afterwards too task-id#3909619 Forward-Port-Of: odoo/enterprise#68374
The PR hides the M2O external button in the "Add to Dashboard" dialog by passing the 'no_open' option to the widget. Task: [4066519](https://www.odoo.com/odoo/project/2328/tasks/4066519?cids=2) Forward-Port-Of: odoo/enterprise#67804
Original PR description
The PR hides the M2O external button in the "Add to Dashboard" dialog by passing the 'no_open' option to the widget. Task: [4066519](https://www.odoo.com/odoo/project/2328/tasks/4066519?cids=2) Forward-Port-Of: odoo/enterprise#67804
Part of a UI task. Changed CONTINUE/PAUSE to CONTINUE/START Regenerated the PDF file task-id: 3646156 community: https://github.com/odoo/odoo/pull/171616 Forward-Port-Of: odoo/enterprise#65904
Original PR description
Part of a UI task. Changed CONTINUE/PAUSE to CONTINUE/START Regenerated the PDF file task-id: 3646156 community: https://github.com/odoo/odoo/pull/171616 Forward-Port-Of: odoo/enterprise#65904
The Ecuadorian law requires the unit price on the XML invoice and on the PDF to be the same, this is currently not the case with taxes included in the price. ### Steps to reproduce: - Install the 'l10n_ec' module and switch to an Ecuadorian company - Change the 'IVA 15% (411, Servicios)' Tax to be included - In Accounting create a new Customer Invoice - Select 'Instituto Ecuatoriano' as Customer - Add a line with the included tax set before - Select 'Sin utilization del sistema financie
Original PR description
The Ecuadorian law requires the unit price on the XML invoice and on the PDF to be the same, this is currently not the case with taxes included in the price. ### Steps to reproduce: - Install the 'l10n_ec' module and switch to an Ecuadorian company - Change the 'IVA 15% (411, Servicios)' Tax to be included - In Accounting create a new Customer Invoice - Select 'Instituto Ecuatoriano' as Customer - Add a line with the included tax set before - Select 'Sin utilization del sistema financiero' as Payment Method - Confirm - On the blue popup at the top of the page, click 'process now' to get the XML in the chatter - Click preview to get the PDF - The unit prices are not the same ### Cause: Usually on the PDF the unit price with included taxes is displayed. ### Solution: Create a xpath to compute the unit price in the same way as the XML. opw-4078177 Forward-Port-Of: odoo/enterprise#67721
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive the MTO Route - With CO1 create a route with a buy action and destination CO1/stock - With CO2 create a route with a manufacture action - Go to Inventory > Configuration > Products > Attributes - Create a product att
Original PR description
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to…
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive the MTO Route - With CO1 create a route with a buy action and destination CO1/stock - With CO2 create a route with a manufacture action - Go to Inventory > Configuration > Products > Attributes - Create a product attribute with a value that "is_custom" - Create a storable product P with using MTO and tour CO1 and CO2 routes - Set CO2 as a vendor for the product - With CO1, create a SO for 1 unit of your product P - a popup asks you for a custom product attribute value, write "test" - Confirm the SO > Automatically creates a PO (w/ description) - Confirm the PO > Automatically create an SO in CO2 (w/ description) - Confirm the SO in CO2 > Automatically create an MO #### Issue: #### The custom description is missing on the final MO. #### Note: If you were to create an SO directly in CO2 for 1 unit of P, the custom description associated with the custom attribute value would be present on the associated MO. ### Cause of the issue: The MO is created by a procurement generated from the SOL during the call of the `_action_launch_stock_rule` method: https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L345 The custom description that will appear on the MO and containing the informations related to the custom attribute values is generated here: https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L267 However, this method will return an empty string because the `product_custom_attribute_value_ids` is absent from our SOL https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale/models/sale_order_line.py#L338-L347 On the other hand, this `product_custom_attribute_value_ids` was set and is still existing on the original SO that started the flow in CO1. The reason that it is not present anymore on the last SO is because this SOL field has no equivalent on the `purchase.order.line` model and the information was therefore forgotten on the MO and has not been transferred directly from the PO of CO1 to the SO of CO2. ### Fix: We rely on the `sale_line_id` field of the `purchase.order.line` model in order to determine the original SOL of the final SOL and update the `product_custom_attribute_value_ids` accordingly. ### Note: As a side effect of our change in `sale_purchase_stock` linking our sol to the pol via the procurement commit 63ef74b can be reverted since the message is already automatically posted (the message is now written by the user who cancelled the SO rather than Odoobot). opw-3998861 --- Forward-Port-Of: odoo/enterprise#67650 Forward-Port-Of: odoo/enterprise#67172