Friday, May 24, 2024
34 changes
1 change
Resolved issues and error corrections
This update fixes several issues in Odoo's internal HOOT testing tools and mock browser/server behavior. It helps developers run more reliable automated tests, reducing the risk of test failures unrelated to real product problems.
Original PR description
## Pull Request HOOT (PRHOOT) - part 15.5 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 15.5 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
4 changes
Resolved issues and error corrections
Spreadsheet autocomplete now includes the needed date granularity when suggesting pivot fields, preventing formula errors for date-grouped data. The spreadsheet edition was also aligned with the latest underlying spreadsheet library changes, improving compatibility and reliability.
Original PR description
### [FIX] spreadsheet_edition: auto-complete with date granularity
Steps to reproduce:
- Go to CRM lead pivot view
- group by any date field by day
- insert in spreadsheet
- start typing '=odoo.pivot(1, <measure>, '
=> Currently, when the auto-complete proposes a date field (e.g. "create_date"),
the field is proposed without the granularity ("create_date", not
"create_date:month").
The formula result is an error if the granularity is missing.
Task: 3823433
X-original-commit: https://github.com/odoo/enterprise/commit/a52b11884adaefa45e2f854bf775a43afb462d2b
### [FIX] spreadsheet_edition: Update o_spreasheet to latest version
Update spreadsheet_edition code following library update.
Counterpart of https://github.com/odoo/odoo/pull/16668720 changes
Resolved issues and error corrections
This fix corrects how yearly salary costs are calculated when employees have extra time off benefits. Previously, when benefits were changed and triggered a salary recalculation, the system would incorrectly compute the yearly cost if the contract included additional vacation days. The fix ensures the calculation properly accounts for extra time off, though the final amount may vary by a few cents due to rounding in the calculation process.
Original PR description
When the yearly cost is recomputed, beecause the change of a benefit re-triggered it, it is badly recomputed if the contract contains extra time off. To avoid this issue, we us the function _get_yearly_cost with inverse param to true that correctly handle the value of the extra time off in the yearly cost. The amount of the yearly cost can slightly change, few cents, because of the precision lost caused by computing gross from yearly cost and then recomputing yearly cost based on the gross
The GSTR-1 report now includes POS order reversal entries when a customer later requests an invoice for a POS sale. This prevents sales and HSN values from being counted twice, improving the accuracy of Indian GST reporting.
Original PR description
Fixes an issue where the GSTR-1 Report was double counting sales and HSN due to missing POS order reversal entries. Scenario: - A sale is made via POS without an invoice. - Later, an invoice is requested and generated, creating two entries: 1. Invoice sales entry. 2. Reversal of the POS order. This update ensures that these reversal entries are included in the GSTR-1 report, preventing double counting. Task Id: 3927208
Several localization and accounting EDI tests were updated to match the new invoice line behavior where product names are no longer automatically used as line names. This helps keep electronic invoicing, tax, and statutory reporting checks reliable after the product widget change.
Original PR description
*: account_avatax, account_saft, l10n_cl_edi_export, l10n_co_edi, l10n_it_reports, l10n_lu_reports, l10n_mx_edi, l10n_mx_xml_polizas, l10n_nl_reports --- This commit modifies tests to adapt to the new behavior of the invoice lines' name not using the product name anymore. --- task-3888602 Community PR: https://github.com/odoo/odoo/pull/152869
The workspace settings menu in Documents now displays with the correct spacing after a Bootstrap update caused the layout to look broken. This keeps the menu readable and easier to use for users managing document workspaces.
Original PR description
Steps to reproduce 1. Click on the cog wheel menu of a workspace 2. The menu padding is broken Reason: Bootstrap library updated. After this commit: There is no broken wheel menu of a workspace. Task:3892891
Fixed a bug where validated timesheets could be inadvertently modified when updating sale order items in project settings. Now, once a timesheet is validated, it remains locked and cannot be changed, ensuring data integrity and consistency in billing records.
Original PR description
Steps to reproduce:
-------------------
- create a product:
- service
- based on timesheet
- create on order: project & task
- create a sale order with this product
- confirm the sale order
- go on the created task
- add timesheets with an employee
- go to timesheet
- validate created timesheets
- go to the project settings
- in invoicing tab, change de sale order item for the employee
Issue:
------
The sale order item linked to the validated timesheets are modified.
This behaviour causes negative side effects.
A validated timesheet should no longer be modified, but the backend logic does, which is not consistent.
Solution:
---------
Make the condition that filters timesheets to update take account of whether the timesheet is validated or not.
opw-3791062
Forward-Port-Of: odoo/enterprise#62856
Forward-Port-Of: odoo/enterprise#61122This fix allows businesses to set up multiple payment acquirers (payment methods) for the same company, each linked to different journals. Previously, when duplicating a payment acquirer, both copies would be linked to the same journal, causing visibility and functionality issues. Now companies can properly configure separate payment methods for different business needs.
Original PR description
The payment acquirer must always be linked to a single journal, one per company. It's currently an hard constraint So after the duplication, both are always linked to the same journal but only one appear on it. This "fix" is improving that allowing the duplication of an existing acquirer and to be able to link them to diffe opw-3704407 Forward-Port-Of: odoo/enterprise#62744
This fix prevents the VoIP system from crashing when receiving incoming calls from providers that include empty video tracks. The system now properly checks if a video track exists before attempting to enable it, ensuring calls can be received without interruption.
Original PR description
__Current behavior before commit:__ When there is an incoming call, a VoIP provider may give a session description containing an audio sender and a video sender even if the video track is empty. In such case, `track` may be `null`. Therefore the page will crash when we try to set `track.enabled`. __Description of the fix:__ Check if each track is not `null` before setting its `enabled` property. opw-3833811
This fix corrects how the system calculates the number of months worked for Belgian payroll commission computations. Previously, when employees changed positions, their prior work history wasn't being counted, which resulted in zero months being recorded and commissions not being added to their pay. Now the system properly includes all previous occupations in the calculation.
Original PR description
The number of months worked in the previous year was not including previous occupations. Thus, the commissions were not added as the number of months was 0.
Fixed a test in the mail module that was failing inconsistently when custom modules were installed before the mail enterprise module. The fix narrows the test to check only the Studio module's custom code metrics, which remain consistent across different installation scenarios. This ensures tests pass reliably regardless of what other custom modules are present.
Original PR description
Since the commit https://github.com/odoo/enterprise/pull/52348/commits/5c11c94b972d1993de4147d96fc3faaaaddc7c57 a test has been added that check the cloc result it stored on a ICP. But the result can be a bit different then expected during custom build if custom module are installed prior mail_enterprise. Solution: Check only the value of odoo/studio module that give the custom line in database that should be always empty during installation Forward-Port-Of: odoo/enterprise#63108 Forward-Port-Of: odoo/enterprise#62909
This update fixes an issue where the automatic invoice sending feature wasn't working correctly when companies were involved. The system now properly handles company-specific product information when the automated process runs, ensuring invoices are sent reliably across multiple company setups in Brazil.
Original PR description
l10n_br_edi_services defines l10n_br_property_service_code_origin_id on product.template. It's a property field, so to ensure it's read correctly by ir_cron_account_move_send that runs as OdooBot we explicitly set the company for the entire flow. Although not strictly needed in l10n_br_edi, fixing it here is the cleanest and most complete. The *_services modules will be merged into the main ones anyway. task-3887264
This fix resolves a technical error in the Mexican electronic invoicing system for stock transfers. The system was failing to properly calculate a required field in certain situations, causing the application to crash. This update ensures the calculation completes successfully in all scenarios.
Original PR description
In certain scenarios, the `_compute_l10n_mx_edi_idccp()` method does not assign a value to its related field. This omission results in a traceback because non-stored computed fields must be assigned a value by the end of their compute method's execution. opw-3923109 Forward-Port-Of: odoo/enterprise#62533
This fix corrects a bug where manufacturing orders created using barcode scanning were calculating component quantities incorrectly when different units of measure were used. The system now properly converts between units of measure (for example, grams to kilograms) when processing barcode scans, ensuring accurate inventory tracking and order fulfillment.
Original PR description
Issue: ====== Creating a MO with barcode uses the wrong quantity for the components. Steps to reproduce the issue: ============================= - Install mrp , barcode - Activate unit of measure - Create a product and assigna barcode number to it - Create a BoM for that product with a component `comp` - The `comp` product have `g` as unit of measure - Assign the unit of measure in the BoM for the `comp` as `kg` - Go to barcode -> operations -> manufacturing - Create a new order - Enter barcode manually of the product that you set up early - Click on +1 button - You can see the quantity is wrong as and not counting the difference of UoM Solution: ========= We need to fetch the uom data of the move to compare it to the one of the product and update the quantity accordingly. opw-3776896 Forward-Port-Of: odoo/enterprise#59131
This fix corrects how sub-workspace names are displayed in the Documents module. Previously, when viewing a list of workspaces, sub-workspaces were not showing their parent workspace name in the display, making it harder to identify the workspace hierarchy. The fix merges two conflicting display name calculation methods to ensure parent workspace names are properly included in sub-workspace names.
Original PR description
Steps to reproduce: ------------------- - Install `Documents` module - Go to Documents -> Configuration -> Workspaces - Create a workspace with a sub workspace - Go to list view Issue: ------ The display name of the sub workspace is not correct; It should also add the parent workspace name in the display name. Cause: ------ The following commit added a second `_compute_display_name` method that override the flow that add the parent workspace to the sub workspace name. https://github.com/odoo/enterprise/commit/ca7efce8f7bdb497f39a8438b5c266a7861d9a92 Solution: --------- Merge the 2 `_compute_display_name`. opw-3835887 Forward-Port-Of: odoo/enterprise#62759
This fix resolves an error that occurred when printing delivery slips for kit products with components measured in different units (like kilograms). The system was incorrectly trying to convert component quantities to packaging units, which caused the delivery slip to fail. The fix ensures kit components are handled properly during delivery slip generation.
Original PR description
Steps to reproduce: - Create a kit with components Uom set as Kg - Create an SO for the kit using packaging - Validate the delivery and try printing the delivery slip ERROR Bug: when generating the delivery slip we convert movelines qty to the packaging Uom but in the case of a kit the movelines are those of the components (in this we're converting Kg to units) Fix: Ignore kit lines (will be removed any way in _get_aggregated_product_quantities) opw-3758203
This fix resolves an issue where appointment availability slots were incorrectly showing as unavailable at the end of business hours (like 11pm-12am). The system was treating tiny 1-minute gaps between time slots as unavailable periods, which blocked legitimate appointment times. Now these minimal gaps are ignored, allowing customers to book appointments throughout the full business day including the final hour.
Original PR description
Current behavior: --- When looking at an appointment availability, slots are missing (ie: 11pm-12am) Steps to reproduce: --- 1. Install website_appointment 2. Go to Appointment 3. Select/Create a…
Current behavior: --- When looking at an appointment availability, slots are missing (ie: 11pm-12am) Steps to reproduce: --- 1. Install website_appointment 2. Go to Appointment 3. Select/Create a resource appointment 4. Make sure resources use the default calendar 5. In schedule, change 'To' to midnight (00:00) 6. Click on 'Go to Website' 7. Select the next day 8. Should be available until midnight 9. => slots missing Cause of the issue: --- When computing unavailabilities with _unavailable_intervals_batch, it takes all available slots: 12am-11:59am, 12pm-11:59pm then finds intervals between slots: 11:59am-12pm 11:59pm-12am These 1-minute intervals invalidate their respective slot => the slots 11am-12pm and 11pm-12am will show as unavailable Fix: --- Don't consider intervals that are one minute or less as unavailable Enterprise PR: https://github.com/odoo/enterprise/pull/61403 opw-3861561 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix enables the "Error amount too high" message in the Point of Sale sales management screen to be translated into different languages. Previously, this error message was hardcoded and could not be translated, limiting usability for non-English users. The fix adds the necessary translation wrapper to allow this message to appear in the user's preferred language.
Original PR description
In order for some text in the JavaScript code to be translatable, it must be wrapped in a call to _t. The title of a popup in the "sales management screen" missed this call to _t, preventing it from being translated. This commit fixes the problem by adding the missing call to _t. opw-3908751 Forward-Port-Of: odoo/odoo#165499 Forward-Port-Of: odoo/odoo#165337
This fix prevents validated timesheets from being modified when project settings are changed. Previously, when a user changed the sale order item assignment in project invoicing settings, it would incorrectly update timesheets that had already been validated. Now the system properly respects the validated status and prevents these modifications, ensuring data consistency and preventing unintended changes to finalized timesheet records.
Original PR description
Steps to reproduce:
-------------------
- create a product:
- service
- based on timesheet
- create on order: project & task
- create a sale order with this product
- confirm the sale order
- go on the created task
- add timesheets with an employee
- go to timesheet
- validate created timesheets
- go to the project settings
- in invoicing tab, change de sale order item for the employee
Issue:
------
The sale order item linked to the validated timesheets are modified.
This behaviour causes negative side effects.
A validated timesheet should no longer be modified, but the backend logic does, which is not consistent.
Solution:
---------
Make the condition that filters timesheets to update take account of whether the timesheet is validated or not.
opw-3791062
Forward-Port-Of: odoo/odoo#166162
Forward-Port-Of: odoo/odoo#162558This fix allows businesses to set up duplicate payment providers (like Authorize.Net) with different journals and currencies within the same company. Previously, when duplicating a payment provider, both copies would be linked to the same journal, preventing users from accepting payments in different currencies. Now each duplicate can be independently configured with its own journal and currency.
Original PR description
Issue: - unable to set up different journals on duplicated payment providers. - As a result, customers cannot set up different currencies for the same payment provider in one company database. A very common case with Authorize.Net -> for each currency, a different account needs to be created: USD and CAD.The customers are unable to set up different journals on a payment provider. Steps To Reproduce: - Under one company duplicate a payment acquirer. - Try to set a different journal per each duplicate. - Notice changing journal on one acquirer changes it on the duplicate. Solution: - WIP Ticket [link](https://www.odoo.com/web#model=project.task&id=3704407) opw-3704407 Forward-Port-Of: odoo/odoo#165589 Forward-Port-Of: odoo/odoo#154351
This update fixes a performance issue in the web editor where the system was continuously performing unnecessary calculations when users moved their mouse in the editing area. The problem occurred when a mouse click was released outside the editable area but the system didn't properly register this action. By fixing this tracking mechanism, the editor now runs more efficiently and responsively.
Original PR description
Description of the issue this PR addresses: Previously, if a mouseup event occured outside the editable area, `currentMouseState` remained as mousedown, causing unnecessary calls to `_handleSelectionInTable` and some other functions such as `getDeepRange`, `getDeepestPosition`, `ancestors`, `closestElement`, etc., during mousemove in editable area. This commit makes sure that when a mouseup event happens outside the editable area, `currentMouseState` is updated to mouseup, preventing these unnecessary calls. Forward-Port-Of: odoo/odoo#166342
Fixed an issue where inactive product variants were incorrectly displayed in the Point of Sale variant selection popup. Now only active variants appear, making the POS experience consistent with the Sales quotation workflow where inactive variants are not available for selection.
Original PR description
Currently, if you select a product that has variants, the popup window to choose the variants shows both active and inactive variants. Steps to reproduce: ------------------- * Make a quotation with…
Currently, if you select a product that has variants, the popup window to choose the variants shows both active and inactive variants. Steps to reproduce: ------------------- * Make a quotation with the product `Desk Organizer` and select `Plastic` as its variant -> Confirm * Go to **Products** * Select `Desk Organizer` * Go to `Attributes & Variants` * Remove the `Plastic` option > The variant is now inactive * Go to the **Point of Sale** App * Open a shop session * Select the `Desk Organizer` product > Observation: the `Plastic` variant is shown Why the fix: ------------ We compare the workflow with sales, when doing a new quotation with the `Desk Organizer` product, the inactive variant is not an option to select. We now load the information about attribute values being active or not when loading the data to the POS Session. All attributes that are inactive will not be shown in the product configurator. opw-3713374 Forward-Port-Of: odoo/odoo#166373 Forward-Port-Of: odoo/odoo#165110
This update adjusts the color of placeholder text in web forms to be lighter and more visually distinct from regular text. Previously, placeholder text used a gray color that was too similar to regular body text, causing potential confusion for users. The change makes placeholder text appear lighter to improve clarity and user experience.
Original PR description
This PR aims to decrease a bit the contrast of placeholder textin order to avoid confusion with regular text. Prior to this PR, placeholder texts were using a gray value from the grayscale, which was very similar to the `$body-color` in some context. To fix that issue, the color of the placeholder has been reduced to make it lighter, even though it doesn't meet `3.5:1` contrast ratio. task-3686510 - requires https://github.com/odoo/enterprise/pull/62029 Forward-Port-Of: odoo/odoo#166581 Forward-Port-Of: odoo/odoo#164510
This fix ensures that the request stack is properly cleaned up even when errors occur during request initialization. Previously, if an error happened during the request setup process, the system could be left in an inconsistent state, causing unrelated requests to fail with missing session information. This change prevents those cascading failures by guaranteeing proper cleanup in all scenarios.
Original PR description
**Impacted versions:** - 17.0 - 16.0 **Description of the issue/feature this PR addresses:** The addition of `request._post_init()` in #104573, introduced the possibility that `_request_stack.pop()`…
**Impacted versions:** - 17.0 - 16.0 **Description of the issue/feature this PR addresses:** The addition of `request._post_init()` in #104573, introduced the possibility that `_request_stack.pop()` is not called after `_request_stack.push(...)` was called before. This would happen in the case if request._post_init() raised an Exception. Even though with the standard `SessionStore` this is extremely unlikely to happen the possibility remains. In any case, one shouldn't set the expectation that `request._post_init()` isn't allowed to raise, therefore by moving the function call into the try block, it makes sure that `_request_stack.pop()` is called in the finally block. **Current behavior before PR:** If `request._post_init()` raises an Exception, `_request_stack` is left in a polluted state. This can cause issues during RPC-Calls, since during an RPC-Call, the request in `_request_stack` is borrowed with the expectation that `_request_stack` is empty. This can cause issues further down the line for completely separate requests which may break here: https://github.com/odoo/odoo/blob/4b6dea23a04d7b5317a94e75c8a670de82762276/odoo/addons/base/models/ir_qweb.py#L879 It breaks because, `request` will not be `None` (as would be expected due to borrowing) but `session` is not set on the `Request` object since that only happens if `_post_init()` succeeds. This results in the following error for completely unrelated requests going forward: ``` AttributeError: 'Request' object has no attribute 'session' ``` As a side-note, in our environment this happened likely due to using [camptocamp/odoo-cloud-platform/session_redis](https://github.com/camptocamp/odoo-cloud-platform/tree/16.0/session_redis). I did a write-up of the specific issue I ran into myself and reproduction steps here: https://gist.github.com/Jenjen1324/81d3547e5713ba253b67970bc8388147 I'm also not sure if there might be any security implications leaving a *partially* constructed object in this stack. **Desired behavior after PR is merged:** It is no longer possible to have a broken request hanging on in `_request_stack`, be it in stock Odoo or with customizations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166524
This fix corrects how section subtotals are calculated in sales order reports. Previously, the system was including all order lines in the subtotal calculation, but now it only counts the lines that actually appear on the printed report. This ensures the subtotals displayed to customers match the items shown on their documents.
Original PR description
Fix the section subtotal on the 'report_saleorder_document' to consider the lines displayed on the report ('lines_to_report') instead of all the sale order lines
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#166558