Daily updates from Odoo
Thursday, May 8, 2025
45 changes · 18.0
New functionality added to Odoo
Adds support for Colombian mandate invoices in electronic invoicing, including product settings and the required invoice XML details. This helps businesses in Colombia issue compliant mandate-related invoices through Odoo.
Original PR description
Extension of l10n_co_edi to allow creation of mandate invoices. - Adding mandate-related fields for product_template. - Adding relevant EDI XML section for mandate products. Task [link](https://www.odoo.com/odoo/project/967/tasks/4302423) task-4302423
Enhancements to existing features
Partner lists now include the invoice sending method as a hidden field, allowing teams to use mass editing when they need to update how invoices are sent. This reduces manual work when maintaining customer billing preferences.
Original PR description
Add the Invoice Sending Method field to the partner's list view to enable mass edit. task-no (feedback from WTA)
The Guatemala localization now supports local CUI and NIT identification types and includes Guatemala-specific fuel taxes. This helps companies operating in Guatemala keep partner records and tax calculations aligned with local requirements, with updated demo data to reflect the new setup.
Original PR description
Added support for CUI and NIT identification types, added GT-specific fuel taxes (requiring a dependancy on account_tax_python), updated demo data. CUI for demo_partner set to an obviously fake 1111111100000 for the moment as the originally provided one doesn't pass the validation. To work alongside l10n_co, requires the fix in https://github.com/odoo/enterprise/pull/81216 (temporary branch for 18.0 to work with the runbot is added here https://github.com/odoo/enterprise/pull/80671) task-4318265 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The purchase product category search view now places the “In the order” filter in its own section and in a clearer position. This makes it easier for purchasing users to compare products and prices when reviewing order-related items.
Original PR description
Description of the issue/feature this PR addresses: When purchasing a product in a unit different than the product unit, it is not easy to compare price for purchaser (alternative, ...) Current behavior before PR: Desired behavior after PR is merged: - One line change for purchase category search view, to add the "In the order" filter in its own section and change its order within the search view, the rest of the changes are on-save auto format. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Deleting expenses is now much faster when accounting records are large. This reduces waiting time for users and improves day-to-day performance without changing how expenses work.
Original PR description
Description ----------- Deleting an expense is slow when the `account_move_line` table is large, as the `Many2one`/`fkey` `expense_id` needs to be set to `NULL` where necessary. If there is no index on the `fkey`, it's `Seq. Scan` on the table `account_move_line`. Benchmark: ---------- On odoo.com, unlinking an expense took: | Before | After | |--------|-------| | 10s | 58ms | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Financial report settings now show the integer rounding option directly in the report options. This makes the setting easier to discover and use without needing technical knowledge or code inspection.
Original PR description
This is a useful option that is hard to know about unless you read the code or are told it exists. It should be visible in the report options. In the context of: task-4734528
Resolved issues and error corrections
This fix prevents point of sale order lines with different prices from being combined. It helps keep receipts and order records accurate when the same product is sold at different prices.
Original PR description
Before this commit, the can_be_merged_with method did not work correctly because an incorrect argument was passed to floatIsZero. As a result, orderlines with different prices could be merged together, leading to inaccurate order information. opw-4778629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where increasing the quantity of a sold kit could create too many delivery quantities when the kit included both made-to-order and standard components. Businesses can now update kit sale orders without causing incorrect deliveries or extra stock movements.
Original PR description
### Steps to reproduce: - In the settings enable Multi-Step - Unarchive the MTO route - Create a storable product P with bom of type kit: - 1 x MTO COMP: with routes MTO and buy and set vendor - 1 X…
### Steps to reproduce:
- In the settings enable Multi-Step
- Unarchive the MTO route
- Create a storable product P with bom of type kit:
- 1 x MTO COMP: with routes MTO and buy and set vendor
- 1 X not MTO COMP: without routes
- Create and confirm a sale order for 1 units of P
- Update the quantity of the sale order line from 1 to 5
#### > The delivery is now for 6 units of both kit component
### Cause of the issue:
Updating the quantity on the SOL will launch a call of the `_action_launch_stock_rule`.The quantity of the new procurement is then processed by these lines based on the kit data's: https://github.com/odoo/odoo/blob/65704e58fda293af727f76d5c0741b135817db99/addons/sale_stock/models/sale_order_line.py#L359 https://github.com/odoo/odoo/blob/65704e58fda293af727f76d5c0741b135817db99/addons/sale_mrp/models/sale_order_line.py#L153-L160 However, since one component uses the MTO route and the other does not the filter based on rules will fail since one of the component move refer to the mto rule and the other one to the delivery rule. In particular the computation will always lead to a result of 0 no matter how many are really processed because only one of the 2 moves can respect the filter.
opw-4700925
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe web app icon has been updated so it is properly centered and uses Odoo’s main brand color consistently across icon formats. This improves the visual polish and brand consistency when users install or view the app icon on their devices.
Original PR description
This commit fixes the position and update the color being used in the both SVG and PNG versions of the icon. The main #714B67 color is now used and everything is centered. The shadow has been removed.
Stripe subscription payments now only request saved payment method setup when it is actually needed and supported. This prevents customers from seeing an error during payment when saving payment methods is disabled or unavailable.
Original PR description
To reproduce: - Enable Stripe payment provider, and disable "Allow Saving Payment Methods" - Create a subscription and 'Sent' it - Click on "Preview" and try to paid using payment method provided by Stripe. An error is raised: ``` The provided setup_future_usage (null) does not match the expected setup_future_usage (off_session). Try confirming with a Payment Intent that is configured to use the same parameters as Stripe Elements. ``` This commit ensure we only request for tokenization if it's required and both the provider and the payment method support it. opw-4605528 opw-4723230
This fixes a layout issue in printed purchase order PDFs where the totals and taxes block could appear in the wrong position on the right side of the page. Purchase documents should now print with a clearer, correctly aligned totals section, reducing confusion for vendors and internal users.
Original PR description
-> Issue: - PDF purchase order on the total table on the right side of the page encounters a display issue. -> Steps to reproduce: - Install the Purchase app - Navigate to the Purchase app - Open any purchase order - Then navigate to the settings - Click to Print - Print the Purchase Order report -> Cause: - The issue is caused because of this #204575 new commit. OPW: 4754858 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
Purchase order PDFs now display the tax totals in the correct position on the right side of the report. This improves document readability and helps ensure printed purchase orders look professional and consistent.
Original PR description
Steps to reproduce: 1. Go to Purchase > Open a purchase order record 2. Click on Print > Purchase Order Issue: The tax totals section of the table appears misaligned or on the incorrect side of the page in the generated PDF. Solution: Added class ms-auto to the tax totals element to ensure it aligns correctly to the right side. opw: 4771854
This fixes scheduled automation rules that used relative date filters such as “is within the last month.” These rules will now run reliably instead of failing silently when processed in the background.
Original PR description
# Bug: Currently, base automations that use filters constructed by the front-end using `context_today` and `relativedelta` will fail. These are for example constructed when using the "is within"…
# Bug:
Currently, base automations that use filters constructed by the front-end using `context_today` and `relativedelta` will fail.
These are for example constructed when using the "is within" operator for filter domains, producing search domains like: "Created on is within -1 months"
```
["&", ("create_date", ">=", datetime.datetime.combine(context_today() +
relativedelta(months = -1), datetime.time(0, 0, 0)).to_utc().strftime("%Y-%m-%d %H:%M:%S")),
("create_date", "<=", datetime.datetime.combine(context_today(),
datetime.time(0, 0, 0)).to_utc().strftime("%Y-%m-%d %H:%M:%S"))]
```
When running the CRON for the automation rules, it will silently fail throwing a `NameError: name 'context_today' is not defined` error.
# Proposed solution:
Extend the `eval_context` dictionnary in `_get_eval_context` to whitelist the needed methods to resolve such filter domains. Additionally replace `.to_utc()` calls that only make sense when evaluating the filter domain in thre front-end JS
opw-4763409
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prRazorpay payment records can no longer have key reference or payment method details changed once a transaction is authorized or completed. This helps protect payment accuracy and prevents accidental or unauthorized changes after confirmation.
Original PR description
This measure prevents any accidental or unauthorized modifications to these critical fields after the transition has been done or authorized, thereby ensuring data accuracy and consistency. task - 4680092 you can check this for reference  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents access errors when shared products are used across multiple companies with restricted company data access. It ensures the product cost currency can still be calculated correctly, reducing disruptions for users working in multi-company environments.
Original PR description
Similar fix as what has already be done in this following commit: https://github.com/odoo/odoo/commit/483024d122565523a8f1788201ecce47c6d1dfd0 In multi-company setups, `product.template` records can be shared, but access to `res.company` may be restricted. To avoid access errors when computing `product.template.cost_currency_id`, use `sudo()` when reading `company_id.currency_id`. opw: 4744418 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The event kiosk app now uses the right launch address instead of conflicting with the main Odoo app address. This helps staff open the event kiosk reliably and avoids confusion when using the app as an installed web app.
Original PR description
This commit fixes the URL being used in the path argument given to the 'scoped_app' route. Since '/odoo' is already used by the main PWA, we must not use 'odoo' in the actual path of the PWA.
Customers using self-ordering with payment after each order can now cancel an incorrect order and start again instead of getting stuck. This reduces frustration and helps keep self-service point-of-sale flows moving smoothly.
Original PR description
When configuring a self-ordering PoS in pay after each, if the user made an error in the order and wants to modify it, the user is blocked and cannot modify the order. This commit fixes this behavior by allowing the user to cancel the order and recreate it if needed.
This fixes an error that could occur when preparing a UK CIS monthly return before all options were set. The change adds a safe default so the form can load and update reliably, reducing interruptions for users completing compliance reporting.
Original PR description
when the option is not set key error is raised , this due to when onchange is called the default value is not set but being also called with empty option build_error-107919
Fixed a rounding mismatch in Mexican electronic invoices for external trade when product prices use more than two decimal places. This prevents valid USD invoices from being rejected during CFDI validation because line totals and invoice totals no longer disagree.
Original PR description
Steps to reproduce: - Raise Product Price Accuracy to 6 - Set Global Rounding - Fetch latest currency rate for USD from Bank of Mexico - Create a [TEST] Product with: - UNSPSC Category: 12141502…
Steps to reproduce: - Raise Product Price Accuracy to 6 - Set Global Rounding - Fetch latest currency rate for USD from Bank of Mexico - Create a [TEST] Product with: - UNSPSC Category: 12141502 Magnesium Mg - UMT Aduana: kg - Make an Invoice as follows: - Customer: Deco Addict - Currency USD - Product: [TEST] - Price: 3,114.515000 - Qty UMT: 11 - Incoterm: EX WORKS - External Trade: Definitive - Confirm Invoice - Send CFDI Issue: Validation will fail with error """ Code : CCE122 Message : El atributo cce20:ComercioExterior:TotalUSD no coincide con la suma de ValorDolares de las mercancías. """ In the xml, the ValorDolares for the sold item will be 3114.5150 but the attribute TotalUSD will be 3114.52 This occurs because ValorDolares are emitted as unrounded amount, but TotalUSD is rounded to 2 decimals. When working with 3+ digits the amounts might not add up correctly. Note: Before version 18, ValorDolares (`product_values['total']`) amount was already rounded according to the currency decimals (2) and there was no issue opw-4662692 opw-4686226
Batch payments without linked accounting entries now use the correct company-currency conversion during bank reconciliation. This prevents misleading debit and credit amounts when matching foreign-currency vendor batch payments, improving accuracy for accounting teams.
Original PR description
Steps to reproduce: - Activate foreign currency EUR (main company in USD) - Have a Bank journal in EUR - Create one Vendor "Send" payment of 100 EUR - Create a new Vendor batch payment and add the payment. - Open EUR Bank and register an outgoing transaction of 100 EUR - Match the transaction with the Batch payment Issue: Looking at the debit/credit columns it can be seen that the transaction amount is properly converted in company currency, but the batch amount is not converted (rate 1.00) This occurs because when the payments in a batch don't have an associated move, the amount residual is converted from payment currency (EUR) to batch currency (still EUR) and not company currency (USD) opw-4656807
The update makes automated spreadsheet document tests more dependable by searching directly for the needed folder instead of relying on where it appears in the folder list. This reduces random test failures and helps keep quality checks stable without changing user-facing behavior.
Original PR description
Sometimes, when opening the documents folder, test folder is hidden on a second page, even if we open a parent folder first. With this fix, we search for the folder directly through search bar, eliminating undeterminism from the test.
The UK CIS report now rounds total payments and materials costs to whole pounds. This ensures the report values match HMRC requirements, so businesses can submit valid CIS returns.
Original PR description
Before, the feature was not usable because HMRC would only accept whole pounds for the total payments made and the materials cost. The fix was to round the values on the report to whoule pounds for those two columns. This way, it would become valid for HMRC as the return is based on those report values. opw-4686819
Budget reports can now open correctly when a purchase order line has no value but is linked only to a credit note, creating a negative invoiced quantity. This prevents an error that could block users from viewing budget information in that edge case.
Original PR description
It's possible to have a 0 purchase order line with a negative invoiced qty if there is only a credit note linked to the PO. When the budget report process this order line, it will trigger a traceback. This commit aims to handle this case so the report can be open without issue. opw-4749480
The Accounting Reports interface now keeps the tax report cog menu visible on narrower screens or when users zoom in. This helps users access options such as the Argentine VAT Book ZIP export without needing to adjust browser width or zoom.
Original PR description
**Steps to reproduce:** - Install Accounting - Install a module that adds a button to tax report (e.g. l10n_ar) - Switch to an Argentinian company (e.g. (AR) Responsable Inscripto) - Go to…
**Steps to reproduce:** - Install Accounting - Install a module that adds a button to tax report (e.g. l10n_ar) - Switch to an Argentinian company (e.g. (AR) Responsable Inscripto) - Go to "Accounting / Reporting / Statements Reports / Tax Return" (i.e. Tax Report) - Select "Argentinean VAT Book (AR)" as report - A cog button should appear after the report name with "VAT Book (ZIP)" option - With browser debug feature, switch to a responsive display and reduce the width or - Repeatedly increase the zoom to increase the size of the button **Issue:** For a certain range of width the cog button is not visible. **Cause:** ".o_control_panel_breadcrumbs" element that contains the buttons has a min-width of 200px, hiding all elements that are after these 200px when reducing the width. **Solution:** Increase the min-width to 350px. The value is arbitrary but it covers well this use case. With a lower value, the cog button could still be hidden in the case of the Argentinian Tax Report in Spanish language. opw-4747697
Uploading a file from a shared Documents folder now attaches it to the specific request the user selected. This prevents files from being incorrectly added to another available folder or request when multiple upload options are present.
Original PR description
Step to reproduce : - Create a folder with a sub folder and a request or two requests. - Share the parent folder with edit permission to anyone. - Go to the public folder view. - Upload a file for the last request document. - The file will be uploaded to the first editable folder/request found. This was due to a hidden form tag to upload file to sub folders which was using the same class as the one used by the request documents (o_request_upload). Using class instead of id also means that it wasn't possible to share more than one request document. Task-4718126
Documentation and clarification updates
The pull request updates the contributor license agreement record for CRogos. This is an administrative legal documentation change that helps keep contribution records current and does not affect product functionality.
Miscellaneous changes
## Issue: A standard IBAN always breaks into two lines on the DIN 5008 report. ## Steps to reproduce: - Install l10n_de; - Change to DE Company; - Navigate to Settings; - Under the Companies section, click `Configure Document Layout`; - Select `DIN 5008` layout; - Check footer display. ## Cause: The commit 3a139b15a5270fb466b608b340013c93214557bb reset the font-size without thinking about the IBAN display. opw-4680515 --- I confirm I have signed the CLA and read the PR guide
Original PR description
## Issue: A standard IBAN always breaks into two lines on the DIN 5008 report. ## Steps to reproduce: - Install l10n_de; - Change to DE Company; - Navigate to Settings; - Under the Companies section, click `Configure Document Layout`; - Select `DIN 5008` layout; - Check footer display. ## Cause: The commit 3a139b15a5270fb466b608b340013c93214557bb reset the font-size without thinking about the IBAN display. opw-4680515 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204296
Purpose of the commit: The recipient list overflows when the screen size is increased. This commit resolves the issue by showing the overflowing text on the next line. task-4417552 Forward-Port-Of: odoo/odoo#191880
Original PR description
Purpose of the commit: The recipient list overflows when the screen size is increased. This commit resolves the issue by showing the overflowing text on the next line. task-4417552 Forward-Port-Of: odoo/odoo#191880
This commit removes the z-index priority of kanban groups, headers and quick create over the no-content helper since it became useless with https://github.com/odoo/odoo/pull/148138 and can now cause display issues when these elements are on top of each other (which can happen with the quick create column). task-4778356 Forward-Port-Of: odoo/odoo#208795
Original PR description
This commit removes the z-index priority of kanban groups, headers and quick create over the no-content helper since it became useless with https://github.com/odoo/odoo/pull/148138 and can now cause display issues when these elements are on top of each other (which can happen with the quick create column). task-4778356 Forward-Port-Of: odoo/odoo#208795
### Steps to reproduce: - install "l10n_de" and switch to a German company - Go to a contact, in the page Accounting > Electronic Invoicing change the format to "Factur-X (CII)" - Create an invoice for this contact - Add a start and end date on the line of this invoice - Confirm and send to Factur-X - In the generated XML there is no trace of the start or end dates ### Solution: Set the variables to add the `BillingSpecifiedPeriod` in the XML. Put `invoice_date` as start date and `invo
Original PR description
### Steps to reproduce: - install "l10n_de" and switch to a German company - Go to a contact, in the page Accounting > Electronic Invoicing change the format to "Factur-X (CII)" - Create an invoice for this contact - Add a start and end date on the line of this invoice - Confirm and send to Factur-X - In the generated XML there is no trace of the start or end dates ### Solution: Set the variables to add the `BillingSpecifiedPeriod` in the XML. Put `invoice_date` as start date and `invoice_date_due` as end date. opw-4680890 Forward-Port-Of: odoo/odoo#208930 Forward-Port-Of: odoo/odoo#208088
- saas-17.4 issue 2: ### Steps to Reproduce: - Install the hr_timesheet module. - Create a portal user. - Create a project, task, and sub-task (with timesheet entries). - Share the project with the portal user. - Log in as the portal user. - Open the shared project and navigate to the task. - Open timesheet. ### Issue: When a portal user tries to open the timesheet of a shared project task from a mobile device, an error occurs. ### Cause: The po
Original PR description
- saas-17.4 issue 2: ### Steps to Reproduce: - Install the hr_timesheet module. - Create a portal user. - Create a project, task, and sub-task (with timesheet entries). - Share the project with the portal user. - Log in as the portal user. - Open the shared project and navigate to the task. - Open timesheet. ### Issue: When a portal user tries to open the timesheet of a shared project task from a mobile device, an error occurs. ### Cause: The portal user does not have access to the analytic account, which triggers this error. The form view for analytic.line in the analytic module includes analyti_account_id. ### Solution: In this commit, we have used the `timesheet_view_form_portal_user` form view. This view does not include analytic_account_id, which prevents the access error from occurring. task-4369891 Forward-Port-Of: odoo/odoo#168847
Add in missing modules to tx/config where their pots were auto-added by the pot export sync. Note that new pot files that were only for model names (i.e. not user facing) are usually bridge modules with nothing to translate => they weren't added to the config file --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Add in missing modules to tx/config where their pots were auto-added by the pot export sync. Note that new pot files that were only for model names (i.e. not user facing) are usually bridge modules with nothing to translate => they weren't added to the config file --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This commit, fixes the scroll of the control panel when we opened the search bar. The bug happened because when we scroll we save the last scroll position into `oldScrollTop` variable. But when we "open" the search bar a "new line" (search input) is rendered so the height of the scrolling element is increase (by the height of the search input line). Also, a scroll is triggered so the view remains at the same position. But the `oldScrollTop` is not adapted to reflect the new height of the scroll
Original PR description
This commit, fixes the scroll of the control panel when we opened the search bar. The bug happened because when we scroll we save the last scroll position into `oldScrollTop` variable. But when we…
This commit, fixes the scroll of the control panel when we opened the search bar. The bug happened because when we scroll we save the last scroll position into `oldScrollTop` variable. But when we "open" the search bar a "new line" (search input) is rendered so the height of the scrolling element is increase (by the height of the search input line). Also, a scroll is triggered so the view remains at the same position. But the `oldScrollTop` is not adapted to reflect the new height of the scrolling element. When the new delta was calculated (in the scroll handler) to set the top position of the control panel, a wrong value was set as there was an additional offset of the height of the "search input line". This commit adds an ResizeObserver to observe the scrolling element and so adapt the `oldScrollTop` variable to adapt the delta of its height. task-4466063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208787
This commit modifies the condition for the Peppol information footnote to be added to the mail to be only when the country of both the company and the partner is one of the following: BE/LU/NL/SE/NO. task-id: 4750146 Forward-Port-Of: odoo/odoo#207270
Original PR description
This commit modifies the condition for the Peppol information footnote to be added to the mail to be only when the country of both the company and the partner is one of the following: BE/LU/NL/SE/NO. task-id: 4750146 Forward-Port-Of: odoo/odoo#207270
Steps to reproduce: - With an AE Company - Enable Multicurrency (USD) - Create an invoice in USD with total 0.00 - Print Issue: Traceback will raise """ odoo.addons.base.models.ir_qweb.QWebException: Error while render the template ZeroDivisionError: float division by zero Template: account.document_tax_totals_company_currency_template Path: /t/div/table/tr[1]/td[2] Node: <td class="text-end" t-out="exchange_rate" t-options="{"widget": "float", "precision"
Original PR description
Steps to reproduce:
- With an AE Company
- Enable Multicurrency (USD)
- Create an invoice in USD with total 0.00
- Print
Issue: Traceback will raise
"""
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template ZeroDivisionError: float division by zero
Template: account.document_tax_totals_company_currency_template Path: /t/div/table/tr[1]/td[2]
Node: <td class="text-end" t-out="exchange_rate" t-options="{"widget": "float", "precision": 5}"/>
"""
opw-4724401
Forward-Port-Of: odoo/odoo#208396Versions -------- - 16.0+ Steps (saas-17.4) ----------------- 1. Install `l10n_ar_website_sale`; 2. run `:TestWebsiteSaleProductFilters` test suite. Issue ----- 2 tests fails. Cause ----- The filters search for sale orders from `get_current_website`. Even though the correct website is passed to the `MockRequest`, the result of the call is a website from an Argentinian company with no sales orders. Solution -------- Add `force_website_id` to the `MockRequest` session, so `g
Original PR description
Versions -------- - 16.0+ Steps (saas-17.4) ----------------- 1. Install `l10n_ar_website_sale`; 2. run `:TestWebsiteSaleProductFilters` test suite. Issue ----- 2 tests fails. Cause ----- The filters search for sale orders from `get_current_website`. Even though the correct website is passed to the `MockRequest`, the result of the call is a website from an Argentinian company with no sales orders. Solution -------- Add `force_website_id` to the `MockRequest` session, so `get_current_website` returns the intended website: https://github.com/odoo/odoo/blob/1ea4f285aba925d437a5129cd36143d9987c6e6a/addons/website/models/website.py#L1121 > [!Note] > Alternatively, we can check for `request.website` being set in `get_current_website`. No idea if there's a reason it doesn't already. runbot-111554 runbot-111555 Forward-Port-Of: odoo/odoo#208687 Forward-Port-Of: odoo/odoo#201433
Issue ----- For subcontracted services, branch companies don't have taxes on PO lines when it is created by a SO. Steps to reproduce ----- - Install MRP, Sale, Purchase apps - Create a branch company and switch to the branch - In the settings, enable subcontracting - Create a product - Type: service - Add a vendor for the product, with some tax applied - Tick the "Subcontract Service" box - Create & confirm a sale for the product - Open the linked PO -> The PO doesn
Original PR description
Issue
-----
For subcontracted services, branch companies don't have taxes on PO lines when it is created by a SO.
Steps to reproduce
-----
- Install MRP, Sale, Purchase apps
- Create a branch company and switch to the branch
- In the settings, enable subcontracting
- Create a product
- Type: service
- Add a vendor for the product, with some tax applied
- Tick the "Subcontract Service" box
- Create & confirm a sale for the product
- Open the linked PO
-> The PO doesn't have the tax specified on the product page
Cause
-----
The tax is defined in the parent, but when applied to the POL it is matched to the PO's company.
Forward-Port-Of: odoo/odoo#208616Description of the issue/feature this PR addresses: It's possible to setup an inherited view with groups if we update the mode Steps: - Open an inherited view form - Change its mode to "Base" - Add a group - Rollback the mode to "Inherited" - Save, no problem - Try to upgrade a module linked to this view Current behavior before PR: - Traceback as inherited view cannot have groups Desired behavior after PR is merged: - Save is not possible opw-3263438 opw-3774300 --- I
Original PR description
Description of the issue/feature this PR addresses: It's possible to setup an inherited view with groups if we update the mode Steps: - Open an inherited view form - Change its mode to "Base" - Add a group - Rollback the mode to "Inherited" - Save, no problem - Try to upgrade a module linked to this view Current behavior before PR: - Traceback as inherited view cannot have groups Desired behavior after PR is merged: - Save is not possible opw-3263438 opw-3774300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156279
This commit removes the demo data for portal user as a portal user cannot be assigned to tasks. taskid:3703637 Forward-Port-Of: odoo/enterprise#81826 Forward-Port-Of: odoo/enterprise#56588
Original PR description
This commit removes the demo data for portal user as a portal user cannot be assigned to tasks. taskid:3703637 Forward-Port-Of: odoo/enterprise#81826 Forward-Port-Of: odoo/enterprise#56588
In the community PR, we have used the timesheet_view_form_portal_user form view for the portal user. To ensure that the status bar is not visible to the portal user, we added a group restriction. An alternative approach would be to hide the status bar based on context, but I did not find it suitable. Therefore, we opted to use the group restriction. task-3969988 Forward-Port-Of: odoo/enterprise#74760
Original PR description
In the community PR, we have used the timesheet_view_form_portal_user form view for the portal user. To ensure that the status bar is not visible to the portal user, we added a group restriction. An alternative approach would be to hide the status bar based on context, but I did not find it suitable. Therefore, we opted to use the group restriction. task-3969988 Forward-Port-Of: odoo/enterprise#74760
Add in missing modules to tx/config where their pots were auto-added by the pot export sync. Note that new pot files that were only for model names (i.e. not user facing) are usually bridge modules with nothing to translate => they weren't added to the config file
Original PR description
Add in missing modules to tx/config where their pots were auto-added by the pot export sync. Note that new pot files that were only for model names (i.e. not user facing) are usually bridge modules with nothing to translate => they weren't added to the config file
Steps --------- 1. Have `accountant` and `account_accountant` installed 2. Set up an online bank -> see Odoofin steps on Knowledge 3. Set another user's access group to `Advanced Billing` for accounting 4. Login as that user and access the accounting app -> Access error for account.online.link Problem --------- Advanced billing should have access to the dashboard due to its role. The group `group_account_readonly` has read access to the model, as suggested by its name. However, the gro
Original PR description
Steps --------- 1. Have `accountant` and `account_accountant` installed 2. Set up an online bank -> see Odoofin steps on Knowledge 3. Set another user's access group to `Advanced Billing` for accounting 4. Login as that user and access the accounting app -> Access error for account.online.link Problem --------- Advanced billing should have access to the dashboard due to its role. The group `group_account_readonly` has read access to the model, as suggested by its name. However, the group `group_account_basic` does not have any access. Solution --------- Add 2 access rules on `account.online.link` that allows a Advanced billing user to see (and only see) those records. Note that it does not change anything for `group_account_user` which inherits both from `group_account_readonly` and `group_account_basic`, since it already had readonly access thanks to the first aforementioned. task-4731654 Forward-Port-Of: odoo/enterprise#83889
Description of the issue this commit addresses: Zero balance lines are creating friction when reconciling lines. They will never need a renconciliation but they still impair the user's ability to reconcile other lines together if selected. --- Desired behavior after this commit is merged: When reconciling lines, the zero balance ones are simply ignored and the reconciliation proceeds as if they were not selected. --- task-4723956 Forward-Port-Of: odoo/enterprise#84851
Original PR description
Description of the issue this commit addresses: Zero balance lines are creating friction when reconciling lines. They will never need a renconciliation but they still impair the user's ability to reconcile other lines together if selected. --- Desired behavior after this commit is merged: When reconciling lines, the zero balance ones are simply ignored and the reconciliation proceeds as if they were not selected. --- task-4723956 Forward-Port-Of: odoo/enterprise#84851
Currently, an empty partner ref in an FEC line could incorrectly match a partner with an empty ref. This fix ensures that only non-empty refs are considered when processing FEC files. Steps to reproduce: 1. Install the `l10n_fr_fec_import` module. 2. Create a contact and set its ref to an empty string (`""`). 3. Import an FEC file containing lines without `CompAuxNum`. 4. The created contact will be incorrectly assigned to all lines without `CompAuxNum`. opw-4592290 Forward-Port-O
Original PR description
Currently, an empty partner ref in an FEC line could incorrectly match a partner with an empty ref. This fix ensures that only non-empty refs are considered when processing FEC files. Steps to reproduce: 1. Install the `l10n_fr_fec_import` module. 2. Create a contact and set its ref to an empty string (`""`). 3. Import an FEC file containing lines without `CompAuxNum`. 4. The created contact will be incorrectly assigned to all lines without `CompAuxNum`. opw-4592290 Forward-Port-Of: odoo/enterprise#84855 Forward-Port-Of: odoo/enterprise#81676
In 65576b109249fbb0f111f57b42d48940a46f63db we added schema files to mock the l10n_ar_edi services. But their filenames contained `?` which is not a valid filename character on Windows. As a result, users cannot pull the repository on Windows anymore. This commit removes the `?` character from the filenames. task-none Forward-Port-Of: odoo/enterprise#84852
Original PR description
In 65576b109249fbb0f111f57b42d48940a46f63db we added schema files to mock the l10n_ar_edi services. But their filenames contained `?` which is not a valid filename character on Windows. As a result, users cannot pull the repository on Windows anymore. This commit removes the `?` character from the filenames. task-none Forward-Port-Of: odoo/enterprise#84852