Odoo Changelog — 2025-01-24

Friday, January 24, 2025

75 changes · saas-18.1

Improvements(1)

Enhancements to existing features

[IMP] orm: keep indexes without comments

PR #194735

Coresaas-18.1base

Upgrades will now keep existing database indexes when they have no recorded comment, instead of dropping and recreating them. This helps preserve customer-specific index changes and reduces unnecessary database work during upgrades.

Original PR description

Description of the issue/feature this PR addresses:
When upgrading, the team would like to keep existing modified indexes. Therefore, we will not re-create indexes that already exist and have no comments. We create the index only when the comment does not match or when the index does not exist.

Current behavior before PR:
If there is no comment, drop and re-create the index during the upgrade.

Desired behavior after PR is merged:
Keep the indexes during the upgrade.


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#upgrade#database#indexes

Bug Fixes(6)

Resolved issues and error corrections

[FIX] mail: no flicker on call video stream inset

PR #194013

Coresaas-18.1mail

Discuss calls no longer show flickering in the small video preview when a user is sharing their screen and has the camera enabled. This creates a steadier, less distracting call experience for users.

Original PR description

Before this commit, during a discuss call while sharing screen and enabling camera, the inset card (= small video stream preview in bottom right of call view of the participant, either camera or screen-sharing depending on other stream being main active) was flickering.

This happens because each rendering of the call view re-renders the inset, which leads to the perceived flickers from stream being re-rendered.

The main cause of re-render comes from `setInset()` that is invoked whenever the `visibleMainCards` getter is called with inset, which is triggered on renderings like mouse-hovering on call view to display the call actions. Even when the inset card is unchanged, `setInset()` produces another object, which forces OWL to re-render the inset component.

This commit fixes the issue by having `setInset` reusing the inset data object if the inset to render refers to the same inset session.

Task-4484908

Other(68)

Miscellaneous changes

[FW][FIX] im_livechat: livechat button loader template

PR #195067

Coresaas-18.1im_livechat

The livechat button loader template adds `websocket_worker_version` to the Odoo session. However, when the loader is called through `chatbot_test_script_page`, it does not receive the `websocket_worker_version`. In the standard Odoo environment, this value is already available in the session This fix ensures the `websocket_worker_version` is properly handled in scenarios involving `chatbot_test_script_page`. Task-4462067 --- I confirm I have signed the CLA and read the PR guidelines at

Original PR description

The livechat button loader template adds `websocket_worker_version` to the Odoo session. However, when the loader is called through `chatbot_test_script_page`, it does not receive the `websocket_worker_version`. In the standard Odoo environment, this value is already available in the session

This fix ensures the `websocket_worker_version` is properly handled in scenarios involving `chatbot_test_script_page`.

Task-4462067

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#193063

Description of the issue/feature this PR addresses: When upgrading, the team would like to keep existing modified indexes. Therefore, we will not re-create indexes that already exist and have no comments. We create the index only when the comment does not match or when the index does not exist. Current behavior before PR: If there is no comment, drop and re-create the index during the upgrade. Desired behavior after PR is merged: Keep the indexes during the upgrade. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit, during a discuss call while sharing screen and enabling camera, the inset card (= small video stream preview in bottom right of call view of the participant, either camera or screen-sharing depending on other stream being main active) was flickering. This happens because each rendering of the call view re-renders the inset, which leads to the perceived flickers from stream being re-rendered. The main cause of re-render comes from `setInset()` that is invoked whenever the `visibleMainCards` getter is called with inset, which is triggered on renderings like mouse-hovering on call view to display the call actions. Even when the inset card is unchanged, `setInset()` produces another object, which forces OWL to re-render the inset component. This commit fixes the issue by having `setInset` reusing the inset data object if the inset to render refers to the same inset session. Task-4484908

Currently when we validate a transfer with products tracked by serial number, we may run into a bottleneck when the `quality_mrp` module is installed. That's because there's 1 move_line by Serial Number and inside `_create_assign_production_lot` those move_lines are grouped by `(company_id, product_id, lot_name)`. As we are tracking by Serial Number, each of these group key will be unique. Also, the mls are grouped in key_to_mls using `__union__` which calls `browse` to produce a recordset, effectively setting the `_prefetch_ids` of the results to `_ids`. Therefore, in the sml `write` override in quality_mrp when there's a condition on `self.sudo().check_ids`, the `_prefetch_ids` of self will only be the id in self, leading to 1 SELECT query by SML, i.e. 1 SELECT query by serial number. This wouldn't be that much of an issue if `quality_check.move_line_id` was properly indexed but that's not the case. So this commit first adds a missing `btree_not_null` index on `quality_check.move_line_id` to change the query plan from Seq Scan to Index Scan. Then we manually set the `_prefetch_ids` in `_create_and_assign_production_lot` to reduce the number of queries. #### speedup In a 17 database with 750 000 quality checks, on hot cache, adding the index makes a single query go from ~50ms to 0.250ms. When doing a transfer of 1000 serial numbers, setting the `_prefetch_ids` reduce the number of queries from 1000 to 1. This query takes around 120ms on hot cache without the index. Both with the index and the `_prefetch_ids`, the total time of the `_create_and_assign_production_lot` method when validating a transer of 1000 serial numbers goes from 50ms * 1000 = 50s -> 2ms * 1 = 2ms. opw-4285293 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190479

## General Issue: Cross-dock rules cannot function as the main rule without disrupting unrelated flows (e.g., regular purchases). They also fail as exceptions, as they are not triggered in such cases. ## Cause: Push and pull rules have been refactored in saas-17.2 (see commit 11e69870db1c49d9a6af79ffd263e4e162b34b6b). Previously, most flows relied solely on pull rules, generating the entire picking chain at inventory need confirmation. With the refactoring, push rules are now prioritized, generating pickings step-by-step upon validation. While this increases route flexibility, it introduces issues for flows expected to be entirely triggered by sales order (SO) validations, such as cross-docking. In version 18.0, cross-dock rules were refactored to rely only on push rules (see commit af5479dfdbed0959c02bd862c8184fe141b51788), but this created significant issues. ### Steps to Reproduce: - In the settings, Enable multi-step routes. - Configure the warehouse for 2-step receipt and delivery > automatically unarchives the cross-dock route and updates its rules: - Push rule: Input → Output - Buy rule: → Partner/Customer #### Scenario 1: Cross-dock set on the product #### Issue: Cannot receipt in 2 steps → cross dock can not be the rule. - Create an inventory-tracked product with the buy and cross-dock routes. - Create and confirm a purchase order for 1 unit of the product. - Validate the receipt from Vendor → Input. Result: Instead of generating a picking Input → Stock, the cross-dock push rule triggers, generating a picking Input → Output. ### Cause: Rules are prioritized by product-specific rules, followed by warehouse rules: https://github.com/odoo/odoo/blob/e3d54695862f73d9be6c35121def57ed641a1a45/addons/stock/models/stock_rule.py#L535-L539 The cross-dock push rule therefore overrides regular 2-step receipt rules, even though cross-dock routes only make sense for flows initiated by an SO. #### Scenario 2: Cross-dock not set on the product #### Issue: Cannot trigger cross-docking by any means → cross dock can not be the exception. - Create an inventory-tracked product with only the buy route. - Create an SO for 1 unit of the product and set the cross-dock route on the Sales Order Line (SOL). Confirm the SO. > A purchase order (PO) is created. - Confirm the PO. > A regular receipt is generated. - Confirm the receipt. Result: The flow proceeds as a regular 2-step delivery; the cross-dock route is not applied. ### Cause: The SO uses the cross-dock route only for the buy rule to generate a PO. Once the PO is generated is role in this world is done. There is no way to provide a route on the PO, it will just generate a regular receipt: https://github.com/odoo/odoo/blob/e3d54695862f73d9be6c35121def57ed641a1a45/addons/purchase_stock/models/purchase_order_line.py#L343-L350 Once it is confirmed, the flow defaults to regular 2-step delivery rules, as the cross-dock route is neither a default nor set on the product. ### Fix: We add the possibility of transmitting the route_id from the pol. As such, we make it possible to use the crossdock route by setting it on the sol, to generate a PO that will pursue with the crossdock route. Furthermore, we discourage to use the crossdock route on products/product categories by setting the default setable values to False. opw-4380375 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192362

Adds a configuration that can be used to mitigate PostgreSQL transactional errors with long-living connections and the `LISTEN/NOTIFY`[^1] functionality by re-establishing the database connection periodically. In the case that a connection outlives the transaction wraparound[^2] mechanism of postgres, the `LISTEN/NOTIFY` internal queue might contain references to transactions that have already been deleted by the system's (or a manual) `VACUUM`[^3] as it has its own transaction validity mechanisms (roughly comparing transaction ids). This can be reproduced by: - Triggering a wraparound _AND_ cleaning of pg_xact between the cron's `LISTEN` + `COMMIT` and its recyling. - Having done at least one `NOTIFY` during that time period (?). - Try to `LISTEN` to the same channel on the same database (transcation id must be < than the first connection's transaction id). The following is an example error message: ``` ERROR database odoo.service.server: Worker (3194772) Exception occurred, exiting... Traceback (most recent call last): File "/home/user/odoo/service/server.py", line 1089, in run self.start() File "/home/user/odoo/service/server.py", line 1235, in start self.dbcursor.commit() File "/home/user/odoo/sql_db.py", line 480, in commit result = self._cnx.commit() ^^^^^^^^^^^^^^^^^^ psycopg2.errors.UndefinedFile: could not access status of transaction 1194816979 DETAIL: Could not open file "pg_xact/0473": No such file or directory. ``` [LISTEN/NOTIFY code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c) [Connection being kept](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L2167-L2191) [See more](https://www.postgresql.org/message-id/flat/VE1PR03MB531295B1BDCFE422441B15FD92499%40VE1PR03MB5312.eurprd03.prod.outlook.com#7e36d1fdca921b5292e92c7017984ffa) [^1]: https://www.postgresql.org/docs/current/sql-notify.html [^2]: https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND [^3]: https://www.postgresql.org/docs/17/sql-vacuum.html Forward-Port-Of: odoo/odoo#194937 Forward-Port-Of: odoo/odoo#194141

**Description of the issue/feature this PR addresses**: 1) It is necessay not to set "Existing Third Party Checks" outgoing payment method in all argentinean cash journals. It is only needed to be set on "Third Party Checks" and "Rejected Third Party Checks" Argentinean journals that are created when the module is installed or a new argentinean company is created. 2) Also when a user mistakenly remove the 'Existing Third Party Checks' payment method from the 'Third Party Checks' journal then is not able to add it back. This bug was introduced on this commit https://github.com/odoo/odoo/pull/188451/commits/0618fff9f9bb4716d22dc2ce8950cada824b90f4. **Current behavior before PR**: 1) "Existing Third Party Checks" outgoing payment method is set in all argentinean cash journals. 2) When a user mistakenly remove the 'Existing Third Party Checks' payment method from the 'Third Party Checks' journal then is not able to add it back. **Desired behavior after PR is merged**: 1) "Existing Third Party Checks" outgoing payment method is set only in "Third Party Checks" and "Rejected Third Party Checks" argentinean journals. 2) When a user mistakenly remove the 'Existing Third Party Checks' payment method from the 'Third Party Checks' journal then is able to add it back. _Ticket Adhoc side_: 83443 _Task Latam side_: 1309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194713

Description of the issue/feature this PR addresses: This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements. The issue it can solve happens when 2 different commercial entities use the same paying partner (ie a partner that is not a subcontact) to pay their invoices. When an invoice is paid by the paying partner, Odoo will store the account number that was used for the transfer on account.bank.statement.line. When this statement line is reconciled with an invoice, if the bank account was not stored on the partner previously, a res.partner.bank will be created automatically. When another payment is coming from the same bank account, Odoo will then select the partner linked to the bank account that it did store previously, even if the payment was for an invoice linked to another partner, and it will not propose the proper invoice in the reconciliation widget, even if it uses an exact match on the payment reference number. Having a parameter allowing to skip creation of the bank account in Odoo will allow the reconciliation to be based striclty on the reference number. Current behavior before PR: Bank account is stored and wrong invoices are proposed by the reconciliation widget Desired behavior after PR is merged: Allow to avoid storing bank account and having wrong invoices are proposed by the reconciliation widget --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173546 Forward-Port-Of: odoo/odoo#168029

[FIX] documents, documents_hr: fix company folder protection How to reproduce: - install documents_hr - In Document, create a folder prjComp2 in /Marketing/Brand 2 - create a second company: SecondCompany - Select SecondCompany - Activate centralization of document for HR and select prjComp2 folder - Log as Marc Demo and delete the folder Brand 2 (Move to Trash + delete) There is no error while this folder should have been protected by the method _raise_if_used_folder called when archiving or deleting a folder. The cause is that Marc user doesn't have access to SecondCompany and as the check is not done in sudo in _raise_if_used_folder, the folder is not identified as a folder to be protected. We solve the issue by running the check in sudo. Technical note: the protection mechanism is defined in the documents app but tested in documents_hr because there is no company folder defined in documents that could be used in a test. [FIX] documents,documents_project: fix document deletion How to reproduce (Move to the Trash): - Install documents_project - Remove any access to the project folder (except to Mitchel Admin) - Login as Marc Demo - Upload a file in Marketing - Move that file to the Trash You get an access error while you should be able to move that document to the Trash. How to reproduce (Delete): - install documents_project - Login as Marc Demo - Upload a file in Marketing - Move it to the Trash - Remove any access to the project folder (except to Mitchel Admin) - As Marc Demo, go to the Trash and delete the document You get an access error while you should be able to delete that document. We solve the problem by doing the check in sudo (in unlink_except_project_folder). Technical note: We haven't done that test in documents (where there are already delete tests) because we had to change the test so that they are executed after all the modules are installed and that cause query count issue in performance tests. Task-4480581 Forward-Port-Of: odoo/enterprise#77162

Several things addressed on the details panel. A. When editing a previewed document, no data was saved. When editing a previewed document, no data was saved. Reproduce: 1. Without selecting any document, open a preview 2. Rename the document or add a tag 3. Close the preview 4. Reload the page 5. See that changes were not saved BTW, tags could not be created from the inspector, it's not clear why. Technical note: for previewed record, that are not "selected" when we update them, we need to force saving immediately. For records that are selected, we can leave the webclient behavior for saving records (urgent save). This can lead to having tracked fields being immediately reported (seen in chatter) when editing previewed documents but not the others. This is acceptable for simplicity. B. When showing data for the current folder opened, the contact info was missing (partner_id). Reproduce: 1. Go inside any folder 2. Without selecting any documents, add a contact to the current folder via the details panel 4. Reload the page 5. The partner doesn't show up in the field (even though it is updated on the record). C. U pdate previewed document only Reproduce: 1. Select two records 2. Preview one of them 3. Change a value in the details panel 4. Both records were modified instead of the previewed one only We're also fixing the removal of the correct documents from the kanban view when documents are moved and making sure we do not try to edit this document again as it could likely not be in the view anymore at all. Task-4465443 Forward-Port-Of: odoo/enterprise#77136

#### Issue: - When an employee is assigned a resource calendar with the `flexible_hours` option enabled, the daily/weekly overtime on the timesheet calendar is not calculated based on the 'Average Hour per Day' that we set for the flexible resource, it is instead being calculated based on the specific work intervals. #### Steps to reproduce: 1. Assign a resource calendar with `flexible_hours` enabled to an employee. 2. Ensure the calendar has a defined `hours_per_day` value. 3. Verify that the timesheet grid correctly shows the daily/weekly overtime hours as per `hours_per_day`. 4. Test with non-flexible schedules to confirm existing behavior remains unchanged. #### Solution: - In the frontend, the method `fetchDailyWorkingHours` retrieves daily working hours data by calling the backend method `get_daily_working_hours`. - This method computes working hours based on the employee's `resource_calendar_id` and its associated work intervals. However, It does not check if the `flexible_hours` flag is enabled on the `resource_calendar_id`. For employees with flexible schedules, the backend still calculates working hours based on detailed intervals instead of simply using the `hours_per_day` value defined in the `resource_calendar`. - To fix this I ensure we respect flexible schedules by using `hours_per_day` directly when `flexible_hours` is enabled. opw-4407910 Forward-Port-Of: odoo/enterprise#77315

Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded. Steps to reproduce: ------------------- * Create a new customer, make a sale order and invoice it. This will set an amount due for that customer * Connect to the shop with a user that has the `point_of_sale.group_pos_user` but not the `account.group_account_readonly` group * Open customer list > Observation: You can see the amount due for multiple customers * Search for the customer created * Select search more > You can't see the amount due for that customer Why the fix: ------------ Since simple pos users are allowed to see the amount due for the loaded customer, there is no reason they shouldn't see it as well for a customer they need to load. Commit allowing simple pos users to see (and settle) customer accounts: https://github.com/odoo/enterprise/commit/37fa4d5f4ed7c7d77f73395a53b7b3ab7006afc4 When loading the pos session `_loader_params_res_partner` is called first and later is called `_get_pos_ui_res_partner`. It is in the function `_get_pos_ui_res_partner` that the amount due is compted if the user does not belong to the group `account.group_account_readonly`. https://github.com/odoo/enterprise/blob/a35a4755cdf86bcfeda0aca6c06397748ba27362/pos_settle_due/models/pos_session.py#L22-L28 However when we load a customer that wasn't previously loaded, only `_loader_params_res_partner` is loaded. And since the users does not belong to the group `account.group_account_readonly`, the field witll not get loaded. We now compute the amount due with the same logic as in `_get_pos_ui_res_partner`. opw-4141955 Forward-Port-Of: odoo/enterprise#77604 Forward-Port-Of: odoo/enterprise#73671

[FIX] documents: clean portal action We disable action that portal user cannot perform: In the preview: - hide Split Pdf in the preview In the cog menu: - remove "Move to Trash" as portal user can't archive document (and can't create folder nor access to the trash anyway) - Info&Tags as it opens the chatter which is disabled for portal user In action: - Info&Tags as it opens the chatter which is disabled for portal user - Duplicate only present if it doesn't lead to an error (canDuplicateSelection method). We also remove the line separator in the action if the user is not internal otherwise it leads sometimes to an empty section. In the "New" drop down button: - hide "Folder" (create Folder) - hide "Link" (create link): fails because of (users | folders.owner_id).fetch(['partner_id']) in _prepare_create_values (no access to user) Hide share button for portal user: Although the portal users could share any documents they have access to (by sending them by email for example), we remove the share action (for document and folder) for them as the only thing they could do was to change the rights for user that had already a link to that document. [FIX] documents: fix attachment not pointing to the copied document When copying a document, the copied attachment still points to the orginal record: - if it is a document with an attachment associated to an other record (ex.: hr.expense). The attachment of the copied document is pointing to the same record as the orginal document. Ex.: for an expense, the expense has now 2 attachments linked (one linked to the original document and one linked to the copied one). - if it is a pure document, the attachment points to the orginal document We solve that problem here by always making the copied attachment to the copied document. How to reproduce case 1: - Install documents_hr_expense - Upload a document in the Document App - Create an expense from that document - Duplicate that document - Open the expense App - The expense related to the document has now 2 attachments instead of one How to reproduce case 2: - Install documents - Log in as admin and open Documents App - In Marketing -> Brand 1, duplicate "LA landscape.jpg" - Move "LA landscape.jpg" to the Trash and delete it (from the Trash) - Return to Marketing -> Brand 1 The copy has disappeared as well and shoudln't. It means that deleting the original document deletes all copies. It works also if we delete the copy (it deletes the original). [IMP] documents: allow portal user to delete their own documents Instead of enabling the Trash for the portal user, we add the delete action for their own documents only so that a user that have uploaded a document by mistake can delete it. Indeed, as portal user don't have access to the Trash, moving a document to the Trash like an internal user would do is no use. Task-4221258 Forward-Port-Of: odoo/enterprise#77281

The issue: The delivered qty is not reflected on the order line after creating the first recurring invoice by the cron job. Steps to reproduce: 1. Create a product with the following configuration: Product Type: Service Create on Order: Nothing Invoicing Policy: Based on Timesheets Product Category: Sellable and Subscription Product 2. Set up a recurring subscription plan for the product 3. Create a Sales Order (SO) for the product and confirm it 4. Add hours to a task linked to the SO 5. From Settings > Technical > Automation > Scheduled Actions, manually trigger the cron job "Sale Subscription: generate recurring invoices and payments" to update the `next_invoice_date`. Observed behavior: On the SO page, the smart button of the tasks reflects the hours added correctly. However, the delivered quantity field in the SO line does not update based on the added hours. The reason: The delivered quantity for timesheet based services is computed taking into account the current period [1], however, `next_invoice_date` was not added as a dependency to the compute method of `qty_delivered`, causing this latter to have a stale value when `next_invoice_date` gets updated when creating the first recurring invoice by `_create_recurring_invoice` [2]. The fix: Added `next_invoice_date` as a dependency for the compute function of `qty_deliverd`. [1]: https://github.com/odoo/enterprise/blob/e990d101cce90311f3e2c5d9be4d480b329f9f2a/sale_subscription_timesheet/models/sale_order_line.py#L39 [2]: https://github.com/odoo/enterprise/blob/07f01f39cb46f1763637b50e628dfb613b0d2266/sale_subscription/models/sale_order.py#L1168 opw-4378914 opw-4426787 opw-4463512 Forward-Port-Of: odoo/enterprise#77059

Improvements(1)

[IMP] orm: keep indexes without comments

Bug Fixes(6)

[FIX] mail: no flicker on call video stream inset

Other(68)

[FW][FIX] im_livechat: livechat button loader template

Improvements(1)

[IMP] orm: keep indexes without comments

Bug Fixes(6)

[FIX] mail: no flicker on call video stream inset

Other(68)

[FW][FIX] im_livechat: livechat button loader template

[FIX] mail: multiple action_unfollow on livechat leave

[FIX] l10n_in_hr_holidays: fix sandwich leave warning sign

[FIX] account: hide purchase tab on product template

[FIX] hr: suppress warning on optimized domains

[FIX] sale_planning: fix traceback when loading gantt popover

[FW][PERF] stock: reduce number of queries when writing on smls

[FW][FIX] pos_sale: separate downpayment for fixed tax

[FW][FIX] account_peppol: remove peppol registration migration button

[FW][FIX] hr_holidays: improve test stability

[FW][FIX] l10n_my_edi: XML format and test mode

[FW][FIX] point_of_sale: new session opening time

[FW][FIX] crm: onboarding tour bubble fix

[FW][FIX] pos_hr: prevent singleton error with multiple related partners

[FW][FIX] account: do not affect base of tax without "is_base_affected"

[FW][FIX] sale_project: fixed a test_cost_invoicing test case

[FW][FIX] l10n_eg_edi_eta: withholding tax amount declaration

[FW][FIX] l10n_ch: print Swiss Qrcodes when the transaction is possible

[FW][FIX] {sale_purchase_,}stock: use pull rules on cross-dock

[FW] 18.0 ref taxes tests las

[FW][FIX] loyalty: parse reward_product_domain as JSON

[FW][IMP] l10n_mu: PDF invoice requirements

[FW][IMP] odoo: add config for cron connection time

[FW][FIX] stock,product_expiry,point_of_sale: cron progress in scheduler

[FW][FIX] web: prevent autocomplete crash on selection

[FW][FIX] mail: ensure selection updates correctly after mention insertion

[FW][FIX] web_editor: delete backward on lists

[FW][FIX] sale_loyalty: traceback when coupon applied on so

[FW][FIX] web: Add preventDefault for Chrome 132 compatibility

[FW][FIX] purchase: fix tour by providing appropriate class

[FW][FIX] account_check_printing: print info on checks without entry

[FW][IMP] point_of_sale, bus: ensure websocket connection

[FW][FIX] im_livechat: pass avatar token to cors route

[FW][FIX] l10n_latam_check: existing third party check outgoing payment method.

[FW][FIX] account: avoid searching on account.root

[FW][FIX] account: prevent setting wrong partner_id.payment_term

[FW][FIX] sale,website_sale: fix configurable products in combo configurator

[FW][FIX] account: Allow skipping bank account creation on reconciliation

[FW][IMP] l10n_mx_hr_payroll: add mexican localisation

[FW][IMP] mail: improve quote reply detection

[FW][FIX] pos_viva_wallet: mark endpoint as read/write

[FW][FIX] mail: correctly restart scheduled message cron

[FW][FIX] pos_self_order_stripe: fix Stripe payments

[FW][FIX] hr_attendance: negative overtime for flexible employee

[FW][FIX] stock_account: fix standard_price on _svl_replenish_stock

[FW][FIX] hr_holidays: allow date modification for unapproved time off requests

[FW][PERF] quality_mrp, *: add mising index on move_line_id

[FW][IMP] account_reports: hide "Amount Currency" in PL if single currency

[FW][IMP] stock_barcode: fetch quants in batch

[FW][FIX] documents,documents_{*}: fix document folder protection

[FW][FIX] documents: save all details panel changes

[FW][FIX] helpdesk_timesheet : Autopopulate project when setting a task

[FW][FIX] timesheet_grid: correct working hours for flexible schedules

[FW][FIX] l10n_mx_edi: Fix rounding issues with 'importe'

[FW][FIX] knowledge: fix article commands tour

[FW][FIX] documents: fix the chatter and the inspector in the list view

[FW][FIX] pos_settle_due: make total_due visible when searching for more customers

[FW][IMP] account_reports: Add Customer Statement Variant

[FW][FIX] account_reports: Executive Summary: use proper line of P&L in formula

[FW][FIX] payment_sepa_direct_debit: unblock UI when error

[FW][FIX] test_sale_subscription: make uninstall possible

[FW][FIX] planning: avoid writing on field when cursor is readonly

[FW][IMP] account_reports: remove prefix from account code journal report

[FW][FIX] l10n_au_hr_payroll_account : fix performance test

[FW][FIX] l10n_in_reports_gstr: Improve GSTR-1 exception activity assignment

[FW][IMP] pos_restaurant_appointment: ensure websocket connection

[FW][FIX] account_followup: report not used

[FW][IMP] l10n_mx_hr_payroll: add mexican localisation

[FW][FIX] documents: fix portal