Tuesday, January 16, 2024
19 changes
1 change
Resolved issues and error corrections
Field service product availability reports now show the warehouse tied to the sales order, or the user's default warehouse when no sales order warehouse is set. This helps teams see accurate stock forecasts for the relevant warehouse instead of defaulting to the first warehouse created.
Original PR description
In a FSM project, when using the `products` smart button, then `view availability` in the 3-dots menu, the warehouse displayed was always the first created one. The warehouse displayed should be related to which is defined on the SO or the current user one if missing. If user's default is also missing, we use the warehouse that have the lowest sequence (and that belong the the task's company). To reproduce behavior: - Install `industry_fsm_stock` - Create second warehouse (WH2) - Assign the new warehouse (WH2) to current user - Open a project in FSM app - On `Products` smart button, check the availability of a product. The displayed forecast report should be the base warehouse (YourCompany) task-3522292
18 changes
Enhancements to existing features
Knowledge articles now display status indicator buttons that show users when their changes have been saved to the database. Users can see at a glance whether their edits are pending or saved, and can quickly discard changes if needed. This brings Knowledge in line with other Odoo forms for a consistent user experience.
Original PR description
This commit aims at adding the status indicator buttons that are present in most other Odoo Form views to Knowledge. These indicators enables the user to know when changes has been taken into account and can be saved inside the DB, either using the buttons or using other methods. This also enables the user to discard any changes he'd done to the article quickly. task-3609594 COM PR: odoo/odoo#145928
This update adds comprehensive automated tests for the Field Service Management module's date widget and calendar/gantt views to ensure reliability. Additionally, outdated field references have been cleaned up and replaced with current naming conventions, improving code maintainability and reducing technical debt.
Original PR description
Added JS tests for the following: - fsm_date_widget - fsm_task_calendar_view - fsm_task_gantt_view (patched TaskGanttController) Also refatored fsm_date_widget planned_date_end deprecated references (to date_deadline) Task-3661094
The OWL web framework library has been updated from version 2.2.7 to 2.2.9, bringing performance improvements and enhanced functionality. The update includes optimizations to reactivity handling and parser improvements, with corresponding adjustments to related tests to ensure compatibility.
Original PR description
Update the OWL lib and adapt some tests/helpers. Release notes: https://github.com/odoo/owl/releases/tag/v2.2.8 https://github.com/odoo/owl/releases/tag/v2.2.9 These releases contain small improvements 2.2.8: - [IMP] template set config: getTemplate function - [IMP] parser: .trim modifier implies .lazy modifier - [REF] parser, template_set: factor out parseXML function 2.2.9: - [IMP] reactivity: replace sets with small arrays for performance Forward-Port-Of: odoo/odoo#149379 Forward-Port-Of: odoo/odoo#149170
Resolved issues and error corrections
This update fixes a technical issue in the account reports module where certain fields were using an incompatible data type that caused errors. The fix converts these fields to a compatible text format, ensuring the analytics reporting feature works correctly without disruptions to users.
Original PR description
There is a field type 'reference' whose column type is 'varchar', but as reference is not a data type; it raises the traceback: "type 'reference' does not exist". So converted that reference field type to a text data type manually, as done for selection. reference: https://github.com/odoo/odoo/blob/60a3e7f9261bbf0b26cf815133bafd7628bc4133/odoo/fields.py#L2829 opw-3633753 Forward-Port-Of: odoo/enterprise#53482
This fix prevents users from editing the "days spent" field in validated timesheets. Previously, when timesheets were marked as validated, the days spent field remained editable when it should have been locked. The fix corrects the validation logic to properly protect validated timesheet data from accidental modifications.
Original PR description
Steps to Reproduce: - install timesheets - go to cofiguration - under time encoding - enable Days/Half-Days option - click on all timesheets, go to kanban view - select a record, click on validate Issue: - in validated timesheet the days spent field is editable, days spent should not be editable in validated timesheet. Cause: - while giving attributes to the unit_amount field, the conditions checking for readonly will cause the error. Solution: - if we gave the conditions properly,then the issue will be solved. task-3627670 Forward-Port-Of: odoo/enterprise#52373
When users view subscription records from a spreadsheet dashboard, they now see a simplified form view that makes it easy to navigate to the related sales order. Previously, clicking on a subscription record would display an unusable auto-generated form with too many fields. This fix provides a better user experience by creating a minimal, focused form view.
Original PR description
Let's say a `sale.subscription.report` list is inserted into a spreadsheet (e.g. in the Subscriptions dashboard). Right click on one of the list cells and click on "See record". It opens an auto-generated form view which is unusable. Ideally we would want to be redirected to the related sale order form view. That's what is done when click on a `sale.subscription.report` in the list view. It's done with `action="action_open_subscription_order"` on the list arch. Unfortunatly, we don't have such a mechanism to overwrite the action for lists in spreadsheet. So, in this commit, we introduce a minimal form view allowing to go the sale order, without having to find the field among the many many fields in the auto-generated form view. Task: 3680601
When users duplicate a published shift in the Planning module, the system was incorrectly creating a new published stage instead of assigning the duplicate to an existing stage. This fix prevents the stage field from being copied during shift duplication, ensuring duplicated shifts are properly assigned without creating duplicate stages.
Original PR description
Versions:
---------
saas-16.4
Steps:
---------
- Installed planning module
- Open Planning
- Create shift and published
- copy the shift
Issue:
---------
When we copy the published shift, a new shift published stage is created.
Cause:
---------
Copy true is given in the stage field, so the stage of the new shift is copied.
Fix:
---------
Prevent copying the status field when duplicating shifts.
task-3524295
Forward-Port-Of: odoo/enterprise#48614This fix resolves a problem that occurred when upgrading databases from version 15 to 16 with active subscriptions. Previously, orders that created subscriptions could not be updated without triggering validation errors, preventing users from invoicing new products. The fix allows these legacy orders to be properly updated by adjusting how the system validates subscription constraints.
Original PR description
Before this commit, when a database was upgraded from 15 to 16 with subscription, the sale.order that created the sale.subscription records (O1) could not be updated without triggering the…
Before this commit, when a database was upgraded from 15 to 16 with subscription, the sale.order that created the sale.subscription records (O1) could not be updated without triggering the subscription python constraint preventing to have a recurring product and no recurrence. These order when confirmed created the sale.subscription records. During the upgrade, they were linked to the sale.subscription records migrated to sale.order record (O2) with the subscription_id o2m field and their subscription_management field remained identical (empty or 'create' value). After confirmation if these O1 records where updated to deliver non recurring products for example, it was impossible to update the line and invoice the remaining newly delivered products because they would trigger the python constraint. This commit exclude them based on their values: they have a subscription_id value but no subscription_management value. opw-ticket: 3634253 Forward-Port-Of: odoo/enterprise#54272 Forward-Port-Of: odoo/enterprise#53081
This update corrects the payment reference information used in Belgium's Form 274 payroll declaration. The fix ensures that payroll declarations are submitted with the correct payment reference details, which is important for compliance with Belgian tax and payroll regulations.
Original PR description
Forward-Port-Of: odoo/enterprise#54194
This fix resolves a display problem in the Field Service module where tabs and columns appeared too small when added to worksheet templates. The issue occurred because these elements were being placed inside comment fields, which have a grid layout that compressed their size. The fix restricts tabs and columns from being placed in comment fields, allowing them only in appropriate locations like sheets and groups, resulting in proper sizing and better template design experience.
Original PR description
Steps: Open the Field Service module. Go to configuration. Open worksheet templates. Select any worksheet template and click on "Design Template". Drag and drop tabs or columns inside the comments field. The size of tabs/columns appears very small. Issue: When dragging and dropping tabs or columns inside the comments field, the size of the tabs/columns appears very small. Cause: This issue occurs because tabs and columns are allowed inside the comments field. Inside the comments field, there is a grid, which reduces the size of tabs and columns. Fix: It is unnecessary to allow tabs and columns inside the comments field. We should restrict them from being placed inside the comments field. Tabs and columns should be allowed inside sheet and after group. task-3631285 Forward-Port-Of: odoo/enterprise#53913 Forward-Port-Of: odoo/enterprise#49034
A previous update inadvertently broke the validation that checks if all website snippets are properly configured. The fix corrects the selector used in the validation test to properly identify and verify all draggable snippets, ensuring the system accurately detects any configuration issues instead of silently passing invalid checks.
Original PR description
[Commit 1](https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76) changed the class from .ui-draggable to .o_draggable in the snippet_version test, specifically in the run function that checks if all snippets have their data-snippet properly set. Indeed, .o_draggable is set on the parents of draggable elements and not on the elements which are draggable themselves. This lead to a `.every` on an empty array which returns true, and therefore avoids the console.error but did not properly check the snippets. This commit changes the selector to all snippets which do not have a [data-module-id] which should be all snippets that are draggable. [1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
This update corrects how Anglo-Saxon accounting is configured across multiple localization modules. The setting was being stored in the wrong location and has been moved to the proper company field. This ensures accounting practices are correctly applied for companies using Anglo-Saxon accounting methods.
This update significantly improves the performance of deleting records (such as sales orders) in large databases. Previously, deletion operations could take up to 1 second; after this fix, the process is now much faster. This enhancement reduces system slowdowns when users delete records in the mail and messaging system.
Original PR description
**Description of the issue/feature this PR addresses:** In large database, the time to unlink a sale.order (or any record with mail.thread) can be take 1 seconde. After it is so fast. @tde-banana-odoo @rco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149166
The spreadsheet application has been updated to version 17.0.7 with several important fixes. These updates address date and time handling issues to ensure dates are properly represented in UTC, improve type checking for functions, and fix naming conventions. This ensures the spreadsheet feature works more reliably and consistently.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/cadb8174b [REL] 17.0.7 https://github.com/odoo/o-spreadsheet/commit/548c779ba [FIX] dates: use UTC to represent naive date times Task: 3666703 https://github.com/odoo/o-spreadsheet/commit/49f05a71c [REF] dates: introduce DateTime to wrap Date object Task: 3666703 https://github.com/odoo/o-spreadsheet/commit/9676b76b7 [FIX] date: properly type reference dates Task: 3666703 https://github.com/odoo/o-spreadsheet/commit/653a0900f [FIX] tests: enables type checking for binded functions https://github.com/odoo/o-spreadsheet/commit/61780b4e4 [FIX] functions: name MID args
This fix resolves an issue where customers trying to request an invoice from a POS order QR code would encounter an error when the system had multiple companies configured. The problem occurred because the system was using the wrong company context when processing the invoice request. Now the system correctly uses the company associated with the POS order, ensuring invoices can be generated successfully.
Original PR description
Have company 1 (main company) and company 2 Activate Website for company 1 Switch to company 2 Setup a POS In Settings > Point of Sale, activate 'Use QR code on ticket' Open POS session Make an…
Have company 1 (main company) and company 2 Activate Website for company 1 Switch to company 2 Setup a POS In Settings > Point of Sale, activate 'Use QR code on ticket' Open POS session Make an order, save qr link from receipt, close session Open the saved link without being logged in Complete form and request invoice Issue: Error will block the operation ``` Incompatible companies on records: - '/ (Reversal of POS closing entry POSS/2024/01/0004 for order Shop/0004 from session POS/00002) 16%' belongs to company False and 'Account' (account_id: '209.01.01 VAT carried forward not collected') belongs to another company. - '/ (Reversal of POS closing entry POSS/2024/01/0004 for order Shop/0004 from session POS/00002) 16%' belongs to company False and 'Originator Tax Distribution Line' (tax_repartition_line_id: 'account.tax.repartition.line,54') belongs to another company. - '/ (Reversal of POS closing entry POSS/2024/01/0004 for order Shop/0004 from session POS/00002) Acoustic Bloc Screens' belongs to company False and 'Account' (account_id: '401.01.01 Sales and/or services taxed at the general rate') belongs to another company. - '/ (Reversal of POS closing entry POSS/2024/01/0004 for order Shop/0004 from session POS/00002) Acoustic Bloc Screens' belongs to company False and 'Taxes' (tax_ids: '16% (MX)') belongs to another company. - '/ (Reversal of POS closing entry POSS/2024/01/0004 for order Shop/0004 from session POS/00002) 105.01.02 105.01.02' belongs to company False and 'Account' (account_id: '105.01.02 National customers (PoS)') belongs to another company. ``` This occurs because when Website is installed, requests from public user will keep in context the id of the company associated to the website, company 1 in this case. opw-3629683 Forward-Port-Of: odoo/odoo#149061
This update fixes a display issue in the CRM enrichment feature where tags become unreadable when dark mode is enabled. The tags' text was appearing in light color on a light background, making them illegible. The fix applies appropriate styling to ensure tags remain readable in dark mode.
Original PR description
In the lead's enrichment, the fields containing tags have an hardcoded background for some reason... which, in dark mode, makes the tags' label illegible (as it is a light text on light background). This commit fixes it by forcing a darker gray when rendered in dark mode (where the dark mode's bundle is applied, like in the backend). Steps to reproduce: - Open CRM - Create an opportunity using a well-known domain in the email address (for example) - Click "Enrich" - A card appears in the chatter containing the matching company's information - Switch to dark mode => Sectors, Technologies Used... tags keep the light background opw-3678598 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a formatting issue with invoice previews when downloading them. Previously, the totals table would appear misaligned (pushed to the right) in downloaded invoices, even though it displayed correctly in the preview and HTML views. This fix ensures invoices look consistent across all viewing methods.
Original PR description
Before this commit, the `report_invoice_wizard_preview` was rendered well in html and in the preview (settings page) but not when downloading it ; the "total" table was pushed all the way to the right. opw-3648586 Forward-Port-Of: odoo/odoo#148337
This fix enables users to process stock transfers between companies using automated push rules, even when they only have access to the first company. Previously, the system would block these multi-company transfers. Now, when a user confirms a transfer to an intercompany location, the system automatically creates and processes the corresponding stock movement in the receiving company.
Original PR description
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
Original PR description
The anglo saxon accounting was set in the wrong field. It should be set in the field 'anglo_saxon_accounting' on the company and not 'use_anglo_saxon' on the configs. task-3642826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149021 Forward-Port-Of: odoo/odoo#148868