Daily updates from Odoo
Thursday, November 21, 2024
15 changes
1 change
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.
5 changes
Enhancements to existing features
Time off categories provided by localization modules are kept available globally instead of being tied to a single country. This avoids disrupting existing leave records and allocations that may already use those categories across multiple countries, while supporting the new country-based filtering capability.
Original PR description
Currently, when you try to take a time off, you'll have the list of all time off types, cause there is no field "country" on the leave type. So, if you have "sick leave" in belgium, "sickness" in US and "sick holiday" in India, you'll see the three of them. A field country_id was created on hr_leave_type model [in odoo community](https://github.com/odoo/odoo/pull/169147) to fix this issue. This commit sets the country_id to False on the time off types defined in L10N modules. Setting the country_id on the time-off types defined in L10N modules to their corresponding countries would cause issues. That is because the time-off type records in L10Ns might be already used by allocations/leaves from multiple countries. task-3978260
Tax selection fields now show the tax scope more consistently across accounting and Ecuador localization screens. This helps users choose the correct tax more confidently and reduces the risk of selecting the wrong option.
Original PR description
Before this **PR**: Tax fields in some modules were not showing tax scope during the tax selection. After this **PR**: Tax fields are now consistent and displays tax scope during tax selection. **task**-4184119 **Community PR**: https://github.com/odoo/odoo/pull/184073
Point of Sale payment method setup is streamlined by letting users enter shared provider details once and reuse them automatically. Online payment methods are now created through a clearer payment type choice, reducing repeated data entry and configuration effort.
Original PR description
pos_*: pos_iot, pos_iot_six, pos_settle_due, pos_urban_piper Before this commit: ========== - Users had to add common field values for the same provider-based method multiple times, which was time-consuming. - There is a boolean field called `is_online_payment` used to indicate whether an online payment method is being created. After this commit: ========== - Users only need to add common field values once. After that, common field values are automatically populated, saving time when creating payment methods. - The `is_online_payment` field has been removed from `pos.payment.method`. The selection value `Online` has been added to create an online payment method. Related PR: Community: https://github.com/odoo/odoo/pull/175119 Upgrade: https://github.com/odoo/upgrade/pull/6329 task-3506646
Users can now link chart titles and axis labels to spreadsheet cells, so chart text updates from the data source instead of being typed manually. This makes spreadsheet charts easier to maintain and keeps reports more consistent when values or labels change.
Original PR description
## Description - Now users can select a cell to set the chart title. This works for any chart type. Task: [3693157](https://www.odoo.com/web#id=3693157&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Appointment booking data and customer handling were cleaned up to make the experience more reliable and easier to maintain. Demo content and test coverage were improved, including clearer appointment questions and booking flows, helping teams validate the customer booking process with more confidence.
6 changes
Resolved issues and error corrections
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
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 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
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
3 changes
Enhancements to existing features
This update enhances the Odoo Amazon connector by making it more adaptable. Developers can now easily customize and extend the module's functionality to better suit their specific needs. This improves the overall flexibility and integration capabilities of the Amazon sales process within Odoo.
Original PR description
Add some hooks and tweaks to improve the experience to customize/improve on top of this module. Info: @wt-io-it
Resolved issues and error corrections
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-4137931