Daily updates from Odoo
Tuesday, March 26, 2024
45 changes · 17.0
Enhancements to existing features
This update adjusts the private car reimbursement rates in the Belgian payroll system to comply with 2024 regulations. The changes ensure that employee car allowances are calculated correctly according to the latest Belgian tax and labor law requirements, affecting how payslips are generated for employees using private vehicles for business purposes.
Original PR description
https://www2.partena-professional.be/LegalPortal/servlet/servlet.FileDownload?file=00P3X00002H45q2UAB
This update enhances the UAE payroll module by adding the necessary salary calculation inputs and rules required for accurate payroll processing in the United Arab Emirates. The changes ensure that the payroll system now has complete support for UAE-specific salary calculations and compliance requirements.
Original PR description
Change adds inputs and rules used for calculating salary in UAE. task-3634461 Forward-Port-Of: odoo/enterprise#53553
This update adds a loading spinner and disables the sign button while an order signature request is being processed. This prevents users from accidentally clicking the button multiple times, which was causing errors and confusion. The improvement makes the signing process clearer and more reliable for customers.
Original PR description
opw-3709064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The portal icon size is now restricted to a standard 64x64 pixel dimension. This ensures consistency across the platform and eliminates the need for manual icon resizing, making the portal experience more uniform and reducing administrative overhead.
Original PR description
-Sometime we may receive a portal icon that can be a little big or a little small in size, then in order to make it perfectly fit to client portal we will have to edit the icon to 64x64, invoice, sale, project app all have the same 64x64 portal icon. -Therefore we should restrict it to 64x64 to ensure no further action is needed 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 stock accounting module has been improved to make it easier to customize how inventory ownership is tracked. This refactoring simplifies the code structure, allowing future enhancements for valuing inventory based on specific ownership without requiring extensive code modifications. This change prepares the system for more flexible inventory management capabilities.
Original PR description
Refactored the restrict_parnter_id check in the stock_account module to make it more flexible for future updates.The The purpose of this refactoring is to prepare for a custom module that will value inventory based on specific ownership. Related: https://github.com/OCA/stock-logistics-workflow/pull/1548 @qrtl QT4334 Forward-Port-Of: odoo/odoo#158343
Resolved issues and error corrections
This fix prevents the system from crashing when approval rules reference models that no longer exist (such as deleted, renamed, or custom models). The system now gracefully skips these non-existent models instead of throwing an error during startup, ensuring smoother upgrades and system stability.
Original PR description
If a `studio.approval.rule` refers to a non-existing model (e.g. the model was removed, or renamed, or it's a custom model that is not present during an upgrade), then while attempting to patch the…
If a `studio.approval.rule` refers to a non-existing model (e.g. the model was removed, or renamed, or it's a custom model that is not present during an upgrade), then while attempting to patch the rule's method the registry will [return](https://github.com/odoo/enterprise/blob/961f67d776a8ec1d9293ed599f284807930496d5/web_studio/models/studio_approval.py#L200) a `None` model, which then causes an AttributeError.
We add a check for the Model's existence, so that any None models are skipped. This follows the approach in [base_automation](https://github.com/odoo/odoo/blob/d11ece23e97189f38040254917a3517e21386e47/addons/base_automation/models/base_automation.py#L847-L857), which was the technical inspiration for the [commit](https://github.com/odoo/enterprise/commit/3db107ae481a8da85aa356c729bae5fc246e655b) that implemented the approval rule logic.
Ticket: [3754939](https://www.odoo.com/web#id=3754939&cids=1&menu_id=4720&action=333&active_id=70&model=project.task&view_type=form), [3777251](https://www.odoo.com/web#id=3754939&cids=1&menu_id=4720&action=333&active_id=70&model=project.task&view_type=form)
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1302, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 606, in load_modules
model._register_hook()
File "/home/odoo/src/enterprise/17.0/web_studio/models/studio_approval.py", line 203, in _register_hook
_patch(Model, approval.method, approval_method)
File "/home/odoo/src/enterprise/17.0/web_studio/models/studio_approval.py", line 132, in _patch
ModelClass = model.env.registry[model._name]
AttributeError: 'NoneType' object has no attribute 'env'
```This update fixes the Send & Print feature in the electronic invoicing systems for Brazil and Mexico. The implementation has been cleaned up to ensure the feature works correctly when users want to send and print documents simultaneously.
Original PR description
Clean the implementation.
This fix corrects an incorrect account mapping in the Swiss payroll module where salary advance transactions were being linked to the wrong account code. The account code 5003 (Salary Advance) was incorrectly pointing to account 5004 (Holidays payment after departure). This correction ensures that salary advance payments are now recorded in the proper account, improving financial accuracy and reporting.
Original PR description
The account code 5003 is used for the salary advance account but in hr.salary.rule the account linked to it is 5004 Holidays payment after departure. see [here](https://github.com/odoo/enterprise/blob/17.0/l10n_ch_hr_payroll_account/models/account_chart_template.py#L15). But that should be Salary Advance. Although I am not very sure about this, I saw the code and it seems to be suspicious. Before fix:-  After fix:- 
This update corrects visibility rules for fields in Mexico's Delivery Guide (Carta Porte) version 3.0. Specific fields now display only when appropriate: material type shows for external trade, tax registration appears for non-Mexican customers, and customs fields display regardless of shipment status. These fixes ensure the delivery guide generates correctly for Mexican compliance requirements.
Original PR description
There were a few issues with the new version 3.0 of the Delivery Guide (Carta Porte): - TipoMateria should only be visible when it's an external trade. - NumRegIdTrib should only be visible when the customer's country is not MX. - Visibility of customs related fields (that were added in version 3.0) should not depend on the state of the picking. task-3755473 Forward-Port-Of: odoo/enterprise#57822
This fix resolves an error in accounting reports that occurred when creating temporary tables with non-standard database field types (like HTML fields). The system now properly converts Odoo field types to compatible database types instead of attempting invalid conversions, preventing report generation failures.
Original PR description
The issue: In the accounting report, in the process of creating the temporary table analytic_temp_account_move_line, that should match the account_move_line schema, we opt for NULL values, casting them to match the column type to match account_move_line table columns type. Now, if you have a field of any type that is not standard in PSQL (like HTML) in the account.move.line model, the query will try to cast a NULL to this type (which is HTML in this case), therefore will throw a traceback The fix: Instead of casting NULL to Odoo type, which is in some cases not a valid type for PSQL (Like HTML type), this PR aims to cast any of these fields to the appropriate PSQL type opw-3782724 Forward-Port-Of: odoo/enterprise#58617
Chilean customers using the ecommerce checkout were unable to complete purchases when selecting the 'Ticket' payment option with automatic invoicing enabled. The system was incorrectly requiring them to complete an incomplete anonymous billing address they didn't have permission to edit. This fix ensures the anonymous address is treated as complete, allowing the checkout flow to proceed smoothly.
Original PR description
Chilean ecommerce checkout flow was consistently breaking when automatic invoice was enabled (Sale settings), for customers choosing the 'Ticket' option (not the 'Invoice' one). Indeed, choosing the 'Ticket' options sets a generic 'Anonymous' customer as billing address, but since this address is incomplete, the customer is redirected to the page to complete it, even though they don't have the rights to update that address since it's not theirs. This commit makes sure to consider this 'anonymous' billing address as being always complete, even if some fields are empty. opw-3792844
This fix removes a duplicate variable that was accidentally introduced in the Dutch localization tax reporting module. The change cleans up test code to ensure the module functions correctly without redundant data.
Original PR description
During this commit: https://github.com/odoo/enterprise/commit/02252c3af7637835e34d0c19a609e1aa05b5a653#diff-fcb2837955e2fcf5fb3885f86c0f12f8facd7cd24d73e1f151957c33db381f9e A duplicate variable was introduced. This commit will remove that. no task-id
This fix corrects an incorrect visibility setting for the phone field in the WhatsApp message composer. The issue occurred during a code merge and has been resolved to ensure the phone field displays properly when composing WhatsApp messages.
Original PR description
Wrong conflict resolution when forward porting odoo/enterprise@7ff6e2b04110d1e3c046388927409ec46d39800e Task-3778173
This fix resolves an error that occurred in the document signing feature when users left the validity field empty. Previously, the system would crash with a technical error when trying to validate the date. Now the system properly handles empty validity fields, allowing users to proceed without interruption.
Original PR description
Before this commit on the sign request when leaving the validity field empty and clicking on a different place, the following error occurs: """ .... if self.validity < fields.Date.today(): TypeError: '<' not supported between instances of 'bool' and 'datetime.date' """ This commit aims to fix this issue by adding an additional condition before comparing the validity. Task: 3750526 Forward-Port-Of: odoo/enterprise#57196
This fix corrects a bug where the timer filter was displaying incorrect records when a task and ticket shared the same ID. Previously, when filtering by "User Timer is set," tickets without an active timer would incorrectly appear in the results. The fix ensures the search properly distinguishes between different record types by including the model type in the filter condition.
Original PR description
When a task and a ticket share the same ID, the _search_user_timer_id method will not work and provide the wrong result when using User Timer as the filter. Steps to reproduce: Having a task and a ticket with the same ID. Start the timer in the task. Go to the ticket and filter by "User Timer is set" There will be a ticket without a timer running but still showing in the search result. Cause The search method did not take into consideration of model. Solution Add model as a condition when searching timer records
This fix resolves errors that occurred in the sales subscription dashboard when it was used without demo data. The dashboard formulas have been updated to gracefully handle missing data by displaying empty cells instead of errors, ensuring a better user experience.
Original PR description
## Description: Before this fix, errors occurred in certain sections of the sales subscription dashboard when attempting to load it without demo data. This PR resolves the problem by incorporating IFERROR into the formulas to leave them empty in case of errors. Task ID: [3754211](https://www.odoo.com/web#id=3754211&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#58155
This fix prevents the system from sending reminder notifications for signature requests that have been archived. Previously, archived requests were incorrectly triggering reminders through automated processes, which could confuse users. Now the system properly skips archived requests when sending reminders.
Original PR description
Before this commit, some archived sign.requests were triggering reminders by the cron when they shouldn't, because they weren't active anymore. After this commit, archived sign.requests no longer trigger reminders by the cron, they are skipped in the SQL query. task-3806013 Forward-Port-Of: odoo/enterprise#58649
This update prevents users from reverting tax closing entries to draft status if newer closing entries have already been posted. This ensures closing entries are reset in proper chronological order, which is essential for accurate carryover calculations and financial record integrity. The change also fixes inconsistent behavior in the Tax Report's Closing Entry button.
Original PR description
Prevents the user to reset to draft a tax closing entry if subsequent closing entries are already posted. This way, the user is forced to reset to draft progressively back in time the closing entries. Accounting wise, this case should not happen. It is by the way prevented by the irreversible_lock_date module (which can be however uninstalled). This mechanism solves an issue with carryovers that need to be progressively recomputed when resetting to draft a closing entry. Another issue has also been fixed. The 'Closing Entry' button in the Tax Report has inconsistent behavior when the closing entry is already posted and then reset to draft. This issue was solved in 17 in this commit: https://github.com/odoo/enterprise/commit/49f664db942f3b7f5d343ac7a42608839b5595bf. It is backported in order to make the draft closing entry flow as smooth as possible. task-3520338 Forward-Port-Of: odoo/enterprise#58869 Forward-Port-Of: odoo/enterprise#52875
This fix prevents users from changing whether a product is set up for recurring invoicing once it has already been included in a confirmed sales order. Previously, while a warning was shown, the system would still allow the change, which could cause confusion. Now the field is locked to maintain consistency with existing customer orders.
Original PR description
Issue: ------ It is possible to change the recurrence of a product if it has already been sold (correct behaviour). The customer receives a warning, but the `recurring_invoice` field is still set to `True`, whereas it may have been set to `False` before the operation. Solution: --------- Prevent the `recurring_invoice` field from being changed if a confirmed sale order line contains this product, to avoid confusion. opw-3457160
This update reorganizes calendar styling code to fix layout problems that occurred when using modules like Planning or HR Payroll without the Calendar module installed. The change moves essential calendar styles to the core Web module and fixes the display of hatched events in Planning's Day and Week views, ensuring consistent appearance across all related features.
Original PR description
### Move common scss into web Prior to this PR, some of the main styles related to event elements in calendars were set in the `calendar` module. This created layout issues when we installed…
### Move common scss into web Prior to this PR, some of the main styles related to event elements in calendars were set in the `calendar` module. This created layout issues when we installed independent modules without installing `calendar` (eg. `planning` or `hr_payroll`). To fix that, this PR moves the necessary styles into `web` and manages duplicated styles in order to remove them. ### Adjust hatched events for planning Prior to this commit, the "hatched" event style in Planning wasn't displayed in Day and Week views. This commit adjusts the css selector to fix this issue. --- task-3617329 Part of task-3575827 --- | Before | After | |--------|--------| |  |  | |  |  | | Before | After | |--------|--------| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes the Send & Print feature across multiple invoice and document management modules including UBL/CII, Peppol, Spanish and Italian electronic invoicing, and Snailmail integration. The fix cleans up the implementation and ensures all modules properly support the Send & Print functionality for document delivery.
Original PR description
…ail_account: fix Send & Print only Clean the implementation + missing peppol, ubl and snailmail.
This fix corrects an issue where time off requests were incorrectly spanning 2 days instead of 1 when users were in timezones ahead of UTC (like UTC+08:00). The problem occurred because date calculations weren't properly accounting for the user's local timezone before converting to dates. Now the system correctly applies timezone conversion before processing request dates, ensuring users see accurate single-day requests.
Original PR description
Steps to reproduce: ------------------- - be in a UTC+08:00 (or more) timezone - go to Time Off dashboard - click on a day (to request a leave) Issue: ------ Default request dates are on 2 days instead of 1. Cause: ------ Default request dates are determined during an onchange. The datetimes (`default_date_from/to`) are set in the context in UTC calculated in relation to the client's timezone. Consequently, these datetimes can be set over several days. In the backend, we will use these datetimes and take only the day (because the `request_date_from/to` fields are of type date). Solution: --------- Put the values back into the client's timezone before they are truncated. opw-3789265
This update fixes the visual appearance of the import tool when using dark mode. The background colors were too dark and inconsistent with other parts of the system, making the interface less appealing. The changes adjust the background colors to look better in both light and dark modes while maintaining consistency across the application.
Original PR description
This commit adapts `base_import`'s background that was too dark compared to other modules. This was caused by the use of a `bg-white` class that is not very "dark-mode friendly" as it will display as…
This commit adapts `base_import`'s background that was too dark compared to other modules. This was caused by the use of a `bg-white` class that is not very "dark-mode friendly" as it will display as a pure black, which is not visually appealing and not wanted. This commit also adapts the background color of the sidebar to make it more consistent with other modules. We also add a `bg-view` class to the table, so it stands out more in light mode and stays the same in dark mode. task-3814508 | Before | After | |--------|--------| | <img width="1728" alt="Screenshot 2024-03-22 at 08 32 26" src="https://github.com/odoo/odoo/assets/110090660/85c0d0bf-19af-4a19-aa1b-cf990a6147d8"> | <img width="1728" alt="Screenshot 2024-03-22 at 08 34 08" src="https://github.com/odoo/odoo/assets/110090660/dfe7198a-c011-4ead-bf6f-cfba50db93a9"> | | <img width="1726" alt="Screenshot 2024-03-22 at 08 32 42" src="https://github.com/odoo/odoo/assets/110090660/ed5914c2-bf1c-44ee-baa6-58fb5f537d9a"> | <img width="1725" alt="Screenshot 2024-03-22 at 08 34 19" src="https://github.com/odoo/odoo/assets/110090660/fb80a723-d1d0-4d44-aded-d603385cce70"> | | <img width="1714" alt="Screenshot 2024-03-22 at 08 59 52" src="https://github.com/odoo/odoo/assets/110090660/98c543a0-05dd-4b71-b5bf-9d702f513fb4"> | <img width="1715" alt="Screenshot 2024-03-22 at 08 57 41" src="https://github.com/odoo/odoo/assets/110090660/4005b050-4a2a-4137-b6c0-47ecbdbe89a7"> | | <img width="1726" alt="Screenshot 2024-03-22 at 08 33 08" src="https://github.com/odoo/odoo/assets/110090660/fde063f8-48f5-4ae2-a5c1-b1973d94f0b3"> | <img width="1728" alt="Screenshot 2024-03-22 at 08 33 59" src="https://github.com/odoo/odoo/assets/110090660/b5875104-7d6f-4a36-8303-0cf7c14c113d"> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158019
This fix resolves an issue that prevented users from selecting Algeria as their fiscal localization package after installing the Algerian localization module. The problem was caused by duplicate tax names in the configuration data, which violated a uniqueness requirement. By making these tax names unique, companies can now successfully set up their Algerian fiscal localization.
Original PR description
**Current behavior:** Trying to select the Algerian fiscal localization for a company after installing the respective module is impossible. **Expected behavior:** The localization package should be installable after the module has been installed. **Steps to reproduce:** 1. Install `l10n_dz` and create a new company without any fiscal localization 2. In the fresh company, select `Algeria` as the fiscal localization package, observe the error **Cause of the issue:** Two tax names in the module's tax data file have the same values for a field that should be unique. **Fix:** Change the values in the identical fields. opw-3787096 Forward-Port-Of: odoo/odoo#157198
This update fixes how the text editor handles empty heading elements when users press backspace. Previously, empty headings (H4-H6) wouldn't be properly removed, and headings with text would incorrectly convert to paragraphs when backspacing at the start. Now, empty headings are correctly deleted on backspace, providing a more intuitive editing experience.
Original PR description
Before this PR:
1. When an empty heading from H4 to H6 is the only element in the editable
area, the backspace key doesn't turn it into paragraphs.
2. When the cursor is at the start of a heading element with text content, and the
user hits the backspace key, the element gets converted into a paragraph.
After this PR:
All heading elements are removed on backspace if they're empty.
task-3456815
Forward-Port-Of: odoo/odoo#132778This fix resolves an issue where copying a button would also copy its parent container, resulting in unwanted extra space and background color when pasting. Now users can copy and paste buttons cleanly without the parent container being included.
Original PR description
**Current behavior before PR:** When attempting to copy a button that is a direct child of a div tag, the div was unintentionally copied along with the button, leading to additional space upon pasting, along with the background color. **Desired behavior after PR is merged:** Now, only the button will be copied and pasted. task-3764652 Forward-Port-Of: odoo/odoo#155212
This update fixes icons that were displaying incorrectly when using right-to-left languages like Arabic. Previously, icons in image galleries, carousels, and other interface elements weren't properly flipped for RTL layouts. The fix ensures all Odoo icons now display correctly regardless of language direction, improving the user experience for RTL language users.
Original PR description
Prior to this PR, `oi` icons were not adapted when RTL was defined in frontend. This is because RTL adaptations were defined in the backend bundle. This PR moves the RTL adaptations to be used wherever `oi` icons can be defined. task-3794966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157214
Fixed an issue where job locations were incorrectly displaying the company name instead of the city on the website's job application page. The fix ensures that when a job has a location set, the correct city name appears under the 'Location' label, and displays "Remote" when no location is specified. This improves the accuracy of job listings for candidates browsing open positions.
Original PR description
**Current behavior:** In the jobs/ directory on the website, if a position has a location set in its configuration, the 'Location' label will display the name of the company rather than the city where it is located. **Expected behavior:** The city will be displayed under the 'Location' label. **Steps to reproduce:** 1. In the Recruitment app, give a job a location value 2. On the website, go to the jobs/ directory and navigate to the position from step 1 3. Click 'Apply Now!' and look at the location label on the right side of the page **Cause of the issue:** This field was missing the "contact" widget type in its t-options. **Fix:** Add the widget type and additionally display "Remote" for the location when there is no location set. opw-3761348 Forward-Port-Of: odoo/odoo#159074 Forward-Port-Of: odoo/odoo#156239
This fix corrects an issue where imported XML bills were incorrectly using purchase order prices instead of the prices specified in the XML file. When a vendor bill in XML format is matched to a purchase order, the bill now correctly preserves the pricing from the XML document rather than overwriting it with the PO price.
Original PR description
**Steps to reproduce:** - Install Accounting and Purchase - Go to Purchase and create a PO: * Vendor: Vendor X * Product: Product X * Unit Price: 50.00 - Create an electronic bill in XML format with: * a reference to PO name * the same partner than the PO * the same line than the PO, except for the price - Go to "Accounting / Vendors / Bills" - Upload the XML bill **Issue:** The bill is generated and linked to the PO, but the price and subtotal on the bill line is the one coming from the PO instead of the one coming from the XML. Values coming from an imported XML should not be overridden by values found in matching PO. **Cause:** "timeout" parameter is wrongly passed as "prefer_purchase_line" parameter in a call to "_find_and_set_purchase_orders" method. opw-3707731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158015
Users were unable to access their own attachments when uploading files in course reviews, resulting in 404 errors. This fix ensures that access tokens are properly generated for user attachments, allowing them to view files they've uploaded regardless of their user status.
Original PR description
Bug === 1. login as demo user 2. add a review on a course and upload an attachment 3. click on the attachment link => You get a 404 error For some reason, we do not return the access token if the user is internal. The generation is not a heavy process, and might be needed depending on the <ir.rule>. Task-3693072 Forward-Port-Of: odoo/odoo#158922 Forward-Port-Of: odoo/odoo#156659
This fix resolves an issue where buttons marked to close dialogs were not working properly when placed in the footer of related record list windows. The system now correctly identifies and uses the dialog closing function, ensuring these buttons work as expected when users interact with related records.
Original PR description
Before this commit, if a button had the attribute special="close" on the footer of an x2many dialog, the dialog was not closed. This occurs because the view button hook searches the dialog close functions put in the environment by the dialog component, and in this case is another component that initialize the hook, and the function is not found. Now, the view button hook will use the dialog close function put in the environment by the dialog service.
This fix resolves an issue where Odoo's auto-reload feature was not working on Windows 11 when using the latest watchdog library. The problem occurred because the watchdog library changed how it handles file event properties, causing the auto-reload to fail silently. This update ensures developers can now properly use the --dev=reload mode to automatically restart Odoo whenever they modify Python files, improving development productivity.
Original PR description
Description of the issue/feature this PR addresses: the autoreload does not work after modified python file(s), dev reload mode has been eanbled when start odoo on windows 11. i found the reason is: when a file modified, watchdog event has the property 'dest_path' but content is empty Current behavior before PR: odoo started with --dev=reload, the log show watchdog is watching addon folders but when i modified a python file, the odoo app did not restart, the log has no output. 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#157829
Fixed an issue where mobile users couldn't save edited log notes because the keyboard shortcut (CTRL+ENTER) wasn't available and there was no save button. A new save button with a paper plane icon has been added to the message composer, making it easy for mobile users to save their edits just like they would send a new message.
Original PR description
Example of steps: - Open any record with a chatter - Log a note - Edit it - Try to save Actually it is impossible to save it, because we can not perform a CTRL+ENTER in mobile and there is no button This commit adds a button to save editing, using `fa-paper-plane` icon similarly to send button. opw-3784145
This fix corrects a bug where products that had expense settings enabled, then disabled, would still create analytic accounts when used in sales quotations. The issue occurred because the expense policy setting was retained even after disabling the "Can be Expensed" option. Now the system properly resets the expense policy when the expense feature is disabled, ensuring consistent behavior across all product configurations.
Original PR description
Currently, an analytic account is created when confirming a quotation for a product created as follow: 1. Enable `Can be Expensed` 2. Select `At cost` for Re-invoice expenses 3. Disable `Can be…
Currently, an analytic account is created when confirming a quotation for a product created as follow:
1. Enable `Can be Expensed`
2. Select `At cost` for Re-invoice expenses
3. Disable `Can be expensed`
Steps to reproduce:
-------------------
* Install **sale_management** and **hr_expense**
* Go to **Settings**
* Under `Customer Invoices`, enable `Intrastat` -> Save
* Under `Analytics`, enable `Analytic Accounting`
* Go to **Sales**
* Create 3 products
* Product 1: Default
* Product 2:
* Enable `Can be Expensed`
* Select `At cost` for Re-invoice expenses
* Product 3:
* Enable `Can be Expensed`
* Select `At cost` for Re-invoice expenses
* Disable `Can be expensed`
* For each product, repeat:
* Create a quotation, select a customer
* Add the product
* Confirm
* Select tab `Other Info`
* Check the analytic account
**Observations:**
* Product 1: No analytic account created
* Product 2: Analytic account created
* Product 3: Analytic account created
Why the fix:
------------
The creation of the analytic account depends on the value of `expense_policy`. When the value is `no`, no analytic account is created. Whereas when the value is `cost`, an analytic account is created.
https://github.com/odoo/odoo/blob/57ad9c05014ca0219d7892c1ff8a2e949fab3c49/addons/sale/models/sale_order.py#L853-L856
In this workflow, `expense_policy` is visible only when `Can be expensed` is enabled. If you select an `expense_policy` then disable `Can be expensed`, the value for the `expense_policy` stays as previously selected.
https://github.com/odoo/odoo/blob/3e320ffe0ff4d1c6bb7d0314f36dd13ad1cf23f4/addons/sale_expense/models/product_template.py#L33-L41
opw-3706305
Forward-Port-Of: odoo/odoo#154153This update corrects where permission groups are defined for analytic account fields, moving them from the account module to the analytic module where they belong. Additionally, the balance information is now visible to all users regardless of their read-only permissions, since balance is independent of credit/debit access controls.
Original PR description
The fields in analytic have a group which is defined in account. It's okay to show them in analytic module only (for example from project) for people having the rights to see analytic. We also show balance now, even if you don't have the group 'readonly', because it's an information that is independent of credit/debit notion. Linked to runbot error 59222 (will need to remove the group in the test) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158994 Forward-Port-Of: odoo/odoo#156349
A Norwegian translation error was preventing sales confirmation emails from being sent properly. The issue occurred because part of the email template code was incorrectly translated, causing the template to fail rendering. This fix corrects the translation to ensure customers receive their order confirmations.
Original PR description
Issue ----- The sale confirmation mail template is not rendered because a part of code is translated. Note: there's currently no Norwegian translation on Transifex for this version opw-3809578 Forward-Port-Of: odoo/odoo#158770
A test in the Purchase MRP module was using incorrect field references that could cause validation issues. This fix corrects the test to use the proper field names, ensuring the test accurately validates the system's behavior when processing purchase orders with backorders.
Original PR description
this commit https://github.com/odoo/odoo/pull/158788/commits/07e2fca9e39e9c32182f10bae6ba814a4241b6bf uses `qty_done` instead of `quantity` in test `test_valuation_with_backorder`
This fix corrects how loyalty program discounts are calculated when taxes are applied to products. Previously, the system was incorrectly calculating discount amounts without properly accounting for included taxes, resulting in discounts that were larger than intended. Now the discount calculation properly adjusts for tax-inclusive pricing to ensure customers receive the exact discount value they earned through loyalty points.
Original PR description
Create a Loyalty program: - Program Type: Loyalty Cards - Rules: 0.01 per $ spent - Reward: 1.00 per point on cheapest product Make a SO with total 339 Loyalty Card will get 3.39 points Make a SO with line having - Unit Price 140 - Tax 15% - Total will be 161 Hit Promotions Issue: The system will add a discount line with unit price 5.0. With 15% taxes applied the total discount will be 5.75 While it should be 5 Order 1, Total with tax 339 => 3.39 loyalty points Order 2, Total with tax 161 => 1.41 loyalty points from current order \+ 3.39 from past order = 5.00 total loyalty points When applying the discount on Order 2 the system converts 5 points to 5$, but considering 15% tax included, the price unit of the discount line should be 4.35 opw-3642795 Forward-Port-Of: odoo/odoo#157125
A previous fix for calculating shipping volume and weight was causing compatibility issues with custom extensions. This update restores the original method structure while maintaining the weight and volume calculation fix by using an alternative technical approach. This ensures existing customizations continue to work without disruption.
Original PR description
36e6728b2cac87c7cd922001be0222688ad52abb fixed an issue where the volume and weight were incorrectly computed for carriers based on rules. But it was done by changing the method api, which seems to break some custom modules using/extending the modified methods. This commit reverts the API change, conveying the needed information through the context for now (the api change will be done in master only). opw-3826165 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159181 Forward-Port-Of: odoo/odoo#159091
This fix removes an unnecessary filter that was significantly slowing down the task view in sales projects. The filter was redundant and caused the system to perform unnecessary searches, resulting in a 400x performance improvement (from 15 seconds down to 39 milliseconds). Users will now see task lists load much faster when viewing tasks associated with sales orders.
Original PR description
Since revision 81b5ef93a773b94a4e3770632469c692b0ff57fa, adding by default the filter `sale_order_id` which does: ```xml <field name="sale_order_id" string="Sale Order" filter_domain="['|',…
Since revision 81b5ef93a773b94a4e3770632469c692b0ff57fa, adding by default the filter `sale_order_id`
which does:
```xml
<field name="sale_order_id" string="Sale Order"
filter_domain="['|', ('sale_order_id', 'ilike', self), ('sale_line_id', 'ilike', self)]"
/>
```
becomes useless, because the final domain, with that `[('id', 'in', self.tasks_ids.ids)]` becomes:
```py
[
"&",
"&",
"&",
[
"project_id",
"!=",
false
],
[
"display_in_project",
"=",
true
],
[
"id",
"in",
[
3341211,
3526685,
3692221
]
],
"|",
[
"sale_order_id",
"ilike",
"SO2023/123456"
],
[
"sale_line_id",
"ilike",
"SO2023/123456"
]
]
```
which makes an "AND" connection between the task ids domain leaf and the sale order name ilike leaves, and all these task ids will come from these SO names, making the AND useless.
In addition to be useless, it downgrades the performance. On Odoo.com,
- with the filter `sale_order_id`: 15473 ms
- without the filter `sale_order_id`: 39ms
On the below screenshot:
The first request is with the filter `sale_order_id`
The second request is without the filter `sale_order_id`
opw-3752003
Forward-Port-Of: odoo/odoo#159115
Forward-Port-Of: odoo/odoo#158898This fix resolves an issue where QR codes printed on point of sale receipts were too small to scan on iOS devices. The QR code size has been adjusted to ensure it displays at a readable size when printed from iOS, improving the customer experience and receipt functionality.
Original PR description
Current behavior: When printing a receipt with a QR code on an iOS device, the QR code was too small and couldn't be scanned Steps to reproduce: - Setup an ePos printer for the PoS - Activate QRCode on receipt option - Start a PoS session on an iOS device - Add some product to the order and validate it - On the receipt screen click on the print button - Try to scan the QR Code on the ticket (it's probably too small) Note: If you don't have an iOS device you can use browserstack and use ngrok to expose your local server to the internet and connect to it on browserstack. You can do the same process to expose the printer so that you will be able to print from browserstack. opw-3788988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157423
This update removes a broken email sending method in the Partner module that has been non-functional since version 14.5. The underlying email functionality it relied on was removed years ago, but this method was accidentally left behind. Removing it prevents confusion and potential errors from attempting to use this obsolete feature.
Original PR description
The underlying `odoo.tools.email_send` was removed in 82de620424e22f9ca7cb9768db638c3a2b4f9318 (merged in 14.5) but this callsite was missed, this method has been broken ever since. Forward-Port-Of: odoo/odoo#159113
Estonia's default tax rate increased from 20% to 22% in 2024, and while the tax report was updated to reflect this change, the calculation formula was still using the old 20% rate. This fix corrects the tax computation formula to use the new 22% rate, ensuring accurate tax reporting for Estonian businesses.
Original PR description
In the beginning of 2024, the default tax of 20% in Estonia was changed by 22% (with the 20% still supported as a legacy) [1]. With that change, the tax report was also updated so the line previously containing the taxable amount at 20% now contains the taxable amount at 22%. However, the formula computing the tax amount itself was not updated to reflect this change and was still computing the tax by multiplying the taxable amount by 0.2. This fix corrects the tax computation in the report. [1] ec25405367eaeca6bdd1f54e2a09fe6b93b8a4b6 [opw-3815147](https://www.odoo.com/web#id=3815147&cids=1&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159154
When creating a new invoice, the browser tab title was showing confusing technical information (NewId_0x7f545c9d6980) alongside the invoice name. This fix removes that unnecessary technical identifier so users see a clean, professional tab title like "Draft Invoice" instead.
Original PR description
Steps to reproduce ================== - Create a new Invoice => The tab title is `Odoo - Draft Invoice (* NewId_0x7f545c9d6980)` Cause of the issue ================== In 17, the display_name is computed for the tab title https://github.com/odoo/odoo/blob/82fd8e702588d2cc5bdad474ed21188257cc7397/addons/web/static/src/views/form/form_controller.js#L342 opw-3794671
This fix addresses a flaky test in the scheduled jobs system that was producing inconsistent results. The issue occurred because data was being flushed at the wrong time, causing conflicting settings to override each other. By reordering when the data flush happens, the test now runs reliably every time.