Daily updates from Odoo
Thursday, March 13, 2025
48 changes · 18.0
Enhancements to existing features
Belgian accounting now supports partial VAT deduction, such as reclaiming only part of VAT on EU purchases like fuel or electricity. This helps businesses record VAT more accurately and stay aligned with Belgian tax requirements.
Original PR description
- Implemented support for partial VAT deduction (e.g., 35% reclaimable VAT on EU acquisitions like fuel or electricity). task-4575302
South African customer invoice reports now display “Tax Invoice” when the company is VAT registered, helping meet local business payment and compliance expectations. The update also handles companies without a VAT number so their invoice wording remains appropriate.
Original PR description
In South Africa, many companies require that 'Tax Invoice' appears on any invoice they will pay if you are VAT registered. I took inspiration from the Zambian localisation, I just added a case for when you are not VAT registered (i.e. don't have a VAT number set). I'll create a separate PR for 16.0 since the invoice report layout changed in 18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Belgian reports module no longer shows VAT report banners for warnings, reducing unnecessary alerts for users. Rejection banners remain in place so important blocking issues are still clearly communicated.
Original PR description
- Removed VAT report banners for warnings but kept rejection banners. task-4575302
The Estonia reporting module now supports the new 13% VAT rate that applies from January 1, 2025. This helps Estonian businesses keep tax reporting and VAT XML exports aligned with upcoming legal requirements.
Original PR description
This adds 13% tax logic to Estonia Localization and VAT tax report. 13% is valid from 01.01.2025 Also in vat xml t-out is used for values true and false as otherwise these are translated during rendering.
Resolved issues and error corrections
This update corrects a styling rule in the Spreadsheet app so the interface displays as intended. It is a small visual fix that helps keep the spreadsheet experience consistent for users.
Original PR description
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 interface no longer shows prices on every product card in the main product screen. Prices are now shown only when selecting items within a combo, reducing clutter and keeping the checkout view consistent.
Original PR description
- Fix issue where the price was displayed on every product card (like in product screen). To fix this we want to only display the price of the card in combo choice. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents blank certificate or key error messages from appearing when records are created directly in the database. Users will only see a loading error when there is an actual message to show, reducing confusion in certificate management screens.
Original PR description
Problem --------- When the certificate or the key is created through SQL INSERT, the compute functions are not triggered. This lead to the 'loading_error' field to remain FALSE. Since the condition that checked whether or not to display the loading error message was "loading_error == ''", it meant that the message would be display when it was equal to FALSE. Instead, we now just check if there is a loading error message with 'not loading_error' which solves the issue and makes it more robust. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes an internal landed costs test check records in a consistent order. It helps prevent false test failures, improving confidence in the inventory costing validation process without changing user-facing behavior.
Original PR description
This commit orders the stock valuation layer of multiple stock moves by product to make sure the assert targets the right layer index in the loop. runbot: 99086 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures overtime hours that have not yet been validated are calculated correctly when processing multiple attendance records at once. It prevents an error that could interrupt attendance or overtime reporting, helping HR teams get complete results.
Original PR description
Steps: - Compute no_validated_overtime_hours for many records Actual result: - Singleton expected Expected result: - Compute is done for all records
The signup reminder process now sends pending emails without repeatedly processing the same users. This prevents duplicate or endless reminder emails when there are more than 100 unregistered users, improving reliability for customer communications.
Original PR description
When we have more than 100 users, we send e-mails in an endless loop because we always process the same records. After this change, we send all e-mails in one call. Backport of odoo/odoo#199091 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Etisalat email addresses ending in @eim.ae are now treated like common personal email providers. This prevents CRM from incorrectly grouping unrelated leads just because they share this widely used email domain.
Original PR description
The email domain eim.ae is associated with Etisalat, a major telecommunications provider in the United Arab Emirates. Addresses ending with @eim.ae are commonly used by individuals and businesses in the UAE, similar to how @gmail.com addresses are used globally. That's why we should not use it for detect it similar leads. Reproduce --- - Install crm - Create a lead - Add email with @eim.ae as domain - BUG: Similar lead identified based on the email domain opw-4506179
This fixes an issue where split or wave-based delivery transfers from the same sales order could receive different scheduled dates. After the change, copied transfers keep the intended sales order delivery date, helping warehouse teams plan shipments accurately.
Original PR description
- Activate wave transfers and group by product or any other, easy to see it by product. - Create a sales order with two different products in the sales order lines - Changed the delivery date in the other info tab. - When confirming the sales order, two transfers will be created, each will have one product. Current behavior: - One picking will respect the scheduled date and the other one will have it for today. Expected: - Both picking have the sale order schedule date. It happens because the picking copy miss some data opw-4571808 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents call events from being handled before the related call session is ready. It reduces the risk of intermittent audio or video issues caused by timing differences between network and server updates.
Original PR description
Before this commit, we could get events for a RtcSession that is not yet available. This can happen when network information (SFU/p2p) races Odoo server information (bus). As RtcSessions' source of truth is the Odoo server, information obtained from the call network are only acknowledged if we have the record from Odoo. This commit fixes this issue by awaiting sessions for which events are obtained. Fetching should not be necessary as: - if the event is for a session that exists, the client will eventually obtain it (from the bus message that is sent when a new is created, or by the `rtc_service.ping()` which periodically fetches sessions). - if the event is for a session that does not exist, fetching does not make sense.
This update fixes several automated guided checks so they wait for pages and forms to be ready before continuing. This reduces false failures in testing for website editing, online sales localization, inventory flows, and point-of-sale restaurant loyalty scenarios, helping teams validate changes more consistently.
Original PR description
- addons/l10n_br_website_sale/static/tests/tours/brazilian_address.js We need to wait the form is loaded before to modify address to prevent js failures. -…
- addons/l10n_br_website_sale/static/tests/tours/brazilian_address.js We need to wait the form is loaded before to modify address to prevent js failures. - addons/stock/static/tests/tours/stock_picking_tour.js We prefer to use more precise trigger instead of run with console.error(). As it's the last step, it's more efficient. - addons/website/static/tests/tours/client_action_redirect.js When we exit edit mode in website, we must wait the dom is stable to continue. - addons/website/tests/test_ui.py Add a step_delay to ensure tour works each time (undeterminisms) - addons/web_tour/static/src/tour_service/tour_helpers.js Harmonize usage of async / await. Wait the dom is stable before to click on a link. - addons/web_tour/static/src/tour_service/tour_automatic.js Set a large timeout when step is paused. 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 how custom text background colors appear in the HTML editor, especially in dark mode. Custom solid background colors now use partial opacity so highlighted text remains easier to read, while theme colors keep their existing behavior.
Original PR description
### Description of the issue/feature this PR addresses: - Applying a background color to text caused visibility issues in dark mode. ### Current behavior before PR: - 60% opacity is applied to background colors in the solid tab, except for theme colors. task-4566382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The web editor now removes hidden placeholder characters from emptied inline required fields before saving. This prevents fields that look empty to users from being incorrectly treated as filled, improving data accuracy.
Original PR description
### Description of the issue/feature this PR addresses: - Block elements: When emptied, a `<br>` is added. - Inline elements: Instead of a `<br>`, a zero-width space (ZWS) is inserted. This makes the field non-empty. ### Desired behavior after PR is merged: - Fields marked with `data-oe-zws-empty-inline` are cleaned by removing the zero-width space in cleanForSave, preventing non-empty fields from being saved. task-4575400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Inventory users with standard access can once again view and edit serial numbers without running into an access error. The change removes valuation details from the serial number form where those users do not have permission, preventing unnecessary disruption to daily inventory work.
Original PR description
steps to reproduce the bug: - install inventory and invoicing app - change the user access right of the inventory app to `User` - access any of the serial number you have in any of the apps having it Problem: Error is raised because no access right for the `stock.valuation.layer` model to the user group. new attribute `stock_valuation_layer_ids` was added to the `stock.lot`model on the stock_account module, and hence no access right for that model for the user group so now anyone with user access to inventory app won't be able to access the serial numbers or edit them opw-4466042 opw-4551745 Description of the issue/feature this PR addresses: Current behavior before PR: users with `user access right to inventory app` can't access the serial numbers Desired behavior after PR is merged: users with `user access right to inventory app` can access the serial numbers --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The shared spreadsheet view now consistently hides the download option when there is no pre-generated spreadsheet file to download. This avoids showing users an action that cannot work and keeps the sharing interface clearer.
Original PR description
### Description: In PR #192349, we hide the download button in the live shared spreadsheet, but it remained visible in the topbar menu. This commit ensures the button is also hidden in the topbar menu when no pre-generated spreadsheet is available. Task: 4625077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale screen no longer shows unintended product prices directly on product cards, restoring the expected product browsing experience. Combo product pricing has also been clarified so extra charges are displayed more appropriately during configuration.
Original PR description
Since commit 5a26402d33570dd6ad18be122aac74bfe8397445, product prices have been unintentionally displayed on product cards. This commit fixes that issue by hiding the unintended price display. Additionally, it improves how extra prices are shown on combo products, Task: 4644777
The Brazil AvaTax product form now keeps the relevant tax information section visible for service products. This ensures users can access the correct service-related fields instead of having the whole section hidden by mistake.
Original PR description
Small oversight in odoo/enterprise#79245. Don't hide the entire group for service products. Visibility for goods/service products is determined per field below. opw-4601199
Fixed an issue where notes added to trial balance accounts could disappear when account hierarchy and subtotals were enabled. This helps finance users reliably save and review annotations while working with grouped account reports.
Original PR description
Steps to reproduce: - open the trial balance with a company having some account groups (like BE company) - activate the hierarchy and subtotals filter - create an annotation for an account - press outside the popover to save the annotation - open the annotation popover -> The annotation is no longer visible Other similar issue - create an annotation (with again hierarchy activated) - directly create another one -> The popover disappear and no annotations are visible Cause of the issue: When grouping per hierarchy, the line ids contains some unnecessary components for these grouping per account groups, which need to be filtered out with the helper function already created to handle this case. opw-4546653
This fix prevents Sendcloud delivery processing from failing when a sales order includes a deposit line without a product. It helps sales teams continue using deposits on orders without disrupting shipping service calculations or order handling.
Original PR description
Fixed error when a deposit is set on sale order line because not product on line and not display_type.
Read-only users can now open payment records without errors caused by hidden direct debit mandate details. The mandate-related fields are limited to invoicing users, matching existing access rules and reducing disruption for users who only need to view payments.
Original PR description
Before this PR: - The SDD Mandate model was accessible only to invoicing users. - As a result, read-only users could not view payment records because some fields attempted to access the SDD Mandate model. After this PR: - Fields related to the SDD Mandate model are now restricted to invoicing users using the appropriate access groups. - This ensures that read-only users can view payment records without encountering access issues.
Mexican electronic invoices can now be printed even when the customer has no language set. The amount written in words uses the customer language when available, or the current user language otherwise, avoiding errors caused by an unavailable Spanish fallback.
Original PR description
When printing an invoice in the l10n_mx_edi module, a traceback occurs if the client's language is empty. This happens because the system previously defaulted to es_ES, which may not be activated. Steps to Reproduce: 1. Install the l10n_mx_edi module and switch to a Mexican company. 2. Enable multiple languages in the system. 3. Create an invoice and leave the customer's language empty (no language set). 4. Print the invoice. 5. Issue: A traceback occurs due to the missing es_ES language. Now, there is no fallback to es_ES when the client's language is empty. The amount-to-text conversion strictly relies on `self.partner_id.lang. If no language is set, the conversion translates to the user's language. opw-4572245
Barcode inventory adjustments now ignore customer, vendor, and other non-internal locations when choosing a default product location. This helps prevent stock corrections from being recorded in the wrong place unless a user explicitly scans that external location first.
Original PR description
Steps to Reproduce: 1. Create a storable product with inventory tracking and assign a barcode. 2. Create an internal transfer from “Partners/Customers” to “Virtual Locations/Inventory Adjustment”. 3.…
Steps to Reproduce: 1. Create a storable product with inventory tracking and assign a barcode. 2. Create an internal transfer from “Partners/Customers” to “Virtual Locations/Inventory Adjustment”. 3. This will generate two quants, one in Customers and another in Inventory Adjustment. 4. Navigate to Barcode > Inventory Adjustment and scan the product’s barcode. Issue: The scan triggers an inventory adjustment for the “Customer” location instead of the correct stock location. Technical Explanation: • The system fetches all quants related to the product, including those in Vendor, Customer, and Inventory Adjustment locations. • These locations have IDs lower than the stock location (e.g., Customers = 5, Stock = 8). • The front-end caches this data (dbIdCache) and calls _defaultLocation() to determine the location. • Since the cache is ordered by ID, the first location (Customers, ID 5) is incorrectly selected instead of the stock location (8). • As a result, the inventory adjustment is applied to the wrong location. Proposed Fix: • Filter the results to include only internal locations when fetching quants. • This prevents non-internal locations (Vendor, Customers, Inventory Adjustment) from being selected by default. • If a user needs to adjust inventory for an external location, they must first scan the location barcode before scanning the product. Task-4596699
This fix ensures upsell activity line text in Sales Subscriptions is translated correctly for users in different languages. It addresses a small localization issue so customer-facing and workflow information appears consistently in the user’s selected language.
Original PR description
Translation tool `_` does not work inside a generator, but new tool* based on the environment (`env._`) does. This commit fixes the issue in upsell activity lines. *https://github.com/odoo/odoo/commit/b794f0f332f473deb2c04eba60baf4761db3b508
Discarding a newly started timesheet entry from an existing timesheet record no longer triggers an error. This makes the Timesheets workflow more reliable for users who start an entry and then decide not to save it.
Original PR description
**Issue:** An error is raised when trying to discard a timesheet entry. **Steps to reproduce:** - Open Timesheets. - Open an existing entry by clicking on the magnifying glass. - Start a timesheet entry by clicking "Start". - Click on "Discard". opw-4614472
Users can now create a new quote calculator from quotation template settings without seeing a missing name error. New calculators are automatically labeled “New Spreadsheet” at first, so teams can proceed smoothly and rename them later if needed.
Original PR description
Steps: - Sales app > Configuration > Quotation Templates. - Create a New template. - In field 'Quote calculator' select 'search more..' - select 'New' button Issue: - New button throws validation error says missing required field 'name', blocking creation. Cause: - default value was not assigned to required field 'name' in respective model. Fix: - Added a default value for 'name' field, so creating a new quote calculator will initially be labeled as 'New Spreadsheet' and can be renamed as needed. opw-4552429
Corrects how discounted invoice amounts are rounded for Mexican electronic invoicing so totals match the sum of line discounts. This prevents valid invoices with certain discount combinations from being rejected during CFDI validation.
Original PR description
Steps to reproduce: - Create an invoice with the following lines: 1. Price Unit 3163.79 | Qty 1 | Discount 25% | Tax 16% 2. Price Unit 2992.41 | Qty 1 | Discount 25% | Tax 16% 3. Price Unit 3025.86 | Qty 1 | Discount 25% | Tax 16% - Confirm, Send to validation Issue: Validation will fail with error ``` Message : Error de validaciones adicionales [Error #CFDI40111] El TipoDeComprobante no es I,E o N, y un concepto incluye el campo descuento. Folio: 1. Serie: INV/2025/. El valor del atributo Descuento (2295.51) no coincide con la suma de los importes (790.947500 + 748.090000 + 756.465000 = 2295.50) ``` This occurs because when correcting the discount rounding we round the biggest discount amount so the amounts might not add up correctly anymore opw-4596741
Code cleanup and technical improvements
This change updates Odoo's web tour testing support to ignore a specific asset-loading failure when appropriate. It helps reduce unnecessary test interruptions from this known issue, improving reliability for internal validation without changing day-to-day user workflows.
Original PR description
In this commit, we skip AssetsLoadingError
Documentation and clarification updates
This pull request adds an individual Contributor License Agreement signature for the contributor Corbiezorq. It supports Odoo's legal contribution process and does not change product functionality or user workflows.
Original PR description
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 update records LABISO GmbH's corporate contributor license agreement and listed contributors. It helps Odoo maintain clear legal permission to include contributions from this company in the project.
Original PR description
This pull request includes an update to the `doc/cla/corporate/labiso.md` file. The change adds a new corporate contributor license agreement for LABISO GmbH, including the list of contributors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request records the contributor's signed CLA and includes early draft work for real estate and Telegram notification add-ons. For the business, the legal confirmation is the key actionable change, while the added modules appear to be preliminary and may need review before any product impact.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A contributor has added their individual Contributor License Agreement record. This supports Odoo's legal contribution process and helps ensure contributions can be accepted under the project's licensing requirements.
Original PR description
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
Miscellaneous changes
To reproduce: ============= - create a contact with customer location : Partners/Customer/test - enable 2 steps delivery on warehouse - create SO for the contact and confirm it - validate first step of delivery - check second step of delivery -> the destination location is Partners/Customer instead of Partners/Customer/test Problem: ======== Now that we are creating moves step by step we are not passing the destination location to the second move and using the one set on the rule.
Original PR description
To reproduce: ============= - create a contact with customer location : Partners/Customer/test - enable 2 steps delivery on warehouse - create SO for the contact and confirm it - validate first step of delivery - check second step of delivery -> the destination location is Partners/Customer instead of Partners/Customer/test Problem: ======== Now that we are creating moves step by step we are not passing the destination location to the second move and using the one set on the rule. Solution: ========= when creating second move and it's last step we set destination to final destination location. opw-4374075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199278
Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems. First, if there was an onchange on that field, the onchange was triggered multiple times with the same forget command, especially on a slow-ish network. Second, there could be a crash, but to reproduce it the timing had to be precise: backspace should have been pressed when a previous tag deletion was al
Original PR description
Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems. First, if…
Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems. First, if there was an onchange on that field, the onchange was triggered multiple times with the same forget command, especially on a slow-ish network. Second, there could be a crash, but to reproduce it the timing had to be precise: backspace should have been pressed when a previous tag deletion was already processed by the model (i.e. the tag is no longer in the list), but the DOM wasn't updated yet. This could be done more easily then it sounds, by quickly pressing backspace on a many2many_tags with a lot of tags. The related opw is about the second issue, as the first one isn't obversable functionally. However, testing the second one is really tricky, even impossible without going white-box. We thus wrote a test for the first issue only, as the fix for both is actually the same. opw-4596936 Forward-Port-Of: odoo/odoo#201233 Forward-Port-Of: odoo/odoo#201164
Before this commit, a traceback is occurred when the user would like to see the raw data of a specific project and the project stage feature is disabled. This commit adds a group on `duration_tracking` field definition to be sure this field will only be computed when the project stage feature is enabled. opw-3709542 Closes #197321 Forward-Port-Of: odoo/odoo#201313
Original PR description
Before this commit, a traceback is occurred when the user would like to see the raw data of a specific project and the project stage feature is disabled. This commit adds a group on `duration_tracking` field definition to be sure this field will only be computed when the project stage feature is enabled. opw-3709542 Closes #197321 Forward-Port-Of: odoo/odoo#201313
Live chat sessions are accessible to live chat managers so they should be able to join or invite anyone to said session. task-4637836 https://github.com/odoo/upgrade/pull/7372 Forward-Port-Of: odoo/odoo#201395 Forward-Port-Of: odoo/odoo#201321
Original PR description
Live chat sessions are accessible to live chat managers so they should be able to join or invite anyone to said session. task-4637836 https://github.com/odoo/upgrade/pull/7372 Forward-Port-Of: odoo/odoo#201395 Forward-Port-Of: odoo/odoo#201321
This fix aims to improve the user experience on mobile by removing useless tooltips on the chatter. Since the user usually does not have a keyboard on the mobile, we do not show the keybind tooltip when the screen is small task-4633869 Forward-Port-Of: odoo/odoo#201271 Forward-Port-Of: odoo/odoo#200961
Original PR description
This fix aims to improve the user experience on mobile by removing useless tooltips on the chatter. Since the user usually does not have a keyboard on the mobile, we do not show the keybind tooltip when the screen is small task-4633869 Forward-Port-Of: odoo/odoo#201271 Forward-Port-Of: odoo/odoo#200961
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 Forward-Port-Of: odoo/odoo#200244 Forward-Port-Of: odoo/odoo#198760
Original PR description
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 Forward-Port-Of: odoo/odoo#200244 Forward-Port-Of: odoo/odoo#198760
*: portal, website, web_editor Enhance user experience by resolving UI inconsistencies and ensuring readability and contrast between the dropdown active / hover states and their inner text. **Global** - Updated hover effects to use `body-tertiary-bg` instead of `gray-100`, aligning with Bootstrap 5.3's styling approach. - Added color-contrast function's variables to allow easier use in `bootstrap_overridden_frontend` **Dropdowns** - Adjusted active state colors to prevent conflicts
Original PR description
*: portal, website, web_editor Enhance user experience by resolving UI inconsistencies and ensuring readability and contrast between the dropdown active / hover states and their inner text.…
*: portal, website, web_editor Enhance user experience by resolving UI inconsistencies and ensuring readability and contrast between the dropdown active / hover states and their inner text. **Global** - Updated hover effects to use `body-tertiary-bg` instead of `gray-100`, aligning with Bootstrap 5.3's styling approach. - Added color-contrast function's variables to allow easier use in `bootstrap_overridden_frontend` **Dropdowns** - Adjusted active state colors to prevent conflicts between the primary active color and dropdown item text color. - Differentiate two active states: - Active menu entries (current page) ➡️ Primary color - Active feedback on click ➡️ color-contrast of background color - Updated the `o_extra_menu_items` dropdown to adapt the borders to the user theme settings, removing the hardcoded `gray-200` value. **Search & Misc** - Replaced `-webkit-search-cancel-button` with Bootstrap's `btn-close` design introducing a mixin for contextual color adjustments to match the input color. - Changed portal search input type from `text` to `search` ensuring proper styling and semantic. task-3969685 | Before | After | | --- | --- | |  |  | | |  | |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170922
Before this PR, a request was sent for each character typed inside the search of the invite to the channel panel. This PR introduces a debounce to avoid spamming the server with useless requests. Part of Task-4637517 Forward-Port-Of: odoo/odoo#201373
Original PR description
Before this PR, a request was sent for each character typed inside the search of the invite to the channel panel. This PR introduces a debounce to avoid spamming the server with useless requests. Part of Task-4637517 Forward-Port-Of: odoo/odoo#201373
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 Forward-Port-Of: odoo/odoo#201246 Forward-Port-Of: odoo/odoo#200033
Original PR description
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 Forward-Port-Of: odoo/odoo#201246 Forward-Port-Of: odoo/odoo#200033
Use case: When sending stock ewaybill with no taxes at that time government API is expecting the taxes values as `0`. Issue: When there is no tax applied we get an empty list due to which it doesn't set the default taxes to `0` Fix: We make sure if there no taxes then return a default taxes as `0` opw-4639009 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201118
Original PR description
Use case: When sending stock ewaybill with no taxes at that time government API is expecting the taxes values as `0`. Issue: When there is no tax applied we get an empty list due to which it doesn't set the default taxes to `0` Fix: We make sure if there no taxes then return a default taxes as `0` opw-4639009 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201118
Steps to reproduce the issue: 1. Activate the Odoo Mexican Localization Reports module 2. In a Mexican company, create a new Account with 1 as code 3. Go to Trial Balance and download COA SAT (XML) 5. In the General Settings with developer mode active, Download XSD files 6. Go to Trial Balance and download COA SAT (XML) again 7. You get a UserError with an unclear message Explanation: The Mexican Chart of Accounts have clear rules regarding `account.account.code`. The only way to v
Original PR description
Steps to reproduce the issue: 1. Activate the Odoo Mexican Localization Reports module 2. In a Mexican company, create a new Account with 1 as code 3. Go to Trial Balance and download COA SAT (XML)…
Steps to reproduce the issue: 1. Activate the Odoo Mexican Localization Reports module 2. In a Mexican company, create a new Account with 1 as code 3. Go to Trial Balance and download COA SAT (XML) 5. In the General Settings with developer mode active, Download XSD files 6. Go to Trial Balance and download COA SAT (XML) again 7. You get a UserError with an unclear message Explanation: The Mexican Chart of Accounts have clear rules regarding `account.account.code`. The only way to verify those accounts is through the XSD files check, but they are not automatically downloaded and the error received with those files downloaded is not user friendly. Fix reasoning: Instead of regulating the code when downloading the XML. We'll add warnings on the Chart of Accounts to notify the user when a code is incorrect. To make the report error clearer to the user, we added a RedirectWarning that displays the accounts with faulty codes before generating the xml. opw-4287338 Forward-Port-Of: odoo/enterprise#81111 Forward-Port-Of: odoo/enterprise#73943
The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO). Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place. This
Original PR description
The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO). Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place. This revision changes the flow by simply re-instanciating a new `Model` every time we change the target revision. Task-4506832 Forward-Port-Of: odoo/enterprise#80680 Forward-Port-Of: odoo/enterprise#77667
Before this commit a translated mail layout's header would be (e.g. in Dutch) 'Je signature'. After this commit, the model's description is translated (e.g. in Dutch) to 'Je Handtekening'. This replicates the same behavior as the _send_signature_access_mail() method. Impacted versions: 16.0, 17.0 and 18.0 Forward-Port-Of: odoo/enterprise#79575 Forward-Port-Of: odoo/enterprise#77948
Original PR description
Before this commit a translated mail layout's header would be (e.g. in Dutch) 'Je signature'. After this commit, the model's description is translated (e.g. in Dutch) to 'Je Handtekening'. This replicates the same behavior as the _send_signature_access_mail() method. Impacted versions: 16.0, 17.0 and 18.0 Forward-Port-Of: odoo/enterprise#79575 Forward-Port-Of: odoo/enterprise#77948
A potential access right issue appears in the case a simple HR user accessed the employee view without payroll rights since source-tax mutations are restricted to payroll users. opw-4607112 Forward-Port-Of: odoo/enterprise#81200
Original PR description
A potential access right issue appears in the case a simple HR user accessed the employee view without payroll rights since source-tax mutations are restricted to payroll users. opw-4607112 Forward-Port-Of: odoo/enterprise#81200