Friday, May 24, 2024
25 changes
2 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/166687The 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
23 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
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.
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 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 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#166558This update resolves a technical issue with how the system compares different types of date and time values. The fix ensures that the base module correctly handles comparisons between naive and timezone-aware datetime objects, preventing errors that could occur during file operations and HTTP requests.
Original PR description
Fine tunning of 447ac7fb97b5 Forward-Port-Of: odoo/odoo#166483
This update fixes a bug in Stripe Express Checkout that was causing errors when customers attempted to complete payments. The issue occurred because recent code updates weren't properly adapted to use the latest payment processing method, which has now been corrected to ensure smooth checkout experiences.
Original PR description
In september 2023 7422eb643c5922bde8c70edfbe7b6f8dad53c1d9 replaced
this._rpc by `this.bindService("rpc")`.
In may 2024 58324ee59946c7bfe9970b5202cce8d4a36a69b0 was
forward-ported without adaptating it to the new way rpc is used.
This is causing report of an error in some case when using stripe
express checkout.
note: in saas-17.1 the code has to be changed again to `await rpc`.
opw-3917632This fix resolves a system crash that occurred when viewing vendor on-time delivery rates after cancelling items in a purchase order. The issue happened because the system tried to calculate delivery performance metrics for products with zero quantities, causing a calculation error. The fix ensures that cancelled or zero-quantity items are properly excluded from the on-time rate calculation.
Original PR description
### Steps to reproduce: - Create a PO: - 1 x storable product 1 - 1 x storable product 2 - Confirm the PO - Change the quantity of the PO line of product 1 to 0 (this modifies the associated delivery…
### Steps to reproduce: - Create a PO: - 1 x storable product 1 - 1 x storable product 2 - Confirm the PO - Change the quantity of the PO line of product 1 to 0 (this modifies the associated delivery accordingly) - Click on the customer to open the res.partner form - Click on the "On-Time Rate" smart button #### > Traceback: psycopg2.errors.DivisionByZero ### Cause of the issue: Clicking on that smart button will call the "_read_group" method and the following sql expression will be added to the associated query: https://github.com/odoo/odoo/blob/b4620c123b753caf2b77472a8d6c42d767471c53/addons/purchase_stock/report/vendor_delay_report.py#L57-L60 The error is therefore rasied because the SUM(qty_total) associated to product 1 was reset to 0 because of our change on the PO line. ### Fix: Since SUM(qty_total) of 0 signifies that no units of that product was not expected to be delivered for that customer. As such they should be removed from the products whose "On-Time Rate" is computed from the vendor.delay.report's. opw-3852055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162632
This fix ensures that when a user is linked to an employee, all existing timesheets for that employee are properly updated to show the new user assignment. Previously, timesheets created before a user was assigned to an employee would not appear in that user's timesheet view, causing confusion and missing time tracking records.
Original PR description
Steps to reproduce: ------------------- - create an employee at a time (E) - create a public holiday at some point in the future (PH) - create a user linked to the employee (U) With E < PH < U Issue: ------ The user has no timesheets linked to him/her, even though the employee was already present. As a result, the user does not see the timesheet in the timesheet grid. Solution: --------- Update the timesheet `user_id` field if an employee's user is modified. opw-3876732 Forward-Port-Of: odoo/odoo#166539 Forward-Port-Of: odoo/odoo#166189
This fix improves the payment registration process by automatically hiding the payment difference field when the difference amount exactly matches an early payment discount. This streamlines the reconciliation workflow and prevents confusion when discounts are applied, ensuring payments are properly matched without requiring manual adjustment.
Original PR description
When the Payment Difference amount equals Early Payment Discount, Don't show the payment difference field and consider full reconciliation. task-3944830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The spreadsheet component has been updated to the latest version (17.0.23) with several important fixes and improvements. This update addresses scroll issues on newer browsers, fixes clipboard functionality, improves translation handling, and enhances performance when working with merged cells. These changes ensure the spreadsheet feature works smoothly across different browsers and improves the overall user experience.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6c10fecf9 [REL] 17.0.23 https://github.com/odoo/o-spreadsheet/commit/62796cad0 [FIX] spreadsheet: fix scroll issue on chromium core 125 Task: 0 https://github.com/odoo/o-spreadsheet/commit/1bf375c14 [FIX] misc: Fix `deepEquals` behaviour Task: 3942782 https://github.com/odoo/o-spreadsheet/commit/ca535adc5 [FIX] translation: replace placeholders even if translation is not loaded Task: 0 https://github.com/odoo/o-spreadsheet/commit/a22fede71 [FIX] clipboard: wrong clipboard invalidation Task: 3901961 https://github.com/odoo/o-spreadsheet/commit/f8e04449d [PERF] merge: faster intersection with zone Task: 3924969 https://github.com/odoo/o-spreadsheet/commit/94c3bfc7a [FIX] Composer: F4 handler should not bubble out of the composer Task: 3916488
This update fixes a bug where link labels weren't being automatically saved when edited in the email marketing editor. Previously, when users changed a link's label and clicked outside the editor, the change would be lost. The fix ensures that link label changes are properly saved without interrupting the editor's tracking system.
Original PR description
Issue: ====== The label of link doesn't auto save. Steps to reproduce the issue: ============================= - Go to email marketing - Add text block - Select some text and convert it to link -…
Issue: ====== The label of link doesn't auto save. Steps to reproduce the issue: ============================= - Go to email marketing - Add text block - Select some text and convert it to link - Change the label of link from the link tools - Click on the top , outside the editable - The label sets back to it's original value Origin of the issue: ==================== `onSelectionChange` is called from the flow of `obeserverApply` which calls `deselectTable` here [1] and it deactivate the observer which clears `this.observerTimout` so `historyStep` don't get caled. Solution: ========= - We don't unactivate the observer when there are no `td` elements to process. [1]: https://github.com/odoo/odoo/blob/saas-16.3/addons/web_editor/static/src/js/editor/odoo-editor/src/OdooEditor.js#3931 --- Issue: ====== Traceback after discard mass mailing with selection Steps to reproduce the issue: ============================= - Create a new mass mailing - Choose the welcome template - Click outside the editable - Select the first paragraph in the template such that the toolbar appears - discard the record - traceback Origin of the issue: ===================== The flow goes as follows, create a new mass mailing, click outside the editable will trigger commitChanges, now we click again inside the editable, `activeSnippet` is called which will add some item to the list of snippetEditors in `SnippetsMenu`. Now clicking on discard will goes as follows, `onWillUnmount` will be called and we find the record dirty because the commited changes have already been cleared from `record.data` so we have 2 flows going in parallel , one for the commitChanges and one for the destroy which will be called in this order while running, commitChanges -> destroy -> observerUnactive -> observerFlush -> observerApply -> contentChanged -> updateCurrentSnippetEditorOverlay -> cover -> `ownerDocument.defaultView` but the docuemnt doesn't have a window anymore so its value is null thus the traceback. Solutions: ========== We add check on the default view to make sure it's not null before accessing it. task-3857016 Forward-Port-Of: odoo/odoo#166233 Forward-Port-Of: odoo/odoo#161845