Thursday, November 21, 2024
29 changes
2 changes
Resolved issues and error corrections
Several country-specific accounting localizations now install automatically when the main Accounting app is installed. This ensures businesses in affected SYSCOHADA countries get the correct accounting configuration without manual setup steps.
Original PR description
The dependency `l10n_syscohada` doesn't get installed automatically when account is installed, therefore these l10n don't get installed either. Each localization that had `countries` set in the manifest should have an `auto_install` containing the main app it is for.
The accounting demo setup now ensures a country is defined for the company. This prevents failures in automated checks that depend on country-specific accounting configuration, improving reliability for test and demo environments.
Original PR description
Fix for 1c5cc23b5eb3b59da10926688fc350b56397b550 Generic CoA sets the country on the company. Without one many tests fail. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This fix ensures planning schedule template calculations work correctly when several records are processed at once. It helps avoid incorrect or incomplete planning data in batch operations, improving reliability for teams managing schedules.
Original PR description
Template compute methods do not support properly recordsets and work for a single record. The goal here is to handle more than one record at a time.
19 changes
Resolved issues and error corrections
This fixes a problem where a test retry check could fail after an earlier test failure, creating misleading logs. The change helps keep automated test results clearer and more reliable for teams monitoring product quality.
Original PR description
Since auto retry was disabled after the first failure (see #162990), the test_retry test suite will systematically fail if another test fails before, adding confusing logs. Fix the way the retry count is detected to solve the issue.
New products created while importing sales documents now keep the unit of measure from the sales line, such as dozens instead of defaulting to units. This helps avoid pricing and quantity mistakes when products are created automatically during sales import workflows.
Original PR description
Steps: - Go to sales. - Enable UOM from settings. - Export Purchase EDI file with Dozens UOM on product in another DB. - Import that file here in sales. - Since that product is not created here in our db create product on fly from SOL. Issue: - Newly created product does not have Dozens UOM instead it set to Unit and update it in SOL so price on SOL and product is according to Dozens UOM and UOM set on product and SOL is Unit which can lead to issues. Cause: - Missing context to set default UOM from SOL to product. Fix: - Added `default_uom_id` context on product field on SOL view. - Ensure that an uom is always provided to the creation values even if `default_uom_id` is set to `None` in the context, since `uom_id` is a required field on products. - Updated sale_timesheet code to avoid overwriting default values when product is not a timesheet product opw-4316426
This fix lets website grid sections grow vertically when content needs more space, such as on smaller screens or when translated text is longer. It helps prevent cramped or cut-off content, improving the browsing experience for visitors.
Original PR description
Website CSS grid bug fix affecting responsiveness to smaller screen resolutions. **Description of the issue/feature this PR addresses:** Having `grid-auto-rows` fixed at 50px stops the grid cells from growing in a responsive manner. **Current behavior before PR:** Grid cells don't respond to changes in screen resolution or changes caused by the content being translated to a different language. **Desired behavior after PR is merged:** Using the `minmax()` CSS function allows the grid cells to expand vertically to accommodate content that exceeds the minimum height of 50px, improving responsiveness on smaller screens. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents receipt validation failures when a product is changed from lot-based tracking to quantity-based tracking. It automatically clears the lot valuation setting when it no longer applies, helping purchasing and inventory flows continue without manual correction.
Original PR description
Issue: Cannot validate receipts for products whose tracking changed from lot to quantity. Steps to reproduce: - Install both Inventory & Purchase apps - Create a new product - Track the product's inventory by Lot and set it's valuation by Lot - Set the product's tracking in inventory by quantity - Create a Purchase Order for the product - Confirm the PO - Validate the linked Receipt Cause: Lot valuation is not set to False when changing the tracking of a product from lot to quantity. Solution: Add an onchange on the "[tracking](https://github.com/odoo/odoo/blob/78b8a1670b5272c820f64ef904f4bdf00760031e/addons/stock/models/product.py#L694-L700)" field to update "lot_valuated" to False when **lot_valuated is still True** despite **no tracking being specified**. Ticket: [4345571](https://www.odoo.com/odoo/project/49/tasks/4345571) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A website test step related to hiding the header while scrolling was corrected after it broke in no-demo builds. This helps keep automated quality checks reliable without changing the customer-facing website experience.
Original PR description
in commit https://github.com/odoo/odoo/pull/182289/commits/b18e284da99ff3ae10ef03f12fdcb13efc3acbd1 one of the steps of dropdowns_and_header_hide_on_scroll tour got broken. This commit aims to fix that error. [runbot errors](https://runbot.odoo.com/web#id=105122&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures company-specific numeric and yes/no fields handle empty default values correctly when saving updates. It prevents incorrect stored values and keeps company-dependent settings consistent across records.
Original PR description
The problem is caused by https://github.com/odoo/odoo/pull/184275 For company dependent Boolean/Integer/Float fields, if fallback is unset or falsy, the value filled to cache can be `None` after fetch. When `_flush` `None` in cache for these fields should be converted to the logical equivalent `False`/`0`/`0.0` to allow SQL to compare with the fallback value and drop them when UPDATE opw-4313425 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
Payment transactions can now be completed even when they are linked to more than one invoice due to changes made while the customer is redirected or while webhooks are delayed. The process now selects one eligible posted invoice instead of crashing, reducing failed payment follow-up and manual intervention.
Original PR description
When post-processing a payment transaction, if could happen that the transaction is linked to multiple invoices. Several things can happen while a customer is redirect to a payment provider up to when we post-process the payment (we may long delay for some webhooks), like salesman create multiple downpayment invoices, accountant cancel a pre-existing invoice, etc... In such case we were crashing with a singleton error because `_get_invoice_next_payment_values()` only accept a single recordset. This commit ensure we only match a single posted invoice. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where selecting text across chatter messages in Firefox could trigger an error. The editor now ignores selections outside its own area, improving reliability when users interact with messages around editable fields.
Original PR description
**Problem**: When selecting nodes outside the editor in chatter, attempting to set the selection results in a traceback. This issue occurs because the `setSelection` logic does not properly handle cases where the selected node falls outside the editor's context. **Solution**: Add a check to ensure that the `setSelection` logic does not execute if the selection is outside the editor. same as what we have in 17.0: https://github.com/odoo/odoo/blob/288f815382f6d4f857c233c4627774f1992af5ba/addons/web_editor/static/src/js/editor/odoo-editor/src/OdooEditor.js#L2608-L2610 **Steps to reproduce**: 1. Open any form with chatter in Firefox. 2. Select text across multiple messages in the chatter. 3. A traceback occurs due to improper handling of selections outside the editor. opw-4345728 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the ability for shoppers to select pickup point locations during checkout when using website sale collection with Sendcloud. It prevents the selection button from being incorrectly disabled when optional location details are missing.
Original PR description
Steps to reproduce: - install website_sale_collect - setup a sendcloud delivery method with pickup points - try to select a location Bug: The `Choose this location` button is disabled This is a tiny partial revert of https://github.com/odoo/odoo/pull/180754. The replacement of the chain of `and` cannot be replaced by the ?. operator, as they will return !False and thus disable the button even if `additionalData` (and the other following items of the ?. chain) is not present on the selected location. opw-4283739 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the HTML editor from showing an error when users press Tab while working with nested lists. It makes list editing more reliable and avoids interruptions while formatting content.
Original PR description
Description of the issue/feature this PR addresses: The issue occurs when `mergeSimilarLists` is triggered, leading to a call to `compareListTypes`. If `a.firstElementChild` or `b.firstElementChild` is null, attempting to access their `tagName` causes an error. Desired behavior after PR is merged: The traceback no longer occurs.
This fixes an issue where serial numbers added or changed on Point of Sale order lines were not always shown correctly in the cart. Staff can now see the correct serial numbers when adding the same tracked product multiple times or updating its serial numbers, reducing order errors for tracked items.
Original PR description
When adding/modifying SN on an orderline in the PoS the changes where not always correctly reflected and sometimes it was just not displayed. Steps to reproduce: ------------------- * Create a product tracked by SN * Open PoS * Add this product to the cart and put SN 1 * Add the same product by clicking on it, and put SN 2 > Observation: The item in the cart won't be updated correctly, only one SN will be shown * Click on the lot icon * Add a new SN 3 > Observation: Again the new SN won't be shown opw-4323167
This fix makes Odoo's code upgrade command clearer and more reliable when run directly or through odoo-bin. It now requires the needed add-ons path information, uses sensible defaults where appropriate, and avoids a crash when no files match the requested pattern.
Original PR description
* Requires --addons-path and prints the correct usage when used standalone. * Ensure --addons-path is populated with the default paths when used with odoo-bin. * Fixed 0/0 division by zero error when no file match the glob. 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 fixes a typo that caused an incorrect value to appear in Spanish TicketBAI XML documents. The change helps ensure submitted electronic tax documents contain the expected information and reduces the risk of reporting errors.
Original PR description
Fix a typo in that led to wrong value in tbai xml document. opw-4331383
Salespeople can once again view invoices linked to their sales orders without needing Accounting or Billing permissions. This fixes an access error related to Indonesian e-Faktur data, helping sales teams follow up on customer invoices smoothly.
Original PR description
Salesman have access to see invoices (from orders) but when opening one, an access error it raised: `You are not allowed to access 'Available E-faktur range' (l10n_id_efaktur.efaktur.range) records.` This commit allow salesman without `Accounting / Billing` to see their invoices again. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mobile messaging menu and Discuss app now use less spacing between conversation items. This lets users see more conversations on screen while keeping each item easy to tap with a thumb.
Original PR description
There was too much spacing in the mobile messaging menu and mobile discuss app. This PR reduces is so more item are visible while still being easily clickable with a thumb tap. <img width="1236" alt="Screenshot 2024-11-20 at 17 09 06" src="https://github.com/user-attachments/assets/bccaef0e-150f-4365-a224-e405435afa26">
The partner form now shows the customer's follow-up status, making it easier for staff to see collection status at a glance. It also adds a direct link to the partner's overdue invoices, helping teams act faster on outstanding payments.
Original PR description
The followup status of the partner is added to the partner form view with an additional link to see the list of overdue invoices for the partner. task-4320967
Rental and subscription sales now carry over the unit of measure chosen on the sales line when creating products. This keeps these workflows aligned with standard sales behavior and helps avoid incorrect product setup or ordering details.
Original PR description
To ensure that products created from sale order lines correctly use the uom set on the line, a new `default_uom_id` has been added to the field `context`. This commit makes sure the same change is applied in rental & subscriptions, as both modules inherit from the base `sale` view and overwrite the `context` attribute to add their own keys. opw-4316426
Opening or refreshing a direct link to a document now shows the intended item even when default document filters are configured. This prevents users from landing on an empty or filtered-out view when sharing or revisiting document URLs, including items without previews such as requests or links.
Original PR description
Reproduce: 1. Add the context key `search_default_my_documents_filter` in Documents action context 2. Go in a folder where a document exist that does not match this filter 3. Copy the url of this document (copy url when it is selected) 4. Paste in navigation bar (or refresh page) 5. You do not end up on the document because the default filter still applied This commit prevents loading default filters when we come from such URLs. While we're here, we remove the check on open_preview which was incorrect (e.g., requests and urls have no preview but should be accessible this way too). Follow-up of https://github.com/odoo/enterprise/commit/3418e7318ed993abc2a601ae601e7214e28293a3 (https://github.com/odoo/enterprise/pull/74028) Task-4342960
Portal users can now cancel creating a new folder in Documents without seeing an error screen. This prevents an interruption in the Documents workflow and provides a smoother experience for external users.
Original PR description
**How to reproduce:** Login with portal. Click on New button. Click on Folder button. Click on Discard button. Traceback will be displayed. **After this PR:** Prevent traceback when portal users click the discard button. Task-4330910
7 changes
Resolved issues and error corrections
This update fixes an issue preventing users from duplicating resource bookings (like tennis courts) within the Appointments module. Previously, a validation error would occur, blocking the duplication process. This change ensures users can now successfully duplicate existing bookings, streamlining appointment scheduling.
Original PR description
Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource…
Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource booking Steps to reproduce: --- 1. Go to Appointments 2. Select a resource appointments (ie. Tennis Court) 3. Click on new (To make a new resource booking) 4. Set a name, attendee, AND resource (ie. Court 1) 5. Go to list view, and open newly made booking 6. Click on the cog > Duplicate 7. Validation Error Cause of the issue: --- Caused by: https://github.com/odoo/enterprise/commit/064e0da976edd7ef501e4fb33d4d579eaab85a3d When duplicating a calendar.event, at the field appointment_resource_ids, the relation table appointment_booking_line is used on the fields calendar_event_id and appointment_resource_id. However, the model appointment_booking_line has another required field capacity_reserved. So when inserting into the table: https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/odoo/fields.py#L4945 Only the two specified columns/fields are set, but not the third required field capacity_reserved. Which causes a SQL error "violates not-null constraint" opw-4187159
This update corrects a dependency issue within the Odoo Enterprise HR Payroll module. A previous error was discovered regarding the connection between payroll and attendance modules, leading to problems during automated testing (runbot). This change ensures accurate payroll calculations and test results.
Original PR description
Introduced in https://github.com/odoo/enterprise/pull/73469 I made a mistake when checking module dependencies, `work_entry_source` attendance is not available in `hr_payroll`, the attendance module is separate. This move is needed to fix errors in runbot. opw-4266880
This update corrects an error in the Cash Basis reporting module that was causing incorrect amounts to be displayed for certain sales transactions. The issue stemmed from a flawed SQL query that wasn't properly handling multiple receivable accounts within a single payment. The fix ensures accurate reporting by adjusting the calculation of cash basis amounts.
Original PR description
**Steps to reproduce:** - Install Accounting and Point of Sale - Open a "Point of Sale" session - Create a POS order and pay it by bank - Create another POS order and pay it by Customer Account -…
**Steps to reproduce:** - Install Accounting and Point of Sale - Open a "Point of Sale" session - Create a POS order and pay it by bank - Create another POS order and pay it by Customer Account - Close POS session - Go to Accounting - Open Bank journal - Create a statement line and reconcile it with the POS payment - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Check the amount of the POS orders in the following journals: * [101300] Account Receivable (PoS) * [121000] Account Receivable * [400000] Product Sales - Check "Cash Basis Method" in the options - Check again the amount of the POS orders in the same journals **Issue 1:** The amount for "[121000] Account Receivable" is present but it shouldn't because no payment has been done for it yet. **Extra steps:** - Create another statement line and reconcile it with the POS customer account payment - Check again the amount of the POS orders in the same journals **Issue 2:** The amount of the POS orders is double the original amount. **Issue 3:** If a partial payment is made for one line, the report has incorrect values. **Cause:** To retrieve the cash basis lines, a complex SQL query is executed. Let's take the following entries: - Invoice: | account | debit | credit | | ----------- | -------- | -------- | | Account Receivable 1 | 100 | 0 | | Account Receivable 2 | 200 | 0 | | Product Sales | 0 | 300 | - Payments: | account | debit | credit | | ---------------- | ------------ | ----------- | | Bank | 50 | 0 | | Account Receivable 1 | 0 | 50 | | account | debit | credit | | ------------ | ---------------- | ----------- | | Bank | 200 | 0 | | Account Receivable 2 | 0 | 200| A SELECT is executed to compute and get the percentage of the paid amount of each receivable/payable account by move, generating a temporary "table" as followed: | move_id | matched_percentage| | ------------------|---------------------------------| | 1 | 0.5 (50% paid for Account Receivable 1)| | 1 | 1.0 (100% paid for Account Receivable 2)| This table is then joined to account_move_line table on move_id where matched_percentage is applied to the amounts. Issues 1 and 2 are due to the fact that it was assumed that each account move would only contain 1 receivable/payable account, which is not the case here. As account_id is not present in the temporary table, it is not possible to identify to which account a line of that table refers to. As there is only a JOIN ON move_id when joining with account_move_line table, each aml from a move is taken into account even when it shouldn't. In this example, they are taken into account twice because the 2 entries have the same move_id. Issue 3 is coming from the fact that the WHOLE amount of "Product Sales" is computed with matched_percentage each time. For example, these 2 lines are computed from the tempory table for "Product Sales": * Product Sales = 300 * 0.5 = 150 (for Account Receivable 1) * Product Sales = 300 * 1.0 = 300 (for Account Receivable 2) The amount for "Product Sales" sums to 450, which is not correct. It should be 250. **Solution for issues 1 and 2:** Get account_id and join account_move_line table on it. An exception should be done for "Product Sales" when joining account_move_line table because it is not a receivable/payable account and the temporay table only contains receivable/payable accounts. **Solution for issue 3:** Compute a ratio for "Product Sales" for each receivable account. Its amount is 100 for "Account Receivable 1" and 200 for "Account Receivable 2" So its ratio should be: * 100 / 300 = 0.33 (for Account Receivable 1) * 100 / 300 = 0.66 (for Account Receivable 2) By applying this ratio, the correct amounts are computed for "Product Sales": * Product Sales = 300 * 0.5 * 0.33 = 50 (for Account Receivable 1) * Product Sales = 300 * 1.0 * 0.66 = 200 (for Account Receivable 2) opw-4224136 Forward-Port-Of: odoo/enterprise#73593
This update fixes an issue where profitability reports for subscription projects weren't accurately reflecting invoiced amounts when using custom analytic plans. The change ensures the system correctly identifies the appropriate analytic account data, leading to more precise revenue reporting. This improves the accuracy of financial insights for subscription-based projects.
Original PR description
### Steps to reproduce: - Create a new project and set it to be billable. - Set an analytic account on it - On the analytic account, set a plan that is not the default plan - Create a sale order for…
### Steps to reproduce:
- Create a new project and set it to be billable.
- Set an analytic account on it
- On the analytic account, set a plan that is not the default plan
- Create a sale order for a subscription product with this analytic account and confirm it.
- Create an invoice and confirm it.
- Go to the project and click on Status Updates
- Notice that the revenues show 0 in “Invoiced” even though we have invoiced the product
- If we change the plan on the analytic account, we will be able to see the invoiced amount on the profitability report
### Current behavior before PR:
When setting analytic account with different analytic plan than the default one the analytic account value will be stored in x_plan{plan_id}_id field when creating the analytic account line record. https://github.com/odoo/odoo/blob/39029710bbce55889c6b951fc423c1254e05ff22/addons/account/models/account_move_line.py#L3092
https://github.com/odoo/odoo/blob/17.0/addons/analytic/models/analytic_plan.py#L106:L122
So when fetching the profitability data for a project we are just checking the account_id field.
https://github.com/odoo/enterprise/blob/17.0/project_sale_subscription/models/project.py#L111:L115
### Desired behavior after PR is merged:
We are now using the same method of _column_name() to know which field should we use in the domain whether it is 'account_id' or 'x_plan{plan_id}_id'
opw-4137931This update reduces the size of spreadsheet thumbnails, resulting in faster loading times and reduced storage usage. While image quality was slightly decreased, the thumbnails are so small that the visual impact is negligible. This change focuses on optimizing performance and resource efficiency.
Original PR description
This commit drastically reduces the spreadsheet thumbnails size. Go to CRM lead and insert the pivot in a spreadsheet: The size of the thumbnail: | Description | Size | |-----------------------|--------| | Before | 107Kb | | After quality=0.5 | 7.8Kb | | After quality=0 | 2.9Kb | Image quality is indeed reduced, but the thumbnails are always displayed so small that it doesn't really make any difference to the naked eye. Note: I'm not backporting this fix to 16.0 because the code changed and webp was not supported at the time (even though we could use jpeg) Task: 4337496
This update adds the picking name as a reference number to UPS shipments. This enhancement allows for more precise tracking of deliveries within Odoo, aligning with shipping best practices and providing better visibility for our customers. It resolves an internal task (opw-3930816) to improve the accuracy of UPS shipment data.
Original PR description
Add the picking name as a reference number on ups shipment. [opw-3930816](https://www.odoo.com/odoo/project/49/tasks/3930816) Forward-Port-Of: odoo/enterprise#67303
This update fixes a bug that prevented users from editing locked sales orders with automatic tax calculations (AvaTax). The system attempted to recompute taxes after confirmation, leading to an error. This change ensures users can correctly preview and manage these orders without encountering this issue.
Original PR description
An error will raise when users try to open a locked SO where taxes are automatically computed Set up Avatax on the current company In Settings > Sales > Quotations& Orders active 'Lock Confirmed Sales' Create a SO with fiscal position 'Automatic Tax Mapping (AvaTax)' Add a partner and product having avatax category defined Compute taxes Confirm order, it will be automatically locked - With only sale_external_tax installed: Click "Preview" - With sale_subscription_external_tax installed: Click "Confirm" Issue: Action will be blocked by User Error ``` It is forbidden to modify the following fields in a locked order ``` This occurs because the system attempt to recompute external taxes after confirming the sale order, which has been locked, so the action will be blocked opw-4261396