Thursday, May 23, 2024
25 changes · master
Enhancements to existing features
The appointment module’s automated tests were updated to reflect a calendar list view change. This helps ensure the “All calendars” filter continues to be checked correctly during development, reducing the risk of regressions for appointment scheduling.
Original PR description
This commit adapts the tests with mock RPC routes to add the route to get the "All calendars" filter from the calendar's list view. related: odoo/odoo#149192 task-3790206
Employees with an appraisal already in progress now see “Ongoing” where the next appraisal date appears, instead of a blank value. This makes appraisal status clearer for managers and employees reviewing employee profiles.
Original PR description
Before the next appraisal date displayed nothing when there was an ongoing appraisal but now it will display "Ongoing". task-3890332
New automated tests verify that Balance Sheet reports remain balanced across supported accounting setups. This helps catch localization or configuration issues earlier, reducing the risk of inaccurate financial reports reaching users.
Original PR description
This commit introduces a l10n test over the Balance Sheet reports. For each CoA, a company is set-up, and all the available Balance Sheet reports for the company are tested. The test generates a…
This commit introduces a l10n test over the Balance Sheet reports. For each CoA, a company is set-up, and all the available Balance Sheet reports for the company are tested. The test generates a journal entry with a line in every account that is not `off_balance` and not in the NON_TESTED_ACCOUNTS global at the head of the file (useful for accounts that are forced to be generated, but should never be used, like 999999 in Belgium). It then checks whether the Balance Sheet is balanced. The test does this both for debits and for credits. To work, the test needs to know, for each Balance Sheet report: - the XMLID of the Total Assets line - the XMLID of the Total Liabilities line - the XMLID of the Total Equity line (if separate from Liabilities) - the column name containing the balance (if different from 'balance') These are specified in the REPORT_CONFIG global at the head of the file. The test will hard-fail if an available Balance Sheet report is not configured in the REPORT_CONFIG global. This makes it mandatory for new Balance Sheets to add their config there. Setting the global IDENTIFY_INCORRECT_ACCOUNTS to True switches the behaviour of the test: it identifies the accounts that cause the imbalance using a binary search. This is off by default for runbot. Task: 3060790
This update removes outdated configuration left over from an earlier redesign of the import screen controls. It does not change user-facing behavior, but helps keep the accounting import interface easier to maintain and less prone to future layout issues.
Original PR description
During the "Milk" redesign [1], ControlPanel's layout was changed, impacting the `display` prop used to control which parts are displayed or not.
This commit cleans up some remnants of the old layout (i.e. `{top,bottom}-{left,right}`) that are now unused.
task-3336242
[1]: https://github.com/odoo/odoo/pull/116641Resolved issues and error corrections
This update makes minor corrections to the manufacturing planning setup. It removes an unwanted default forecast value, clarifies a form label, and prevents an error when adding products without an enabled route to the master production schedule.
Original PR description
- remove the default setting from 'To Forecast' field - change the label for field `is_indirect` on form view
Code cleanup and technical improvements
This update modernizes internal accounting report query handling by replacing older query-building logic with a newer, safer SQL object approach. It should not change day-to-day user workflows, but it improves maintainability and consistency across accounting, tax, asset, and localization reports.
Original PR description
Miscellaneous changes
The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing implementation assumes the code has 3 sets of digits separated by two dots, and that the account name has no dots. This is true for the default chart of accounts for Mexico, but is not necessarily the case if additional accounts are added by the user. As a result, invalid NumCta values were generated, whi
Original PR description
The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing…
The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing implementation assumes the code has 3 sets of digits separated by two dots, and that the account name has no dots. This is true for the default chart of accounts for Mexico, but is not necessarily the case if additional accounts are added by the user. As a result, invalid NumCta values were generated, which would include parts of the account name if dots were present in it, or the value would be too long if the code had more than two dots. Subdividing the code into further levels is allowed, they'll get aggregated into the allowed SAT code (of the form XXX or XXX.YY). Dots in account names shouldn't matter. This fix makes the parsing of the NumCta value more strict so it supports the above use cases. In case the prefix doesn't match the expected pattern, an error is shown to the user. Normally this shouldn't happen, since the line would have been filtered out if it didn't match a valid prefix from the upper levels. It was added to make the code more robust against refactoring and customization, and to prevent an uncaught traceback in that case. opw-3878763 Forward-Port-Of: odoo/enterprise#62920 Forward-Port-Of: odoo/enterprise#62113
This fixes an intermittent automated test failure in financial reporting by making the test wait for the correct sorted report lines. It helps keep quality checks stable without changing how users interact with reports.
Original PR description
issue: when the account_reports tour test is run it sometimes fails with some report line not containing the correct value. The root cause of this issue is that the triggers for 2 of the test steps check the content of lines that are excluded from sorting. This could result in the test step triggering before sorting of the report is completed, which will in turn fail the testcase. fix: while testing the sorting mechanism only trigger on lines that are included in the sort. This ensures the next test step is triggered after sorting is completed.
Gist: - Rename `_get_table_expression` to `_get_sql_table_expression` This clarifies that the function returns an SQL expression and not a `account.report.expression`. - Remove `_query_get`: use `_get_sql_table_expression` instead. This makes use of the new `odoo.tools.SQL` object. - Some related functions / queries were adapted to use the new SQL object too: I.e. `_get_query_tax_details` and `_get_query_currency_table` (see related community PR) community PR: https://github.com/odoo/odoo/pull/158880 task-3791228
Since we don't create anymore a contract by default, we don't need to change the values of the contract on the newly created bike. More over, if there is a customization of the creation of vehicle it will scratch it Forward-Port-Of: odoo/enterprise#62455
Original PR description
Since we don't create anymore a contract by default, we don't need to change the values of the contract on the newly created bike. More over, if there is a customization of the creation of vehicle it will scratch it Forward-Port-Of: odoo/enterprise#62455
Steps to reproduce: - Install l10n_es_reports - Switch to a Spanish company (e.g. ES Company) - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Check that a Spanish Tax Report is selected (i.e. Mod 111/115/303/347/349) - Click on "Save" - Select "BOE" for "Export To" option - Export Issue: A traceback is raised: "KeyError: 'res_id'" Cause: In previous versions, "open_boe_wizard" method was creating the wizard and returning its "id". It's not the case anymore.
Original PR description
Steps to reproduce: - Install l10n_es_reports - Switch to a Spanish company (e.g. ES Company) - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Check that a Spanish Tax Report is selected (i.e. Mod 111/115/303/347/349) - Click on "Save" - Select "BOE" for "Export To" option - Export Issue: A traceback is raised: "KeyError: 'res_id'" Cause: In previous versions, "open_boe_wizard" method was creating the wizard and returning its "id". It's not the case anymore. Complement of https://github.com/odoo/enterprise/commit/e8d5582a773d7f31669fa8be576569681ed3f110 opw-3856749 Forward-Port-Of: odoo/enterprise#62841
**Steps to reproduce:** - Install account_reports - Install a RTL language (e.g. Arabic) - Set the RTL language on the current user - Set the currency of the company to SR - Go to "Accounting / Reporting / Partner Ledger" - Make sure there are some partners with long name (but less than 50 chars) - Print PDF **Issue:** In RTL, the partner column overflows outside of the page width. **Cause:** The break-word is only activated when the name has more than 50 characters. In RTL, the
Original PR description
**Steps to reproduce:** - Install account_reports - Install a RTL language (e.g. Arabic) - Set the RTL language on the current user - Set the currency of the company to SR - Go to "Accounting / Reporting / Partner Ledger" - Make sure there are some partners with long name (but less than 50 chars) - Print PDF **Issue:** In RTL, the partner column overflows outside of the page width. **Cause:** The break-word is only activated when the name has more than 50 characters. In RTL, the cell to display the partner is smaller. **Solution:** Do not use a minimum length of 50 characters to activate "break-word" in RTL. opw-3888122 Forward-Port-Of: odoo/enterprise#62626
In the view when `email_from` precomputation isn't triggered because one of its dependencies `mail_server_id` isn't present in the view, because of that `email_from` stays NULL which raises an error since it's a required field. task-3901450 Forward-Port-Of: odoo/enterprise#62860 Forward-Port-Of: odoo/enterprise#62164
Original PR description
In the view when `email_from` precomputation isn't triggered because one of its dependencies `mail_server_id` isn't present in the view, because of that `email_from` stays NULL which raises an error since it's a required field. task-3901450 Forward-Port-Of: odoo/enterprise#62860 Forward-Port-Of: odoo/enterprise#62164
Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work order using the work center from the previous step. On the miscellaneous tab, add an analytic account. 4. Confirm the MO. 5. On the Work Orders tab, change the Real Duration to 60:00 6. Analytic account smart button > the gross margin is correctly set. 7. Either change the real duration to 0:
Original PR description
Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work…
Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work order using the work center from the previous step. On the miscellaneous tab, add an analytic account. 4. Confirm the MO. 5. On the Work Orders tab, change the Real Duration to 60:00 6. Analytic account smart button > the gross margin is correctly set. 7. Either change the real duration to 0:00 or open the work order and delete a line from the Time Tracking tab. Note: decreasing the Real Duration on the Manufacturing Order page will not lead to an issue as long as no time record is deleted on the work order (typically, when decreasing the time by a small amount). Issue ----- The gross margin still takes into account the employee's cost for the deleted time. Note that the workcenter's cost is removed from the gross margin as expected. Either by _create_or_update_analytic_entry in case the time of the work order is modified, or unlink if the work order is deleted. https://github.com/odoo/odoo/blob/16.0/addons/mrp_account/models/mrp_workorder.py Fix ----- When deleting a time record, modify the analytic account accordingly. We create an analytic entry with a previous_duration equal to the double of the time that is deleted. https://github.com/odoo/enterprise/blob/a992a3ae345478a148e536103c1585a4caa86113/mrp_workorder_hr_account/models/mrp_workorder.py#L16 That way, we create an analytic entry with a duration equal to the negative of the deleted time. This will add a positive amount to the analytic account. https://github.com/odoo/enterprise/blob/a992a3ae345478a148e536103c1585a4caa86113/mrp_workorder_hr_account/models/mrp_workorder.py#L21-L22 This makes the analytic account's gross margin consistent with the time worked. **opw-3759144** Forward-Port-Of: odoo/enterprise#61881 Forward-Port-Of: odoo/enterprise#58760
Before this commit: Only the first two `/` were removed from reference_id of picking. creating wrong shipping request url for reference_id with more than two `/`. After this commit: All the slashes are removed from reference_id. opw-3853123 Forward-Port-Of: odoo/enterprise#60652
Original PR description
Before this commit: Only the first two `/` were removed from reference_id of picking. creating wrong shipping request url for reference_id with more than two `/`. After this commit: All the slashes are removed from reference_id. opw-3853123 Forward-Port-Of: odoo/enterprise#60652
Before this commit: request timeout was 15 seconds, which was too short for sendcloud request when requesting large ammount of data. After this commit: request timeout increased to 60 seconds. opw-3890386 Forward-Port-Of: odoo/enterprise#62043
Original PR description
Before this commit: request timeout was 15 seconds, which was too short for sendcloud request when requesting large ammount of data. After this commit: request timeout increased to 60 seconds. opw-3890386 Forward-Port-Of: odoo/enterprise#62043
When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change, not with traceback. Step to reproduce: - Open helpdesk - open the 'all tickets' menu - open any ticket form - set the team_id to false - save changes or click anywhere else to leave the edit field => a traceback occurs Source of the issue: When a new team is set on a ticket, a new stage
Original PR description
When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change,…
When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change, not with traceback. Step to reproduce: - Open helpdesk - open the 'all tickets' menu - open any ticket form - set the team_id to false - save changes or click anywhere else to leave the edit field => a traceback occurs Source of the issue: When a new team is set on a ticket, a new stage is set on it, as well as new sla_status. The issue is that inside the _compute_sla_deadline method, the calendar of the team is used. But since there are no teams, there are also no calendar. And the ensure_one() fails later on in the stack because of that. Solution: Prevent the computation of those values for ticket without team_id. Since this is an invalid value, the changes would be rolled back anyway, or overwrite once the user put a valid value for the team. version 16.0 - master task - 3895303 Forward-Port-Of: odoo/enterprise#61563
This issue arises after having visited the "General Ledger" at least once. When clicking on the "General Ledger" part of the "The current balance in the General Ledger didn't match the balance of your last bank statement, leading to an unexplained difference of [...]" message in "Bank Reconciliation", options such as the currency unit weren't properly transferred. Steps to reproduce original issue: - Install `account_reports` - Go to: Accounting > Reporting > Audit Reports > General Le
Original PR description
This issue arises after having visited the "General Ledger" at least once. When clicking on the "General Ledger" part of the "The current balance in the General Ledger didn't match the balance of your last bank statement, leading to an unexplained difference of [...]" message in "Bank Reconciliation", options such as the currency unit weren't properly transferred. Steps to reproduce original issue: - Install `account_reports` - Go to: Accounting > Reporting > Audit Reports > General Ledger - Go back - Create, confirm & reconcile an invoice - Reset invoice to draft - In "Accounting", go to "Dashboard" - Click on the 3 vertical dots to the right of the "Bank" card - Click on "Reconciliation Report" - In "Options: Posted Entries Only", select "Include Draft Entries" - Click on "General Ledger" in the first yellow warning - Draft entries won't be included task-3928454 Forward-Port-Of: odoo/enterprise#62940 Forward-Port-Of: odoo/enterprise#62655
Steps to reproduce: - Configure Starshipit - Create a stock picking - Choose Starshipit as carrier - Validate the picking - Try multiple times to reproduce the error Current behaviour: - KeyError exception raised Expected behaviour: - Should not have any KeyError Explanation: Starshipit API sometimes will not return the total_shipping_price, therefore the carrier price become 0 and cannot proceed. To handle this case, we put the order detail fetching in background as wel
Original PR description
Steps to reproduce: - Configure Starshipit - Create a stock picking - Choose Starshipit as carrier - Validate the picking - Try multiple times to reproduce the error Current behaviour: - KeyError exception raised Expected behaviour: - Should not have any KeyError Explanation: Starshipit API sometimes will not return the total_shipping_price, therefore the carrier price become 0 and cannot proceed. To handle this case, we put the order detail fetching in background as welljust in case the API didn't return the total_shipping_price again. task-3887386 Forward-Port-Of: odoo/enterprise#61286
The compute function _compute_sending_conditions needs date_from and date_to fields as its dependencies to compute whether or not to show the "Send" button on the ICP report SBR wizard. Without them, the field does not get properly recomptued, and the button isn't shown, unless the "Is Test" checkbox gets ticked by the user. Forward-Port-Of: odoo/enterprise#62876
Original PR description
The compute function _compute_sending_conditions needs date_from and date_to fields as its dependencies to compute whether or not to show the "Send" button on the ICP report SBR wizard. Without them, the field does not get properly recomptued, and the button isn't shown, unless the "Is Test" checkbox gets ticked by the user. Forward-Port-Of: odoo/enterprise#62876
…ec widget Steps to reproduce: - Create an invoice with a foreign currency of rate 1:3: 120 EUR = 40 USD - Create a statement line with a foreign currency of rate 1:2: 120 EUR = 60 USD - Reconcile them both using the bank reco widget: An exchange diff of 20 USD will be created. At this point, the invoice and the statement line are reconciled all together. The exchange difference is reconciled with the statement line (lowest rate). The point is both account.partial.reconcile are linke
Original PR description
…ec widget Steps to reproduce: - Create an invoice with a foreign currency of rate 1:3: 120 EUR = 40 USD - Create a statement line with a foreign currency of rate 1:2: 120 EUR = 60 USD - Reconcile…
…ec widget Steps to reproduce: - Create an invoice with a foreign currency of rate 1:3: 120 EUR = 40 USD - Create a statement line with a foreign currency of rate 1:2: 120 EUR = 60 USD - Reconcile them both using the bank reco widget: An exchange diff of 20 USD will be created. At this point, the invoice and the statement line are reconciled all together. The exchange difference is reconciled with the statement line (lowest rate). The point is both account.partial.reconcile are linked to the exchange diff. That's what will cause the problem describe below. When the invoice is reset to draft: 'button_draft' removes the reconciliation so the partial linking the invoice with the statement line is deleted. Since an exchange diff is attached to the account.partial.reconcile through the exchange_move_id field, we create a reversal for the exchange diff to neutralize its accounting items. During the creation of the reversal, we remove the reconciliation so the partial linking the exchange difference with the statement line is deleted. Since the exchange diff is wrongly attached to this partial too, again, the code tries to reverse the exchange difference. At the end, a double reversal of the exchange diff has been created. opw: 3869770 Forward-Port-Of: odoo/enterprise#62773 Forward-Port-Of: odoo/enterprise#62717
**Steps to reproduce:** - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE) - Activate another currency (e.g. USD) - In Accounting settings, run the "Automatic Currency Rates" feature ([MX] Bank of Mexico) - Add a different currency rate for USD for yesterday - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Currency: [USD] * Invoice Date: [yesterday] * Invoice Lines: - Product: [any product with UNS
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE) - Activate another currency (e.g. USD) - In Accounting settings, run the…
**Steps to reproduce:**
- Install Accounting and l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE)
- Activate another currency (e.g. USD)
- In Accounting settings, run the "Automatic Currency Rates" feature ([MX] Bank of Mexico)
- Add a different currency rate for USD for yesterday
- Create an invoice:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Currency: [USD]
* Invoice Date: [yesterday]
* Invoice Lines:
- Product: [any product with UNSPSC Category set]
- Price: [any] - Taxes: [any]
- Confirm the invoice
- Generate CFDI via "Send & Print" button
- Request Cancel:
* Reason: 01- Invoice issued with errors (with related document)
- Create Replacement Invoice
**Issue:**
A UserError is raised while checking the balance of the replacement invoice because the total of debits and the total of credits are different.
**Cause:**
The lines for the replacement invoice are just copied, keeping the values of the original invoice lines for many fields (such as "balance", "discount_balance" and "tax_base_amount").
Product-type lines do not have "balance" set in the copied data. In this case, "balance" is computed by using the current currency rate when the replacement invoice is created, which is correct.
The other lines are populated with the copied "balances" that correspond to the previous currency rate, which is not correct.
This leads to a mix of balances linked to different currency rates.
These fields are in the invoice currency and should be computed with the current currency rate as the replacement invoice is created with the present day as invoice date.
**Solution:**
Remove non product-type lines from the copied data to force them to recompute with the current currency rate.
opw-3863010
opw-3902683
Forward-Port-Of: odoo/enterprise#62373Steps to reproduce: ------------------- - create a project; - create a new planning slot for the project with a resource (user); - go to the project and create a task; - record timesheet in the planning slot time range in the task; - go to the planning slot view (via list view) Issue: ------ The times recorded are not updated (in the smart button). Despite the fact that `_compute_effective_hours` depends on `timesheet_ids`. Cause: ------ The `effective_hours` field will be recomp
Original PR description
Steps to reproduce: ------------------- - create a project; - create a new planning slot for the project with a resource (user); - go to the project and create a task; - record timesheet in the planning slot time range in the task; - go to the planning slot view (via list view) Issue: ------ The times recorded are not updated (in the smart button). Despite the fact that `_compute_effective_hours` depends on `timesheet_ids`. Cause: ------ The `effective_hours` field will be recomputed if one of its dependencies changes (in this case, `timesheet_ids`). For `timesheet_ids` to be marked for compute, one of its dependencies must change. `project_id.analytic_account_id.line_ids` is different from `project_id.timesheet_ids`. As a result, the method which computes `effective_hours` is not triggered. Solution: --------- Add `project_id.timesheet_ids` in dependencies. opw-3891624 Forward-Port-Of: odoo/enterprise#61668
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
How to reproduce: - Enable "Storage Locations"; - Create a receipt with WH/Stock/Shelf 2 as the Destination Location; - Add a product with a barcode in this receipt and mark it as todo; - Open the created receipt in the Barcode app; - Scan the product; - Scan WH/Stock/Shelf 1 barcode. -> Current behavior: the product will be moved in Shelf 1, which is not a sublocation of Shelf 2 (the receipt's destination.) -> Expected behavior: a product cannot be moved in a destination who is not
Original PR description
How to reproduce: - Enable "Storage Locations"; - Create a receipt with WH/Stock/Shelf 2 as the Destination Location; - Add a product with a barcode in this receipt and mark it as todo; - Open the created receipt in the Barcode app; - Scan the product; - Scan WH/Stock/Shelf 1 barcode. -> Current behavior: the product will be moved in Shelf 1, which is not a sublocation of Shelf 2 (the receipt's destination.) -> Expected behavior: a product cannot be moved in a destination who is not (a part of) the picking's destination. [OPW-3895328](https://www.odoo.com/web#id=3895328&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#62546 Forward-Port-Of: odoo/enterprise#61560
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