Wednesday, October 23, 2024
16 changes
1 change
Resolved issues and error corrections
Branch companies can now see and apply discount and loyalty programs defined by their parent company. This fixes blocked coupon use on branch sales orders and helps companies manage promotions centrally across branches.
Original PR description
Problem: When a user is on a branch, they are unable to view the parent company's discounts and are unable to apply it to the sales orders. Purpose: The branch should have access to the discounts & loyalty programs from the parent company. Steps to Reproduce on Runbot: 1. Install sale_loyalty 2. Create a branch 3. On the branch company, observe that no discounts & loyalty programs from the parennt company are displayed 4. Attempt to apply a coupon code from a discount belonging to the parent company on a sales order and receive a ValidationError opw-4079487 closes odoo/odoo#182392 X-original-commit: 85d130302e88deb4ee8d1172d847d7ab78918418 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Enhancements to existing features
Large spreadsheets now load much faster by avoiding unnecessary server-side processing of already prepared data. This reduces waiting time for users opening spreadsheet documents and lowers server resource usage, especially for very large files.
Original PR description
Server-side load time for a 16.7Mb spreadsheet: **before: 606ms** (`join_spreadsheet_session`) **after: 83ms** (-86%!) (new `/spreadsheet/data/<...>` controller) Previously,…
Server-side load time for a 16.7Mb spreadsheet: **before: 606ms** (`join_spreadsheet_session`) **after: 83ms** (-86%!) (new `/spreadsheet/data/<...>` controller) Previously, `join_spreadsheet_session` returned a combination of: - The full spreadsheet snapshot (JSON file on the filestore) - Pending revision data (also serialized JSON, stored in a Char field) - Additional metadata These were combined into a Python dict and re-serialized into JSON for the response. This process is inefficient as it involved unnecessary parsing and re-serialization of already serialized JSON data. With this commit, we handcraft the json response body, avoiding the need for parsing and re-serializing large json objects, resulting in significant performance improvements in both CPU and memory. To have control of the response body, we now have to use an http controller instead of an RPC method. We could also have sent the raw/serialized data from `join_spreadsheet_session` but then it would be serialized json over json which has several drawbacks: - reduces client-side debuggability - introduce a lot of additional escape characters (e.g. `\"`) - the client would need to explicitly parse the nested json With this solution, the client receives a clean, valid json content type Alternative idea: we could stream the snapshot file directly from the file store to be even more efficient. But then we would need to load the additional metadata and revisions with another http request. As those two requests would not be executed as part of the same transaction, it would come with its own share of issues.
10 changes
Enhancements to existing features
Italian partners now automatically use FatturaPA as their preferred electronic invoicing format. Spanish partners correctly default to Facturae when a certificate exists, improving invoice setup while avoiding errors when no certificate has ever been configured.
Original PR description
…S/IT Add FatturaPA as the preferred EDI format set by default on Italian partners. Fix the preffered EDI format of Spanish partners to be correctly computed to Facturae. task-no
The point of sale now selects an order line only when a cashier has just added a product, and clears selections when reopening orders from areas such as tables, tickets, or payments. This makes the numpad and order editing behavior more predictable, reducing accidental changes during checkout or restaurant workflows.
Original PR description
-Select order line only when I've just added a product to cart -Ensure that no order line is selected anymore when opening an order (from floorplan, table selector, ticket screen, payment screen) -Adapt tours tests to match this new behavior and limit the use of 'inLeftSide' to avoid going uselessly back and forth to the product list in mobile task-id: 4167563 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
The point of sale UrbanPiper integration now creates the store location in Atlas when a user selects Create Store. This reduces manual setup work and helps keep store information aligned between Odoo and Atlas.
Original PR description
After this commit: === - When the user clicks the Create Store button, the location is now created in Atlas. task-4270144
Resolved issues and error corrections
This fix restores shared sales logic needed when re-invoicing expenses without the Project app installed. It prevents errors in expense posting flows where costs, such as mileage, are billed back to customers through sales orders.
Original PR description
This fixes issues that arose since 238a41e3 By moving the `_prepare_analytic_account_data` method from sale to sale_project, any call to this method in sale_expense would break as sale_expense doesn't depend on project. Because this method is crucial in the re-invoicing flows we need it in sale. Steps to reproduce: - Install sale_expense without project - Run the sale_expense tests or test the flow manually (create an expense with mileage as a product, add a sale order to reinvoice it on and move forward to post the expense sheet) - _prepare_analytic_account_data is missing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change restores the previous behavior for required selection fields so users are not shown a first option that appears selected but is not actually saved. It prevents confusion and data entry mistakes in forms that rely on required dropdown choices.
Original PR description
This reverts commit eec86a3fda555f3939d6773f4c79ca6b3636228a. This commit introduced an unexpected behaviour where the field seems to select by default the first choice but has no value.
Users can now change a company’s Chart of Accounts without being blocked by an unnecessary accounting permissions error. This prevents disruption when configuring invoicing for localized companies and keeps setup workflows moving smoothly.
Original PR description
Install account and a localization (i.e. l10n_ar)
Switch to Company "(AR) Exento"
Open Settings>Invoicing
Change current Chart of Account to something else
Save
Error will block the action
This operation is allowed for the following groups:
- Technical/Show Full Accounting Features
Contact your administrator to request access if necessary.
This occurs because the permissions necessary to write on the
AccountReconcileModelLine are loaded when installing module `accountant`
opw-4227071Invoices with early payment discounts remain eligible for the discount when a payment is registered and later matched in bank reconciliation. This ensures the reconciliation suggestion includes the expected discount write-off, reducing manual corrections for accounting users.
Original PR description
Steps to reproduce: - Create an invoice with early payment discount applicable - Register a payment on the invoice (must be without a journal entry associated, done by default) - Open the bank reconciliation widget - Create a statement line with the discounted amount (invoice total - epd amount) - The suggested reconciliation doesn't include a new line with the write-off of the early payment discount Cause of the issue: When registering a payment on the invoice, the invoice payment state switch from 'not_paid' to 'in_payment', which makes this invoice not eligible anymore for early payment discount. task-4237657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Cloud storage attachments now align with the updated mail upload behavior, preventing upload handling errors when files are stored externally. This helps keep attachment uploads reliable for Azure and Google cloud storage users.
Original PR description
Store now returns `ir.attachment` and not `Attachment` as model name. Note: post kwargs backed-ported fix at https://github.com/odoo/odoo/pull/184506 opw-4260378
The payment confirmation action now only applies to payments that are still in draft. This prevents users from accidentally moving already paid payments back to an in-process status when confirming multiple selected payments.
Original PR description
This fixes issues that arose since 2609fc2 The confirm button (action_post) on the list view of payments allows to move the payment state one step back from `paid` to `in_process` We now only consider payment in draft when doing so, to keep all other payments mistakenly selected intact 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
Features or functions removed from Odoo
This change removes the behavior that copied calendar default privacy settings from the default user template when creating users. It simplifies calendar user setup and avoids potential performance and usability issues that needed further product review.
Original PR description
This PR drops the feature of copying of the Calendar Default Privacy field from the Default User Template in the modules `calendar` (full feature) and `microsoft` (only tests). To be discussed with the PO and Team Leader the drawbacks of keeping it and dropping it. Performance regarding _compute and _invert methods and also usability of the feature. task-4260834
4 changes
Enhancements to existing features
This update enhances the accuracy of Early Payment Discount (EPD) reconciliation in countries with cash rounding practices. Previously, slight overpayments weren't recognized, leading to manual adjustments. Now, accountants can customize tolerance levels, ensuring correct discount recognition and streamlining reconciliation workflows.
Original PR description
In countries using extensively cash roundings, invoices having a early payment discount can usually be paid within a cash rounding tolerance. e.g. with a cash rounding of 0.05, and an early payment discount of 5%, for a total amount of 868.25, a discount amount of 824.84 will be stored. If a customer pays slightly more (eg 824.85), the early payment will not be recognized in the reconciliation widget, resulting at best in a partial payment that will require extra work for the accountant to write off properly for early payment discount. By allowing to customize the comparison between open amount and total discount, it allows to implement any kind of tolerance in custom modules without breaking anything in the actual reconciliation mechanism. OPW-3985470 Forward-Port-Of: odoo/enterprise#68523
Resolved issues and error corrections
This update resolves an issue where users would receive a technical error instead of a clear message when creating a Sendcloud shipment without selecting a pickup point. The fix ensures a user-friendly error message is displayed, guiding users to select a pickup location for their shipment.
Original PR description
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name…
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name will be "Bob, delivery address" - Create a sale order for Bob - Add a Sendcloud shipment method to that SO and confirm the SO - Go on the associated delivery and try to validate it ### Expected behavior: You should raise a user error telling you that you a pickup point was required for the selected shipping method. ### Current behavior: You raise a traceback prior to that point. ### Cause of the issue: Since you did not set a name on your delivery partner the code will break as soon as you try to generate the parcels data because "False" is not iterable, see: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L576-L577 ### Fix: If for some reason the name of the delivery partner has been removed or was unset (e.g. display name is of the form: Bob, Delivery address), the name of its parent should be used to generate the parcel data. Note: This fix should normally not be that relevant, because, if you were to select a pickup point, the partner used to generate the parcel would already be the parent partner and is guarranteed to have a name: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L556-L561already However, now, if you proceed with this flow without any pickup point (which you can only select form the website) you will now raise a relevant user error: #### Invalid Operation: "A service point is required for the selected shipping method" opw-4118362
This update significantly speeds up the process of retrieving related documents for large projects. By using a more efficient database query, the system now processes document lookups 2.45 times faster, particularly when dealing with projects containing a massive number of tasks. This improves overall performance and responsiveness.
Original PR description
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over 1M tasks. | | Before | After | Speed-up | |---------------|--------|-------|----------| | Timings (hot) | 2.85s | 1.16s | 2.45x | Forward-Port-Of: odoo/enterprise#72468
This update resolves an issue where location scans weren't being properly recognized during internal transfers when a product was manually added instead of scanned. The fix ensures that the system correctly identifies and utilizes the scanned location, improving the accuracy of internal transfer processes. This enhancement streamlines operations and reduces potential errors.
Original PR description
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Add a barcode to a different location that WH/Stock - Go to the barcode > Operations > Internal Transfers > New > The header…
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Add a barcode to a different location that WH/Stock - Go to the barcode > Operations > Internal Transfers > New > The header propose to scan a product - Do not scan the product by click on `+ ADD PRODUCT` - Add 1 unit of your favorite product > The header propose to scan a product or a destination location - Scan the location you had set #### > The location scan is ignored ### Cause of the issue: During the `_parseBracode` called to determine what was scanned by the barcode, a location corresponding to the barcode scanned will be found. To use this barcode, if it makes sense, the `_setLocationFromBcode` will be called in turn. However, during internal transfers, this location will only be used as a destination location under very specific conditions: https://github.com/odoo/enterprise/blob/8035abddf9991f6bfb71bb7889b703e5ed31a179/stock_barcode/static/src/models/barcode_picking_model.js#L1603-L1619 And, since we did add the product manually rather than using a scan, in our case, `this.previousScannedLines.lengt` will be null rather than positive so that the location will not be used to set the destination. opw-4201489