Tuesday, November 19, 2024
9 changes · saas-17.4
Resolved issues and error corrections
Users who can approve expenses but do not have accounting access can once again reset refused or approved expense reports back to draft. This fixes a workflow blocker and also changes the reset shortcut to avoid conflicting with the create shortcut.
Original PR description
This re-adds the possibility for a user with approval rights, but no accounting rights to reset an expense to draft after it has been refused/approved. opw-4328933 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
Recurring subscription invoices now trigger required electronic declaration files, not just PDF invoices. This helps companies meet government e-invoicing obligations automatically when subscriptions generate invoices.
Original PR description
*: account_edi_ubl_cii,account_peppol,l10n_es_edi_facturae,l10n_it_edi,snailmail_account Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Assign a UNSPSC to a subscription product - Create a new subscription with this product, select a monthly recurring plan - Normally the next invoice date is today - Now go in "Scheduled Actions" > "Sale Subscription: generate recurring invoices and payments" and run it manually - When coming back to the subscription, click on the invoice The PDF is created but not the XML file Cause: Subscription uses the method `_get_wizard_vals_restrict_to(...)`. This methods sets all checkboxes of the wizard to false. This was originally made to avoid sending by default with Peppol. Solution: Add the possibility to enforce mandatory EDI that typically declare the invoice to the government. opw-4230920
Restaurant POS orders now update correctly when the same table is open on multiple devices. This prevents confusing negative quantity indicators and helps waiters and checkout staff work on shared orders without inconsistencies.
Original PR description
Steps to reproduce: 1. open a first restaurant session on one tab => S1 2. open the same restaurant session on a second device (e.g. incognito tab) => S2 3. select a table on S2, create an order and…
Steps to reproduce: 1. open a first restaurant session on one tab => S1 2. open the same restaurant session on a second device (e.g. incognito tab) => S2 3. select a table on S2, create an order and add a product 4. open that order on S1 5. add more of the same product from S2 6. you will see negative quantities on the order button on S1 Before this commit, the callback for websocket notification "TABLE_ORDER_COUNT" was assuming we were on the floor screen and thus not updating the (potential) opened order. The result was an inconsistency when using multiple devices, with one of the POS session detecting "negative" additions to the order. Typical use case where this causes problems: A restaurant where waiters use mobile devices to take the orders at tables and a fixed PC as the checkout to settle orders and payments. In such instances, if the waiter forgot to return to floor screen after taking an order or if someone went to check the table order from the PC and kept that view open, inconsistencies arise. After this commit, changes made to the order from another device are taken into account even when the order is already opened on this device. opw-4208794
The Point of Sale screen now informs users when server data cannot be loaded instead of leaving them stuck on an endless loading screen. This helps cashiers and store staff understand that something went wrong and take action sooner.
Original PR description
Before this commit, the PoS interface would continue to show loading indefinitely without displaying any message if an error occurred during data retrieval from the server. This commit resolves the issue by introducing an alert mechanism to inform the user of any errors encountered during the loading process. opw-4176629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents some real-time notifications from being skipped when several messages are created at nearly the same time. Users should receive bus notifications more consistently, improving reliability for live updates and messaging-dependent workflows.
Original PR description
Before this PR, some notifications could be missed due to the way notifications are fetched. We tracked the last fetched ID and only fetched notifications with greater IDs. However, this approach is…
Before this PR, some notifications could be missed due to the way notifications are fetched. We tracked the last fetched ID and only fetched notifications with greater IDs. However, this approach is subject to concurrency issues because primary keys are assigned before commit. As a result, we might fetch a notification with a greater ID and miss one with a lower ID that hasn't been committed yet. Problematic scenario: - A bus_bus record is inserted with ID 1. - A bus_bus record is inserted and committed with ID 2. - A bus_bus record with ID 2 is fetched, but ID 1 is missing because it was not yet committed. - The bus_bus record with ID 1 was missed. To solve this issue, the WebSocket class now keeps track of notifications received within a 10-second window. Fetches will target unknown notifications with an ID greater than the smallest one in this window. This effectively prevents missing notifications, as the 10-second window is much larger than the commit concurrency. 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
This fix prevents some real-time notifications from being skipped when several notifications are created at nearly the same time. Users should receive bus-based updates more consistently, reducing missed messages or status changes in live interfaces.
Original PR description
Before this PR, some notifications could be missed due to the way notifications are fetched. We tracked the last fetched ID and only fetched notifications with greater IDs. However, this approach is subject to concurrency issues because primary keys are assigned before commit. As a result, we might fetch a notification with a greater ID and miss one with a lower ID that hasn't been committed yet. Problematic scenario: - A bus_bus record is inserted with ID 1. - A bus_bus record is inserted and committed with ID 2. - A bus_bus record with ID 2 is fetched, but ID 1 is missing because it was not yet committed. - The bus_bus record with ID 1 was missed. To solve this issue, the WebSocket class now keeps track of the last 500 notifications received. Fetches will target unknown notifications with an ID greater than the smallest one in this window. This should prevent missed notifications.
Point of Sale orders are no longer moved into automatic rescue sessions when the original session was closed elsewhere. Instead, the system uses another open session when available or asks the user to open a new one, helping keep cash statements and closing balances accurate.
Original PR description
This commit addresses the issue where orders were created on a device with an open PoS session, even though the session had been closed on another device. Previously, the system would create a "rescue session" for these orders, which led to incorrect cash statements. With this fix, instead of creating a rescue session, the system now attempts to find any available open session. If no open session is found, the system prevents the order sync and raises an error, prompting users to open a new session. The decision to remove rescue sessions was driven by the fact that they caused inaccuracies in cash statements. Orders captured in a rescue session, especially those involving cash payments, would disrupt the cash control process. Furthermore, rescue sessions would initialize with a zero opening balance, which affected the accuracy of closing balances and cash flow. opw-4219284 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A problem in the loyalty integration could stop all Point of Sale products from loading when loyalty products hit an access error. This fix keeps regular PoS product loading working even if loyalty-related products cannot be accessed, reducing disruption for store operations.
Original PR description
Before this commit, encountering an access error while loading loyalty products would prevent all Point of Sale products from loading. This commit addresses the issue by ensuring that PoS products are still loaded even if there's an issue with accessing loyalty products. opw-4209609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Recurring subscription invoices in Brazil and Mexico now trigger the required electronic declarations, not just PDF generation. This helps businesses stay compliant with local tax reporting obligations when invoices are created automatically.
Original PR description
…scription *: l10n_br_edi,l10n_mx_edi Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Assign a UNSPSC to a subscription product - Create a new subscription with this product, select a monthly recurring plan - Normally the next invoice date is today - Now go in "Scheduled Actions" > "Sale Subscription: generate recurring invoices and payments" and run it manually - When coming back to the subscription, click on the invoice The PDF is created but not the XML file Cause: Subscription uses the method `_get_wizard_vals_restrict_to(...)`. This methods sets all checkboxes of the wizard to false. This was originally made to avoid sending by default with Peppol. Solution: Add the possibility to enforce mandatory EDI that typically declare the invoice to the government. opw-4230920