Tuesday, May 21, 2024
32 changes · saas-17.2
Enhancements to existing features
The accounting test suite has been updated to use Odoo's newer testing framework. This improves maintainability and helps ensure future accounting changes can be validated more reliably, without changing business functionality.
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 PR Enterprise: https://github.com/odoo/enterprise/pull/62434
Accounting-related automated tests were updated to use the newer testing framework. This is an internal quality improvement that helps maintain reliability without changing day-to-day user workflows.
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 Community PR: https://github.com/odoo/odoo/pull/165371
Resolved issues and error corrections
This change updates an internal setup test so it remains reliable when French localization demo data is installed first. It prevents false test failures caused by different default currencies, helping keep automated quality checks stable without changing user-facing behavior.
Original PR description
Since https://github.com/odoo/odoo/commit/67b4ec4ba431adb4090aa8629d2a556dbf8df54a, l10n_fr is installed before base_setup. The issue is that it creates a demo company that has EUR currency. While the default stays USD. As there are 2 currencies, the group multi_currency is given by default to users. The test trying to check that it's not given by default will then fail. We will have more occurences of this in the future, as more payroll modules will arrive. To solve the issue, we just test on a different group. Linked to runbot error 58147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
[IMP] point_of_sale: display odoo's logs' folder from an url Allow to access odoo logs from the IoT Box even if Odoo's server is down via nginx by displaying /var/log/odoo How : from the IoT Box, go to the url `/odoo-logs` will display all the logs files from Odoo opw-3887623 Forward-Port-Of: odoo/odoo#165765
Original PR description
[IMP] point_of_sale: display odoo's logs' folder from an url Allow to access odoo logs from the IoT Box even if Odoo's server is down via nginx by displaying /var/log/odoo How : from the IoT Box, go to the url `/odoo-logs` will display all the logs files from Odoo opw-3887623 Forward-Port-Of: odoo/odoo#165765
A mobile-only editor issue was fixed so the toolbar no longer tries to hide a link-removal option when that option is not available. This prevents unnecessary errors on small screens and keeps editing smoother for users.
Original PR description
When the unlink button is not present in the toolbar, the editor should not try to hide it. This commit fixes the issue by checking if the unlink button is present before trying to hide it. The issue only occurs on mobile (or small screens) where the toolbar is not hidden by default. opw-3865509
The salary contract form now shows yearly cost information to users who are already allowed to see it elsewhere. This removes an inconsistent restriction so staff can view the same compensation cost data in both list and form views.
Original PR description
Since you don't need the group 'hr.group_hr_manager' to access the value of the yearly cost and you have it displayed in the view list. We remove the group in the view form
Previously, only credit notes created from existing Invoices were allowed to be posted & sent to ZATCA. Now, as long as a credit/debit note has a Customer Reference (ref), the system will allow it to be confirmed and submitted Description of the issue/feature this PR addresses: Users are not allowed to confirm/submit Credit Notes if they are not linked to an existing Invoice Current behavior before PR: Upon confirmation/posting of a Credit Note, if it is not linked to an existing Invoice
Original PR description
Previously, only credit notes created from existing Invoices were allowed to be posted & sent to ZATCA. Now, as long as a credit/debit note has a Customer Reference (ref), the system will allow it to be confirmed and submitted Description of the issue/feature this PR addresses: Users are not allowed to confirm/submit Credit Notes if they are not linked to an existing Invoice Current behavior before PR: Upon confirmation/posting of a Credit Note, if it is not linked to an existing Invoice or does not have a Customer Reference, the system blocks the confirmation Desired behavior after PR is merged: As long as a credit note is linked to an existing Invoice or has a valid Custoemr Reference (ref) the system allows it to be confirmed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166102
commit that introduced the issue: [1] Steps to reproduce the issue: ============================= - Go to to-do - Add some text - Click shift+enter at the end of the first line - Add some text in the second line - Select a prefix of the second line - Click any character - The selection is back at the start of the paragraph Origin of the issue: ==================== This was done intentionally by the mentioned commit which didn't take into consideration this case. Solution: ==
Original PR description
commit that introduced the issue: [1] Steps to reproduce the issue: ============================= - Go to to-do - Add some text - Click shift+enter at the end of the first line - Add some text in the second line - Select a prefix of the second line - Click any character - The selection is back at the start of the paragraph Origin of the issue: ==================== This was done intentionally by the mentioned commit which didn't take into consideration this case. Solution: ========= We set the curosr at the element index relative to its parent. opw-3829462 [1]: https://github.com/odoo/odoo/commit/06658ff13abfbdaeb7c562b8fd33fc9cf4f56f95 Forward-Port-Of: odoo/odoo#164509
Following the update to the VAT code required to be used with ZATCA sandbox on SA companies, we need to update the demo PCSID and CCSID on the journals as well. Description of the issue/feature this PR addresses: Base demo data for SA company does includes outdated data for the Journals Current behavior before PR: Base demo data for SA companies includes outdated data for the Journals Desired behavior after PR is merged: Base demo data for SA companies includes updated CCSID & PCSID
Original PR description
Following the update to the VAT code required to be used with ZATCA sandbox on SA companies, we need to update the demo PCSID and CCSID on the journals as well. Description of the issue/feature this PR addresses: Base demo data for SA company does includes outdated data for the Journals Current behavior before PR: Base demo data for SA companies includes outdated data for the Journals Desired behavior after PR is merged: Base demo data for SA companies includes updated CCSID & PCSID on the journals --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166106
**Steps to reproduce:** - Install Delivery, Sales and Stock modules - Create a based on rules Shipping method for a product using weight as a variable - Create a quotation for this product - Add shipping to the quotation - Change the quantity of the order line - Click on 'Update shipping cost' **Current behavior before PR:** The weight of the order does not get updated once we set a shipping cost to the order. This is happening because of this condition https://github.com/odo
Original PR description
**Steps to reproduce:** - Install Delivery, Sales and Stock modules - Create a based on rules Shipping method for a product using weight as a variable - Create a quotation for this product - Add shipping to the quotation - Change the quantity of the order line - Click on 'Update shipping cost' **Current behavior before PR:** The weight of the order does not get updated once we set a shipping cost to the order. This is happening because of this condition https://github.com/odoo/odoo/blob/17.0/addons/delivery/models/sale_order.py#L139 since we can edit the quantity of the order lines then there is not point of not calculating the estimated weight each time. **Desired behavior after PR is merged:** With removing this condition the weight will get updated each time we open the shipping cost wizard. opw-3908453 Forward-Port-Of: odoo/odoo#165838 Forward-Port-Of: odoo/odoo#164928
This commit follows the list view renderer commit 62172737b689d08856f4ad3d3d49beb796c9f42e which adapts the vertical alignment inside the list view. Thus why this fix is in the same task. The btn remove (trash icon) was set to a padding of five pixels making it not vertically align with the rest of the list view text. This comes from commit 258e6a019a21042bf4f6cf70fcce386d37afd50c where the trash icon was moved to align with the new "View" button, but it misaligned the icon in all the oth
Original PR description
This commit follows the list view renderer commit 62172737b689d08856f4ad3d3d49beb796c9f42e which adapts the vertical alignment inside the list view. Thus why this fix is in the same task. The btn remove (trash icon) was set to a padding of five pixels making it not vertically align with the rest of the list view text. This comes from commit 258e6a019a21042bf4f6cf70fcce386d37afd50c where the trash icon was moved to align with the new "View" button, but it misaligned the icon in all the other list views. Applying an align top on the "View" button instead allows an even alignment with the rest of the text content of the list view. task-3557566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145457
This commits cleans up countries from manifest which were missed out by the following commit- https://github.com/odoo/odoo/commit/ac809d3c31cc29a31790aeef53f7a2a7bde4b9c8 task-3935204 Ent PR-https://github.com/odoo/enterprise/pull/62723 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165936
Original PR description
This commits cleans up countries from manifest which were missed out by the following commit- https://github.com/odoo/odoo/commit/ac809d3c31cc29a31790aeef53f7a2a7bde4b9c8 task-3935204 Ent PR-https://github.com/odoo/enterprise/pull/62723 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165936
### Steps to reproduce: - Enable Multi-step Routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Enable manufacturing in 2 steps (pbm) - Create a manufacturing order for a product P1 with a demand of 1 x P2 - Confirm the MO (a transfer for 1 x P2 should be created). - Add a line to the MO with a demand of 1 X P2 and save. #### > the related stock picking was updated twice leading to a demand of 3 Cause of the issue: Since pbm is enabled the co
Original PR description
### Steps to reproduce: - Enable Multi-step Routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Enable manufacturing in 2 steps (pbm) - Create a manufacturing…
### Steps to reproduce: - Enable Multi-step Routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Enable manufacturing in 2 steps (pbm) - Create a manufacturing order for a product P1 with a demand of 1 x P2 - Confirm the MO (a transfer for 1 x P2 should be created). - Add a line to the MO with a demand of 1 X P2 and save. #### > the related stock picking was updated twice leading to a demand of 3 Cause of the issue: Since pbm is enabled the components are required to be in pre-Production for the manufacturing to start with. As such, our MO is associated with two stock moves. One for the local transport of components: - move_inter_1: 1 x P2 from Stock to pre-Production - move_raw_1: 1 x P2 from pre-Production to Production Saving the additional component requirement on the mo will create and confirm a second raw move: - move_raw_2: 1 x P2 from pre-Production to Production During its "_action_confirm", the procurements of this move will create and confirm a second internal move: - move_inter_2: 1 x P2 from Stock to pre-Production During the "_action_confirm" of this internal move a merging process will start since the already existing move_inter_1 is a good candidate: https://github.com/odoo/odoo/blob/f07c1a6b60ac1d07d9a2b098cca6ba8413ffbe0d/addons/stock/models/stock_move.py#L1369-L1370 https://github.com/odoo/odoo/blob/f07c1a6b60ac1d07d9a2b098cca6ba8413ffbe0d/addons/stock/models/stock_move.py#L994-L998 The quantity of move_inter_1 will then be updated: https://github.com/odoo/odoo/blob/f07c1a6b60ac1d07d9a2b098cca6ba8413ffbe0d/addons/stock/models/stock_move.py#L1035 Then, the merging process of move_raw_2 will start since the already existing move_raw_1 is found as a good candidate and the quantity of this move will be updated by a "write" call. However, procurements are also run in the call of the write method unless 'no_procurement' is specified in the context: https://github.com/odoo/odoo/blob/e8f8c9b4286f60733153220511fd0e2bf33370b3/addons/mrp/models/stock_move.py#L344-L348 Since this is not the case, this will create and confirm a new internal move: - move_inter_3: 1 x P2 from Stock to pre-Production This move will also be merged to move_inter_1 (this is the second update). ### Fix: Since procurements will always be run by the "_action_confirm" of the related stock moves, we can safely skip the procurements run by the write method during this flow. opw-3880686 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163808
#### [FIX] account,sale: credit_to_invoice in multi-company Currently the credit_to_invoice includes sales orders from all allowed companies. But it should only include sales orders from the active company. (Since a single sales order belongs to only 1 company) #### [FIX] account: flush in _credit_debit_get of model res.partner Function _credit_debit_get uses a raw SQL query, but does not flush the used tables to the DB before. Without this commit some of the tests in the following c
Original PR description
#### [FIX] account,sale: credit_to_invoice in multi-company Currently the credit_to_invoice includes sales orders from all allowed companies. But it should only include sales orders from the active…
#### [FIX] account,sale: credit_to_invoice in multi-company
Currently the credit_to_invoice includes sales orders
from all allowed companies.
But it should only include sales orders from the active company.
(Since a single sales order belongs to only 1 company)
#### [FIX] account: flush in _credit_debit_get of model res.partner
Function _credit_debit_get uses a raw SQL query,
but does not flush the used tables to the DB before.
Without this commit some of the tests in the following commits of this PR will fail
(since some of the invoice lines are not flushed yet).
#### [FIX] account,sale: credit limit in multi-currency setup
The partner credit limit (warning) may not be computed correctly in a
multi-currency setup.
Note that the partner credit is always in company currency.
1) Consider a draft invoice. To determine the warning amount
the current amount in document currency (not company currency)
is added to the current partner credit (roughly speaking).
2) To compute the credits from sales orders of the partner
(credit_to_invoice) we just add the amount_to_invoice
from each sales order of the partner.
But this field is in the currency of the order
and thus may be different from the company currency.
To fix these issues currency conversions were added for both cases.
#### [FIX] account,sale: credit limit warning
Currently the amount of the partner credit warning
on invoices is not computed correctly in some cases.
1) There are Sales Order credits
and we create an invoice independent of any of SO
2) We create an invoice from a Sales Order with
an amount greater than the Sales Order.
For (1) the problem is that we substract the current
amount of the invoice from the sales order credits
(since we need to do this in the sales order to invoice flow)
But in case the invoice does not come from a sales order
this is wrong.
For (2) the problem is that the `amount_to_invoice` of a
Sales Order may be negative. This can happen if we invoice
more than the sales order amount.
E.g. we can end up with one invoiced order with -100 and
one uninvoiced order of 100. In the sum this would leave us
with "nothing to invoice" (100 + -100 = 0).
Reproduce (1):
All monetary values here are in company currency.
- Ensure that the partner credit is 0:
i.e. remove all Sales Orders and Invoices.
- Activate 'Sales Credit Limit' in the settings
and set the 'Default Credit Limit' to 100
- Create a new customer; here 'Test'
- Create a Sales Order for customer of 200
and deliver it
- The total partner credit is now 200
- Create an Invoice (not from the Sales Order)
for customer 'Test' (without any lines at first).
- There should be a warning that the total amount
due is 200 (since it exceeds the limit of 100).
- Add a line of 200 to the Invoice
(any value ≤ 200 will do).
- The total amount due in the warning is still 200
but it should be 400 (200 + 200)
- Change the line to 800 (any value > 200 will do)
- The total amount due in the warning is now 800
but it should be 1000 (200 + 800)
Reproduce (2):
All monetary values here are in company currency.
- Ensure that the partner credit is 0:
i.e. remove all Sales Orders and Invoices.
- Activate 'Sales Credit Limit' in the settings
and set the 'Default Credit Limit' to 100
- Create a new customer; here 'Test'
- Create 2 Sales Orders for customer of 200 each
and deliver it
- The total partner credit is now 400
- Create an Invoice from exactly one of the Sales Orders
(full amount or downpayment does not matter here)
- There should be a warning that the total amount
due is 400 (since it exceeds the limit of 100).
- Modify the invoice (any line from the sales order)
s.t. it has a total of 400
- Confirm the invoice
- The amount_to_invoice of the Sales Order is now -200.
The sum of the amount_to_invoice of the Sales Orders is 0.
- Create a new invoice without any lines.
- There is a warning that the total amount
due is 400 (= 200 + -200 + 400 ; SO + SO + invoice).
But it should be 600 since the "overinvoiced" SO
should just be counted with amount_to_invoice 0.
Forward-Port-Of: odoo/odoo#164971
Forward-Port-Of: odoo/odoo#162770Before this commit: =================== When clicking the refund button without selecting the quantity for the selected order lines, the ticket screen would redirect to the product screen, resulting in empty order lines. After this commit: =============== The refund button will not redirect the ticket screen to the product screen until a quantity is selected for the selected order line. Task ID: 3922007 Forward-Port-Of: odoo/odoo#165180
Original PR description
Before this commit: =================== When clicking the refund button without selecting the quantity for the selected order lines, the ticket screen would redirect to the product screen, resulting in empty order lines. After this commit: =============== The refund button will not redirect the ticket screen to the product screen until a quantity is selected for the selected order line. Task ID: 3922007 Forward-Port-Of: odoo/odoo#165180
As all won / lost leads will have an impact on the PLS frequency table, demo data will have one on the probabilities of leads without team_id set, as their probability is based on all leads, regardless on their team. Therefore, make sure we unlink all leads that are not the ones created in the test. We rebuild the table below, which is needed to ensure we only consider test leads. Follow up of ecac497336826b66799f63c1daa0749535ce73f1 Task-3700966 Forward-Port-Of: odoo/odoo#165842 Forward
Original PR description
As all won / lost leads will have an impact on the PLS frequency table, demo data will have one on the probabilities of leads without team_id set, as their probability is based on all leads, regardless on their team. Therefore, make sure we unlink all leads that are not the ones created in the test. We rebuild the table below, which is needed to ensure we only consider test leads. Follow up of ecac497336826b66799f63c1daa0749535ce73f1 Task-3700966 Forward-Port-Of: odoo/odoo#165842 Forward-Port-Of: odoo/odoo#162414
Before this commit, the root URL of the request was not sent to PayuLatam, leading to redirection to an incorrect website when databases with a different domain were set. To use the url_root, get_base_url must be called from the payment.acquirer instance. opw-3348291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165252 Forward-Port-Of: odoo/odoo#165092
Original PR description
Before this commit, the root URL of the request was not sent to PayuLatam, leading to redirection to an incorrect website when databases with a different domain were set. To use the url_root, get_base_url must be called from the payment.acquirer instance. opw-3348291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165252 Forward-Port-Of: odoo/odoo#165092
manual port of https://github.com/odoo/odoo/commit/c5175077ff9403bd2c1873a0144f31a6e8c8d3e3 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#165585
Original PR description
manual port of https://github.com/odoo/odoo/commit/c5175077ff9403bd2c1873a0144f31a6e8c8d3e3 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#165585
Issue: ====== Buttons of type of custom color in colorpicker are misaligned. Steps to reproduce the issue: ============================= - Go to notes and write some text - Select some text and open colorpicker - Got to gradient and click on Custom button Before: ======  After: ==== 
Original PR description
Issue: ====== Buttons of type of custom color in colorpicker are misaligned. Steps to reproduce the issue: ============================= - Go to notes and write some text - Select some text and open colorpicker - Got to gradient and click on Custom button Before: ======  After: ====  task-3562148 Forward-Port-Of: odoo/odoo#157234
New accounts added in https://github.com/odoo/odoo/commit/d8873ee01f0974e82de2e6cc906b0c77f8a3687f will not be created upon module update because they are stored in a csv. A migration script will trigger their creation by calling `try_loading()`, similarly as was done here for new taxes: https://github.com/odoo/odoo/blob/512574861691f425ec6a17f20fe4b586bb88a299/addons/l10n_fr/migrations/2.1/post-migrate_update_taxes.py#L8 https://github.com/odoo/odoo/blob/eb7ea22ea036c645d3c22049b6e874f9e8ada6d4
Original PR description
New accounts added in https://github.com/odoo/odoo/commit/d8873ee01f0974e82de2e6cc906b0c77f8a3687f will not be created upon module update because they are stored in a csv. A migration script will trigger their creation by calling `try_loading()`, similarly as was done here for new taxes: https://github.com/odoo/odoo/blob/512574861691f425ec6a17f20fe4b586bb88a299/addons/l10n_fr/migrations/2.1/post-migrate_update_taxes.py#L8 https://github.com/odoo/odoo/blob/eb7ea22ea036c645d3c22049b6e874f9e8ada6d4/addons/l10n_ch/migrations/11.1/post-migrate_update_taxes.py#L21 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165276
Issue --> The fetchall call made after the querying the dataset in `_saft_fill_report_general_ledger_values` runs into a memory error if there is a large number of rows. Solution --> Use a `while True` loop to use `dictfetchmany` to return rows in batches to optimize memory usage. `dictfetchmany` returns None if no rows are returned, which is the exit condition of the loop. opw-3859206 Forward-Port-Of: odoo/enterprise#62571 Forward-Port-Of: odoo/enterprise#61272
Original PR description
Issue --> The fetchall call made after the querying the dataset in `_saft_fill_report_general_ledger_values` runs into a memory error if there is a large number of rows. Solution --> Use a `while True` loop to use `dictfetchmany` to return rows in batches to optimize memory usage. `dictfetchmany` returns None if no rows are returned, which is the exit condition of the loop. opw-3859206 Forward-Port-Of: odoo/enterprise#62571 Forward-Port-Of: odoo/enterprise#61272
# Issue: In a Partner Ledger using the "Prefix Groups Threshold" option, there are the "Open" and "Journal Items" buttons that are available as any other line in partner ledger report but they aren't bind to a specific Partner so the Open button, redirect to a "New partner" page and the Journal Items raise a traceback. # Reproduce: - Go in debug mode - Accounting > Configuration > Accounting Report > Partner Ledger > Options - Set Prefix Groups Threshold to 2 - Go in
Original PR description
# Issue:
In a Partner Ledger using the "Prefix Groups Threshold" option, there are the "Open" and "Journal Items" buttons that are available as any other line in partner ledger report but they aren't bind to a specific Partner so the Open button, redirect to a "New partner" page and the Journal Items raise a traceback.
# Reproduce:
- Go in debug mode
- Accounting > Configuration > Accounting Report > Partner Ledger > Options
- Set Prefix Groups Threshold to 2
- Go in Accounting > Reports > Partner Ledger
- Try to open a journal items on a "Grouping Line"
# Task:
opw-3916555
Forward-Port-Of: odoo/enterprise#62360Before this commit, When the developer mode is enabled and the user click on the available "x" button in the selection box, a traceback will be occur. Steps to Reproduce : 1. Toggle On the developer mode 2. Go to any app ( here Sales ) ---> Toggle Studio 3. Click on Reports ---> Select any Report 4. Click on Edit XML sources --> Click on the "x" button available 5. Traceback occurs Video link : [link](https://drive.google.com/file/d/1Qf6VI118YypPQI8Je6DP4xkfjSVqwCC_/view) Traceback
Original PR description
Before this commit, When the developer mode is enabled and the user click on the available "x" button in the selection box, a traceback will be occur. Steps to Reproduce : 1. Toggle On the developer mode 2. Go to any app ( here Sales ) ---> Toggle Studio 3. Click on Reports ---> Select any Report 4. Click on Edit XML sources --> Click on the "x" button available 5. Traceback occurs Video link : [link](https://drive.google.com/file/d/1Qf6VI118YypPQI8Je6DP4xkfjSVqwCC_/view) Traceback message link : https://pastebin.com/cunYkfBm after the commit,The "x" button in the selection box won't be shown to users. Task-3866142 Forward-Port-Of: odoo/enterprise#61283
The link from 'Balance Sheet (abridged)' to 'Profit & Loss (abridged)' raises an error. ### Steps to reproduce : - Install the l10n_lu_reports module - Change the company to a Luxembourgian company - Go to Accounting > Reporting > Statement Reports > Balance Sheet - Change the report to 'Balance Sheet (abridged) (LU)' - In the report, click on the link 'VI. Profit or loss for the financial year' ### Cause: The action triggered by this link has not the right formatted context. It shou
Original PR description
The link from 'Balance Sheet (abridged)' to 'Profit & Loss (abridged)' raises an error. ### Steps to reproduce : - Install the l10n_lu_reports module - Change the company to a Luxembourgian company - Go to Accounting > Reporting > Statement Reports > Balance Sheet - Change the report to 'Balance Sheet (abridged) (LU)' - In the report, click on the link 'VI. Profit or loss for the financial year' ### Cause: The action triggered by this link has not the right formatted context. It should have the value 'report_id' but has 'model' and 'id' instead. This raises an error in execute_action when trying to read 'report_id' on this action. ### Solution: Remove 'model' in the context and rename 'id' to 'report_id'. opw-3912348 Forward-Port-Of: odoo/enterprise#62715
This commit fixes an issue that was brought by the redesign of Odoo, Milk. This redesign modified a scss variable for kanban views inside of form views which removed the background of the kanban view's headers. Now a new css rule has been added to the kanban embedded view so that the background comes back to its original value inside of Knowledge. task-3930157 Forward-Port-Of: odoo/enterprise#62528
Original PR description
This commit fixes an issue that was brought by the redesign of Odoo, Milk. This redesign modified a scss variable for kanban views inside of form views which removed the background of the kanban view's headers. Now a new css rule has been added to the kanban embedded view so that the background comes back to its original value inside of Knowledge. task-3930157 Forward-Port-Of: odoo/enterprise#62528
This commits cleans up countries from manifest which were missed out by the following commit- https://github.com/odoo/enterprise/commit/148810637bf9e7a9cc53338f665ec612221a1ba2 task-3935204 Community PR- https://github.com/odoo/odoo/pull/165936 Forward-Port-Of: odoo/enterprise#62723
Original PR description
This commits cleans up countries from manifest which were missed out by the following commit- https://github.com/odoo/enterprise/commit/148810637bf9e7a9cc53338f665ec612221a1ba2 task-3935204 Community PR- https://github.com/odoo/odoo/pull/165936 Forward-Port-Of: odoo/enterprise#62723
When unfolding the journals, a lot of empty, unused space was left around the values. This lead to the report easily becoming too large for the screen, causing the display of an horizontal scrollbar, and hence degrading the user experience. We fix that by removing any notion of minimal width for this report specifically. Forward-Port-Of: odoo/enterprise#62718
Original PR description
When unfolding the journals, a lot of empty, unused space was left around the values. This lead to the report easily becoming too large for the screen, causing the display of an horizontal scrollbar, and hence degrading the user experience. We fix that by removing any notion of minimal width for this report specifically. Forward-Port-Of: odoo/enterprise#62718
A separate tree view is defined in `whatsapp_template_view_form` to display the `variable_ids` field on the Variables page. This tree view contains fields that are not needed to display, such as `model`, `line_type`, and `name`. These fields are made invisible using `column_invisible="1"`. Task-3902030 Forward-Port-Of: odoo/enterprise#61952
Original PR description
A separate tree view is defined in `whatsapp_template_view_form` to display the `variable_ids` field on the Variables page. This tree view contains fields that are not needed to display, such as `model`, `line_type`, and `name`. These fields are made invisible using `column_invisible="1"`. Task-3902030 Forward-Port-Of: odoo/enterprise#61952
When accessing EC listing through the "Do not forget to submit the EC Sales list report" warning, the tax report's options used not to be passed onto EC listing. Steps to reproduce original issue: - Install `l10n_be_reports` - Create an invoice for a customer with 'Intra-Community' as a 'Fiscal Position' - Confirm it - Go to: Accounting > Reporting > Statement Reports > Tax Report - Select a period that'd include the invoice - Click on the "Do not forget to submit the EC Sales list re
Original PR description
When accessing EC listing through the "Do not forget to submit the EC Sales list report" warning, the tax report's options used not to be passed onto EC listing. Steps to reproduce original issue: - Install `l10n_be_reports` - Create an invoice for a customer with 'Intra-Community' as a 'Fiscal Position' - Confirm it - Go to: Accounting > Reporting > Statement Reports > Tax Report - Select a period that'd include the invoice - Click on the "Do not forget to submit the EC Sales list report" warning - The period selected will be the wrong one task-3891799 Forward-Port-Of: odoo/enterprise#62761 Forward-Port-Of: odoo/enterprise#62642
Kilometers are only computed using the aller-simple distance instead of aller retour Forward-Port-Of: odoo/enterprise#62366
Original PR description
Kilometers are only computed using the aller-simple distance instead of aller retour Forward-Port-Of: odoo/enterprise#62366
### Steps to reproduce: With company 1: - Go to the General Settings and activate: 1) Inter-Company Transactions: - "Synchronize Sales and Purchase Order" - "Automatic Validation" - "Copy Lots on Delivery Validation" 2) Multi-Step Routes - Go to Inventory > Configuration > Warehouse Management > Locations - Create a new Location SHELF with COMP1/STOCK as parent - Go to Inventory > Configuration > Warehouse Management > Putaway Rules - Create a new putaway r
Original PR description
### Steps to reproduce: With company 1: - Go to the General Settings and activate: 1) Inter-Company Transactions: - "Synchronize Sales and Purchase Order" - "Automatic Validation" - "Copy Lots on…
### Steps to reproduce:
With company 1:
- Go to the General Settings and activate:
1) Inter-Company Transactions:
- "Synchronize Sales and Purchase Order"
- "Automatic Validation"
- "Copy Lots on Delivery Validation"
2) Multi-Step Routes
- Go to Inventory > Configuration > Warehouse Management > Locations
- Create a new Location SHELF with COMP1/STOCK as parent
- Go to Inventory > Configuration > Warehouse Management > Putaway Rules
- Create a new putaway rule applicable to all products from COMP2/STOCK to COMP2/STOCK/SHELF
With company 2:
- Create a storable product tracked by a Unique Serial Number
- Click on "On Hand" > Register 1 on hand qty with a new serial Number
- Create and confirm an SO for company 2 with your product
At this point, if you go to company 1:
A purchase order related to the SO was created and confirmed. If you open the related delivery and inspect the related stock move line the destination, it will correctly be set to COMP1/STOCK/SHELF.
With company 2:
- Open the delivery linked to your SO click on the list icon of you stock move line
- Add a stock picking referencing the serial number you created
- Validate the delivery
If you go to company 1, the move line is now attached with a serial number but the destination is set to set to COMP1/STOCK.
#### > The putaway rule is not applied anymore
### Cause of the issue:
When you confirmed the SO with company 2, it will create an PO in company 1:
https://github.com/odoo/enterprise/blob/3190d36192def6c63c254e16e754b12353a865e6/sale_purchase_inter_company_rules/models/sale_order.py#L22 and a related stock move will then be created. During the "_action_confirm" of this stock move the putaway rules will be applied to the stock move lines a few lines after creation: https://github.com/odoo/odoo/blob/58fefc94ca39f7951392063921fe9b5e606178e6/addons/stock/models/stock_move.py#L1720 When you confirm the delivery, this correclty set stock move line will be deleted and a new one will be created:
https://github.com/odoo/enterprise/blob/3190d36192def6c63c254e16e754b12353a865e6/sale_purchase_inter_company_rules/models/stock_picking.py#L30-L33 However, as the "apply_putaway_strategy" method is not called after the creation of this newly created stock move line, the destination of the line will entirly be set by the destination of the stock move: https://github.com/odoo/odoo/blob/42b760c8fa27cfc75fcb2fd5b232defc9002e85f/addons/stock/models/stock_move.py#L1441 so that the put away rules will not be applied anymore.
opw-3744375
Forward-Port-Of: odoo/enterprise#62427
Forward-Port-Of: odoo/enterprise#60161Steps: - Schedule an appointment for one table at a specific time. - Open the POS and verify the appointment. - In a separate tab, open the appointments application and transfer the appointment to a different table. - Return to the POS tab and confirm that the appointment is displayed on both tables. Issue: Both tables display scheduled appointments. Cause: Booking is not removed from the previous table. FIX: When updating an appointment to a new table, the booking is only visibl
Original PR description
Steps: - Schedule an appointment for one table at a specific time. - Open the POS and verify the appointment. - In a separate tab, open the appointments application and transfer the appointment to a different table. - Return to the POS tab and confirm that the appointment is displayed on both tables. Issue: Both tables display scheduled appointments. Cause: Booking is not removed from the previous table. FIX: When updating an appointment to a new table, the booking is only visible on current booking table. task-3893909 Forward-Port-Of: odoo/enterprise#62020