Daily updates from Odoo
Navigate
Branch
Friday, May 16, 2025
51 changes
20 changes
Enhancements to existing features
Planning and project views now use a standard date range display instead of separate start and end date fields with a manual arrow. This simplifies the interface setup and helps keep date ranges more consistent for users.
Original PR description
This commit replaces manually constructed daterange fields (using two datetime fields and an arrow) in some XML views with actual daterange fields to simplify view definitions and take advantage of changes made in https://github.com/odoo/odoo/pull/209493. task-4788200
Bank reconciliation now lets users quickly apply the full amount when working from a partial amount, reducing manual entry and speeding up matching. The update also cleans up related editing behavior and improves form alignment for a smoother accounting workflow.
Original PR description
This commit will add the possibility to quickly apply a full amount when you have a partial amount. Also removing part of the edit line function that is not needed anymore since we added the amount currency in the view, the record_data parameter has now always the amount_currency in it. And doing some formatting because the alignment was wrong in the form view. task-4749342
Portal users linked to the same company can now view and manage subscriptions for their organization, even when another colleague is listed as the customer. This makes it easier for company teams to collaborate on subscription renewals, updates, and follow-up actions without needing access through a single contact.
Original PR description
### Purpose Improve the portal experience by making subscriptions visible to all contacts of a company, regardless of which contact is set as the subscription customer. ### Current Behavior Only the specific contact set as the customer on a subscription can access it from the portal. Other contacts from the same company are unable to view or act on that subscription. ### New Behavior All portal users linked to a company can now access and manage subscriptions associated with their organization, even if they are not the direct customer. task-4750267
The helpdesk timesheet dashboard now replaces broad 'Last X Days' filters with clearer quarter/month and year selectors. This makes it easier for users to review timesheet data by standard reporting periods and compare results more consistently.
Original PR description
Improve the filtering options in dashboard of timesheet by removing the generic 'Last X Days' filters and replacing with 'Quarter/Month' and 'Year' selectors. task-4380906
Resolved issues and error corrections
The planning interface now keeps the planned date range with allocated hours field at a consistent width. This prevents visual inconsistencies and makes scheduling information easier to read for users.
Original PR description
This commit takes advantage of changes made in https://github.com/odoo/odoo/pull/209075 to fix the same issue for the PlannedDateRangeWithAllocatedHours field as well. task-4751837
Features or functions removed from Odoo
Unused backend methods were removed from the Sign and Sales Subscription areas. This cleanup reduces maintenance overhead without changing expected user-facing behavior.
Original PR description
This commit removes the following unused methods: **Sign module** : - `open_log`: no longer used after this PR : https://github.com/odoo/enterprise/pull/38571/files - `open_template`: no longer used after this PR : https://github.com/odoo/enterprise/pull/75291/files - Removed `_get_font`, `_get_normal_font_size`, `_get_page_size`, and `_get_preview_values` from the sign.template model because they are already defined and used in the sign.document model after this PR :https://github.com/odoo/enterprise/pull/81766/files **Sale_subscription module**: - `_get_subscription_qty_to_invoice`: no longer used after this PR : https://github.com/odoo/enterprise/pull/75150/files task:4783798
Miscellaneous changes
Forgotten in c632b843 / task 4491333. Task-4703626 Forward-Port-Of: odoo/enterprise#82907
Original PR description
Forgotten in c632b843 / task 4491333. Task-4703626 Forward-Port-Of: odoo/enterprise#82907
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 Forward-Port-Of: odoo/enterprise#84071 Forward-Port-Of: odoo/enterprise#82980
Original PR description
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 Forward-Port-Of: odoo/enterprise#84071 Forward-Port-Of: odoo/enterprise#82980
With the removal of custom tax components in the corresponding community commit, views need to be updated to use the standard display_name and markdown formats now available. No Task Forward-Port-Of: odoo/enterprise#85172
Original PR description
With the removal of custom tax components in the corresponding community commit, views need to be updated to use the standard display_name and markdown formats now available. No Task Forward-Port-Of: odoo/enterprise#85172
Adding the right context key to change the order like it was in the old bank rec widget of 18.2. Also correcting a css issues where the ref where too big no task id Forward-Port-Of: odoo/enterprise#85441
Original PR description
Adding the right context key to change the order like it was in the old bank rec widget of 18.2. Also correcting a css issues where the ref where too big no task id Forward-Port-Of: odoo/enterprise#85441
### Steps to reproduce: - Create a recurring service (product) with invoicing policy set as 'Based on Timesheets' - Create a subscription using the created product - Create a task and link it to this subscription order - Timesheet 3 line in the task one in the past one on the same date of creation and one in the future. - Create an invoice for this order - Notice the quantity has been invoiced is the present timesheet line only - Notice that the 3 timesheet lines have all been
Original PR description
### Steps to reproduce: - Create a recurring service (product) with invoicing policy set as 'Based on Timesheets' - Create a subscription using the created product - Create a task and link it to this…
### Steps to reproduce: - Create a recurring service (product) with invoicing policy set as 'Based on Timesheets' - Create a subscription using the created product - Create a task and link it to this subscription order - Timesheet 3 line in the task one in the past one on the same date of creation and one in the future. - Create an invoice for this order - Notice the quantity has been invoiced is the present timesheet line only - Notice that the 3 timesheet lines have all been validated ### Cause: This is happening because when trying to link the lines to the invoice we consider the timesheets within the date range that the user might have set in the create invoice wizard. https://github.com/odoo/odoo/blob/9a4ec08b9a6b07470747923d09adcf51f7e4cd6a/addons/sale_timesheet/wizard/sale_make_invoice_advance.py#L33-L51 https://github.com/odoo/odoo/blob/9a4ec08b9a6b07470747923d09adcf51f7e4cd6a/addons/sale_timesheet/models/sale_order.py#L153 ### Fix: In subscription we can use the last and next invoice dates if the user hasn't set a period for the invoice. opw-4523727 Forward-Port-Of: odoo/enterprise#83333 Forward-Port-Of: odoo/enterprise#80582
Before this commit, when pos_blackbox_be was installed, the pos tests were failing because most pos test called `_run_test` which is calling `_satrt_pos_session` which is calling `open_new_session` which is calling `set_opening_control`. This makes that when calling `set_opening_control`, the request is not bound and we cannot do `request.geoip.ip`. We now check that the request is bound in `_log_ip`: if it is not, we return, if it is, we resolve the ip on the fly. We also add a check to t
Original PR description
Before this commit, when pos_blackbox_be was installed, the pos tests were failing because most pos test called `_run_test` which is calling `_satrt_pos_session` which is calling `open_new_session` which is calling `set_opening_control`. This makes that when calling `set_opening_control`, the request is not bound and we cannot do `request.geoip.ip`. We now check that the request is bound in `_log_ip`: if it is not, we return, if it is, we resolve the ip on the fly. We also add a check to the sale details data computation method `get_sale_details` override in pos_blackbox_be to check if the config is a blackbox one. original commit: df796f3770ff2fdaf553cdfb4206f65c7b371189 Community PR: https://github.com/odoo/odoo/pull/209584 Forward-Port-Of: odoo/enterprise#85356
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#85089 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#85089 Forward-Port-Of: odoo/enterprise#74760
The error was caused by the ability to `quick-create` digital certificates from the settings screen without providing the actual certificate file. This results in False being stored in the certificate content fields, ultimately triggering a `TypeError` during PDF signing. Steps to reproduce: - Go to Settings > Search for `Cryptographic signature` > Quick create a Certificate with random name and save. - Now sign and validate any file, you will encounter the error. Error: `TypeError: exp
Original PR description
The error was caused by the ability to `quick-create` digital certificates from the settings screen without providing the actual certificate file. This results in False being stored in the certificate content fields, ultimately triggering a `TypeError` during PDF signing. Steps to reproduce: - Go to Settings > Search for `Cryptographic signature` > Quick create a Certificate with random name and save. - Now sign and validate any file, you will encounter the error. Error: `TypeError: expected bytes-like object, not bool` Solution: - Removed being able to quick create certificates. sentry-6545302218 Forward-Port-Of: odoo/enterprise#85276
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
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 Forward-Port-Of: odoo/enterprise#83222
Steps to reproduce - Install Accounting - Go to settings and activate Analytic Accounting - Go to Configuration and create two analytic plans without any analytic accounts - Go to the Profit and Loss report - Activate the two new analytic plans -> the report is messed up in its columns Cause of the issue: When two analytic plans without any analytic account are present, they have the exact same forced_options, leading to the same column_group_key. task-4675686 Forward-Po
Original PR description
Steps to reproduce - Install Accounting - Go to settings and activate Analytic Accounting - Go to Configuration and create two analytic plans without any analytic accounts - Go to the Profit and Loss report - Activate the two new analytic plans -> the report is messed up in its columns Cause of the issue: When two analytic plans without any analytic account are present, they have the exact same forced_options, leading to the same column_group_key. task-4675686 Forward-Port-Of: odoo/enterprise#82231
Description of the issue this commit addresses: When multiple lines that are in budget on their own are above budget when summed together, neither the lines nor the budget button show that the budget will be exceeded. This leads to making purchase orders that shouldn't be made. --- Desired behavior after this commit is merged: This commit makes it so that when the lines together will exceed the budget, the budget smart button and all the lines become red as a single line would.
Original PR description
Description of the issue this commit addresses: When multiple lines that are in budget on their own are above budget when summed together, neither the lines nor the budget button show that the budget will be exceeded. This leads to making purchase orders that shouldn't be made. --- Desired behavior after this commit is merged: This commit makes it so that when the lines together will exceed the budget, the budget smart button and all the lines become red as a single line would. --- task-4710838 Forward-Port-Of: odoo/enterprise#84653
Currently the "resend" mechanism relies on `_send`; marking messages to resend as "outgoing". However when used in batch mode `_send` only sends template messages. We enable `_send_cron` to send discuss messages too and to process these in priority. As these have a fixed time limit to be sent. We also do some filtering on resend to avoid marking messages that we know will fail as outgoing. Including "unrecoverable" errors and messages on outdated channel. Methods that use crons are a
Original PR description
Currently the "resend" mechanism relies on `_send`; marking messages to resend as "outgoing". However when used in batch mode `_send` only sends template messages. We enable `_send_cron` to send discuss messages too and to process these in priority. As these have a fixed time limit to be sent. We also do some filtering on resend to avoid marking messages that we know will fail as outgoing. Including "unrecoverable" errors and messages on outdated channel. Methods that use crons are also updated to use direct method trigger and prevent commits during tests to avoid having to patch them every time. task-3547088 Forward-Port-Of: odoo/enterprise#85014 Forward-Port-Of: odoo/enterprise#79050
Before this commit, whatsapp conversations could not send voice message. This is a regression made from this PR: https://github.com/odoo/odoo/pull/186084 This commit re-adds the feature to voice a message in whatsapp. Note that whatsapp conversations allow only 1 attachments per message. Since a voice message is an attachment, this commit makes sure allow voice message only when no attachment, and similarly allow uploading a file only when there's no ongoing voice recording. opw-4750
Original PR description
Before this commit, whatsapp conversations could not send voice message. This is a regression made from this PR: https://github.com/odoo/odoo/pull/186084 This commit re-adds the feature to voice a message in whatsapp. Note that whatsapp conversations allow only 1 attachments per message. Since a voice message is an attachment, this commit makes sure allow voice message only when no attachment, and similarly allow uploading a file only when there's no ongoing voice recording. opw-4750594 Forward-Port-Of: odoo/enterprise#85326 Forward-Port-Of: odoo/enterprise#85303
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic distribution - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Activate "Analytic Group By" in the settings of the report - Add the plan used in the analytic distribution in "Analytic" group option **Issue:** In the "End Balance" column, all the amounts are summed in the total colu
Original PR description
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic distribution - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Activate "Analytic Group By" in the settings of the report - Add the plan used in the analytic distribution in "Analytic" group option **Issue:** In the "End Balance" column, all the amounts are summed in the total column instead of being grouped by analytic plan. It results on a total amount being twice what it should be as the total column of each period is also included in the sum. This is a complement to previous fix for the grouping by analytic account where the analytic plan groupby case was forgotten: https://github.com/odoo/enterprise/commit/05bbab713c749b7d7450d5dbaf2eda1ba4f68712 opw-4648009 Forward-Port-Of: odoo/enterprise#85372 Forward-Port-Of: odoo/enterprise#85344
31 changes
Enhancements to existing features
Odoo can now recognize UBL AttachedDocument wrapper files and extract the original invoice or document inside for normal processing. This improves compatibility with electronic invoicing systems, including Colombian EDI flows and other UBL-compliant platforms that send bundled documents.
Original PR description
AttachedDocuments are a wrapper filetype in the UBL 2.0/2.1 specification that allows for multiple documents to be bundled together. Colombia uses it as a way to return back values from the EDI but it is in the standard and can therefore be used by any UBL 2.0/2.1 compliant system. To be able to parse the documents inside correctly, we must obtain the original record which is stored in the outermost Attachment node either under the EmbeddedDocumentBinaryObject element or the ExternalReference/Description node. Once we find it we send it to the normal decoder process. Specification: https://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AttachedDocument-2.1.html task-4299222
Odoo’s Colombian localization now includes standard consumption taxes and related accounts needed for products such as alcohol. This prepares Colombian businesses to use upcoming point-of-sale capabilities with the required taxes available out of the box, including migration support for existing databases.
Original PR description
Consumption taxes are required for alcohol and other products, withthe POS module for Colombia coming out soon it's necessary to support such taxes out of the box for when it's released. A migration script has been added to automatically load these new taxes and accounts that will be necessary. task-4634313 Enterprise PR: https://github.com/odoo/enterprise/pull/84717
Users can now click anywhere across the Activities column in list views, not just on a small activity control. This makes opening and managing activities easier and reduces misclicks during daily work.
Original PR description
After this commit, the full width of the Activities column in a list view will be clickable, for ease of use. task-4525830
Uruguayan electronic invoice PDFs now better match the customer’s language preference by requesting English reports when the customer is not set to Spanish. Longer addenda, such as terms and mandatory disclosures, are now placed on a dedicated page when needed so important text is not cut off.
Original PR description
This fixes two issues with the report. The first one is automatically requesting an English report if the customer's preferred language is not Spanish. This way the lang field on the partner is somewhat respected for these externally generated reports too. The second fix requests a dedicated addenda page when appropriate. By default, the addenda (e.g. terms and conditions) is added in a small box at the bottom of the standard PDF report. This can only accomodate roughly 6 lines of 140 characters. If the addenda exceeds that, the remainder is silently cut off which is problematic for mandatory disclosures etc. It's possible to request a dedicated addenda page in the PDF that fixes this issue. We considered always requesting it, but it looks strange to have a whole page in the PDF if the addenda is very short. We therefore make a best effort attempt to figure out if the addenda will fit in the standard report or not. task-4750717
Colombian electronic invoicing now handles the special tax calculation required for alcoholic beverages, similar to existing support for sugary drink taxes. Product tax data was generalized so businesses can provide the required tax component details for different product-specific taxes, helping invoices comply with DIAN rules.
Original PR description
Like the sugar tax, alcohol is also taxed differently in Colombia such that we need a special case for how to compute it. The Per Unit Amount is the total tax amount divided by the alcohol percentage. To facilitate this change, the field that was previously used for the volume in ml for sugary drinks has been made into a generic "Specific Component Nominal Tax" field which can be used for any extra tax data depending on what type of tax is on the product. Comm PR: https://github.com/odoo/odoo/pull/208500 task-4634313
Odoo can now import Colombia DIAN AttachedDocument files received from vendors, which include the original invoice and related regulatory information. This helps businesses process supplier billing documents more directly and reduces manual handling of compliant Colombian e-invoicing files.
Original PR description
AttachedDocument is a specific XML format used in Colombia, generated by the DIAN regulatory body. These Documents are commonly received from vendors as they contain complete billing information. While Odoo 18.0+ can generate AttachedDocument records for outgoing invoices, it lacks import functionality. This document format contains nested XML documents that represent related records such as DIAN responses, Commercial Events data, and the orignal vendor invoice. The DIAN specifications state that for an AttachedDocument with specified DocumentType must contain the original invoice within the top-most <cac:Attachment> node. (All other documents attached with this file are wrapped in <cac:ParentDocumentLineReference> tags which differentiates it) Specifications: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Techico-Factura-Electronica-de-Venta-vr-1-9.pdf task-4299222
This update adds support for showing tooltip information from the related field in the Documents area. It helps users better understand document options without changing their workflow.
Original PR description
Community https://github.com/odoo/odoo/pull/210097
Resolved issues and error corrections
This fix prevents new Odoo databases from failing when they are created with certain regional languages, such as Argentinian Spanish. It ensures language settings are applied in the right order so setup completes successfully without duplicate language code errors.
Original PR description
**Steps to reproduce:** 1. Initialize a new database with `odoo -d langdb --stop -i base --load-language=es_AR` **Result:** ``` 2025-01-03 11:41:28,054 54 INFO langdb odoo.modules.loading: loading…
**Steps to reproduce:**
1. Initialize a new database with `odoo -d langdb --stop -i base --load-language=es_AR`
**Result:**
```
2025-01-03 11:41:28,054 54 INFO langdb odoo.modules.loading: loading base/data/res_bank.xml
2025-01-03 11:41:28,057 54 INFO langdb odoo.modules.loading: loading base/data/res.lang.csv
2025-01-03 11:41:28,076 54 INFO langdb odoo.modules.loading: loading base/data/res_lang_data.xml
2025-01-03 11:41:28,091 54 ERROR langdb odoo.sql_db: bad query: b' UPDATE "res_lang"\n
SET "url_code" = "__tmp"."url_code"::VARCHAR, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4\n
FROM (VALUES (68, \'es\', \'2025-01-03T11:41:26.517428\'::timestamp, 1)) AS "__tmp"("id", "url_code", "write_date", "write_uid")\n
WHERE "res_lang"."id" = "__tmp"."id"\n'
ERROR: duplicate key value violates unique constraint "res_lang_url_code_uniq"
DETAIL: Key (url_code)=(es) already exists.
```
**Explanation:**
When initializing a new database with a specific language, the language is activated on `install_lang`, and since it's the only active language of the "es_*" family, its url_code is set to the short version. [^1]
By the time the url_code switch in `res_lang_data.xml` is executed, the `base.lang_es` language is no longer the one with "es" as url_code. It's actually the recently activated es_AR language.
**Solution:**
We must perform the `url_code` switch before calling `install_lang`
[^1]: https://github.com/odoo/odoo/blob/c042e1ba/odoo/addons/base/models/res_lang.py#L339-L356
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prBarcode scanning in Point of Sale no longer opens the product configuration popup when a product has only one available attribute option. This makes checkout faster and avoids unnecessary cashier interruptions.
Original PR description
Before this commit, scanning the barcode of a product with attributes set to never creation type, but with only one option available, would still trigger the product configuration popup. opw-4754801 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Event badges with long event names now keep the QR code separate from the badge text. This prevents printed badges from becoming unreadable and helps event check-in materials remain usable.
Original PR description
Steps to reproduce: 1. Go to Events. 2. Create a new event with a long name. 3. Add a product. 4. Print the "Badge Example". Issue: When printing a badge from an event with a long name, the QR code overlaps or clips the information above it, making the badge unreadable. Cause: The issue is due to the large font size used for the event name. Solution: Reduced the font size of the event title to fs-5 to ensure enough spacing is maintained between the text and the QR code, avoiding layout overlap. opw : 4783750 Before FIX:  After FIX: 
This fixes a problem in the website live chat test flow that was causing automated build checks to fail. It helps keep the release validation process stable without changing the user-facing live chat experience.
Original PR description
Runbot Build Error: https://runbot.odoo.com/odoo/runbot.build.error/111747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing the style of selected link text in the editor no longer causes an error. This makes formatting links more reliable for users working in apps such as To-do.
Original PR description
Steps to Reproduce: 1. Go to the To-do module. 2. Create a link. 3. Select the entire content using Ctrl + A. 4. Change the font style from 'Normal' to another (e.g., 'Header 1'). 5. A traceback is…
Steps to Reproduce: 1. Go to the To-do module. 2. Create a link. 3. Select the entire content using Ctrl + A. 4. Change the font style from 'Normal' to another (e.g., 'Header 1'). 5. A traceback is thrown, although the link’s font style is changed. Description of the issue/feature this PR addresses: - The issue was caused by the presence of a `FEFF` (zero-width no-break space) character inside the selected text. This caused a conflict during selection restoration after the font style change. The clean handler was being triggered after the font change attempt, which led to an invalid cursor state. Current behavior before PR: - A Traceback occurred when changing the font style of a selected link text. Desired behavior after PR is merged: - The clean handler is now explicitly called before the font change tries to restore the cursor, avoiding the invalid range or selection error. task-4743390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes how fixed-rate IEPS taxes are reported on Mexican electronic invoices and related payment documents. This helps ensure tax values are sent correctly to the tax authority, reducing validation errors and manual follow-up.
Original PR description
See test in this commit. opw-4744627
Customer follow-up emails now correctly include the overdue invoice attachments again. This ensures customers receive the documents they need to understand and pay outstanding amounts, including when automated follow-ups are run.
Original PR description
### Steps to reproduce:
- Create an invoice with a due date past for long time
- Accounting > Customers, click on the partner of the invoice
- In the page "Accounting" the "Follow-up Status" should be "In need of action"
- Go to the Scheduled Action "Account Report Followup; Execute followup" and Run manually
- Go back to the partner
- The follow-up is send without the invoices
### Cause:
This [commit](https://github.com/odoo/enterprise/pull/84114) moved a part of code to fix a bug but it also changed it: it moved `'attachment_ids' not in options` from the end to the beginning. By doing that the line
`options.get('attachment_ids', self._get_invoices_to_print(options).message_main_attachment_id.ids)`
does not work anyore because `attachment_ids` is always in `options` so `_get_invoices_to_print` is never called.
### Solution:
Use `setdefault` instead of `get`.
opw-4716458This fixes an issue where newly selected Knowledge cover images could be incorrectly linked to an older cover record. As a result, the system cleanup process could delete the active cover image; the change ensures covers remain visible after cleanup.
Original PR description
The overhaul of html editor into knowledge introduced an issue involving the auto-vaccuum. This commit https://github.com/odoo/enterprise/commit/08d84f8b61450a0ebd0d2aadfe8f227bda283edd passes the res_id value of the currently existing knowledge.cover record. However, when we set a new cover image, we will always create a new cover record and the new cover image attachments are linked to the previous cover record. The auto-vaccuum then deletes unused cover images and any attachments linked, which will delete the actual cover image. The web_unsplash/attachment/add does not need to pass in a res_id of the cover image since we always create a new record at the end of the workflow. opw-4629300
This fix prevents a Kenya payroll accounting test from failing when the separate SHIF payroll component is not installed. It improves reliability for single-app deployments without changing payroll behavior for end users.
Original PR description
## Version: 17.0+ ## Issue: Test (introduced by task 4457038) fails on Single App because of missing dependency. Relies on SHIF_AMOUNT https://github.com/odoo/enterprise/blob/ffb0aa8d7aad913328bb0b585197172da4e838b3/l10n_ke_hr_payroll_shif/data/hr_salary_rule_data.xml#L46C1-L47C1 runbot-159825
Miscellaneous changes
This commit removes a useless break line added to the end of chat ratign. Break line is used to put the reason on a different line than the rating smiley but is useless when no reason is passed. task-4791376 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#209571
Original PR description
This commit removes a useless break line added to the end of chat ratign. Break line is used to put the reason on a different line than the rating smiley but is useless when no reason is passed. task-4791376 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#209571
__Current behavior before commit:__ The QR code on the payment page is cropped when the Pending Message of the payment provider has a long line. __Description of the fix:__ Set `flex-shrink-0` to the QR code card so it doesn't shrink. __Steps to show the cropped QR code:__ 1. Install sale_management and website 2. Set company currency to EUR 3. Enable QR Codes under Customer Payments in Settings 4. Enable Online Payment (and disable Online Signature) under Quotations & Orders 5. In
Original PR description
__Current behavior before commit:__ The QR code on the payment page is cropped when the Pending Message of the payment provider has a long line. __Description of the fix:__ Set `flex-shrink-0` to the QR code card so it doesn't shrink. __Steps to show the cropped QR code:__ 1. Install sale_management and website 2. Set company currency to EUR 3. Enable QR Codes under Customer Payments in Settings 4. Enable Online Payment (and disable Online Signature) under Quotations & Orders 5. In Payment Providers, install SEPA Direct Debit. Select Test mode, check Enable QR Codes, and publish it. 6. **In Messages tab, put a very long line as Pending Message** 7. Go to the Journal "Bank" and set a random IBAN as Account number 8. Create a new Quote with a non 0 price and click on Preview and pay the order 9. The QR code is cropped opw-4735003 Forward-Port-Of: odoo/odoo#209686
For proper provision management we introduce accounts 2350 and 2351 task-4797323 Forward-Port-Of: odoo/odoo#210062
Original PR description
For proper provision management we introduce accounts 2350 and 2351 task-4797323 Forward-Port-Of: odoo/odoo#210062
### Issue In project sharing, tasks in the "Done" and "Approved" stages were not shown with distinct progress in the Kanban progress bar. As a result, users were unable to identify the task status easily. ### Reason: The color class was set incorrectly. ### Fix: We have updated the color class in this commit to correctly reflect the task stages. issue-https://github.com/odoo/odoo/commit/1a44b849970d3e39111a99ea35db5b586b184dd3 ### Steps to Reproduce: - Create a projec
Original PR description
### Issue
In project sharing, tasks in the "Done" and "Approved" stages were not shown with distinct progress in the Kanban progress bar. As a result, users were unable to identify the task status easily.
### Reason:
The color class was set incorrectly.
### Fix:
We have updated the color class in this commit to correctly reflect the task stages.
issue-https://github.com/odoo/odoo/commit/1a44b849970d3e39111a99ea35db5b586b184dd3
### Steps to Reproduce:
- Create a project with 2 tasks:
- Task 1 in the "Done" stage
- Task 2 in the "Approved" stage
- Share the project with a portal user
- Open the project in the portal
- Navigate to the project sharing Kanban view and check the progress bar
task-4551177
Forward-Port-Of: odoo/odoo#206031Some services or applications (Outlook, Google Messages) display previews of links sent through messages or email. In an effort to strengten user privacy, these services fetch the previews from their own servers rather than from the user's device. Since these services' requests had not been added to the list of known bot identifiers, they generate parasite "clicks" which don't match their user. This commit adds identifiers for the Outlook and Google Messages service requests to the l
Original PR description
Some services or applications (Outlook, Google Messages) display previews of links sent through messages or email. In an effort to strengten user privacy, these services fetch the previews from their own servers rather than from the user's device. Since these services' requests had not been added to the list of known bot identifiers, they generate parasite "clicks" which don't match their user. This commit adds identifiers for the Outlook and Google Messages service requests to the list of known bot IDs, thereby preventing the parasite clicks from generating. task-3672491 Forward-Port-Of: odoo/odoo#200148 Forward-Port-Of: odoo/odoo#167799
Steps to reproduce: - When the planning module is not installed and we click on employee avatar - This leads to a traceback, especially when the related employee data is available only in hr.employee.public or hr.employee. Cause: - The avatar card component was using a hardcoded model instead of dynamically using props.record.model. Although a custom get_avatar_card_data method was introduced to centralize data logic, it was not implemented on all relevant models (hr.employee,
Original PR description
Steps to reproduce: - When the planning module is not installed and we click on employee avatar - This leads to a traceback, especially when the related employee data is available only in…
Steps to reproduce: - When the planning module is not installed and we click on employee avatar - This leads to a traceback, especially when the related employee data is available only in hr.employee.public or hr.employee. Cause: - The avatar card component was using a hardcoded model instead of dynamically using props.record.model. Although a custom get_avatar_card_data method was introduced to centralize data logic, it was not implemented on all relevant models (hr.employee, hr.employee.public), which caused traceback in certain setups. Solution: - Replaced the hardcoded model with props.record.model to dynamically resolve the model. - Added the get_avatar_card_data method to hr.employee.base to ensure compatibility. Ensured the logic works correctly even when the planning module is not installed. Follow-up to: - Commit : https://github.com/odoo/odoo/pull/187171 https://github.com/odoo/enterprise/pull/75121 - prevent component destruction which moved avatar card data fetching into a parent method to avoid lifecycle issues. Related task-4210513 task - 4777570 Forward-Port-Of: odoo/odoo#210027
To reproduce: ============= - have an employee with a working schedule of night shifts like 18:00 to 00:00 break to 01:00 then continue to 03:00 - create payslip for this employee for January 2025 - print the payslip, the working hours will be 183.9936 The problem: ============ 00:00 is represented as 23:59:59.99999 in python, that missing microsecond impacts the computation of the duration of the work entry. The solution: ============= round the total seconds opw-4702410 ---
Original PR description
To reproduce: ============= - have an employee with a working schedule of night shifts like 18:00 to 00:00 break to 01:00 then continue to 03:00 - create payslip for this employee for January 2025 - print the payslip, the working hours will be 183.9936 The problem: ============ 00:00 is represented as 23:59:59.99999 in python, that missing microsecond impacts the computation of the duration of the work entry. The solution: ============= round the total seconds opw-4702410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208811
Fixes an issue when issuing self-billed invoices to the platform. So far we have been using Odoo's bill name as ID, but we should instead use the bill reference (if set) to use the supplier number. task-4777585 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208721
Original PR description
Fixes an issue when issuing self-billed invoices to the platform. So far we have been using Odoo's bill name as ID, but we should instead use the bill reference (if set) to use the supplier number. task-4777585 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208721
The aim of this commit is to: - avoid reporting negative amount in a 281.50 form which are rejected by the administration. - avoid reporting form with 0 value everywhere which are rejected by the administration. - avoid reporting a form with an amount < 250 EUR Context: The administration stated that we don't need to make any report that would be above 250 EUR. (art. 57, al. 3 CIR 92 et art. 30 AR/CIR 92) https://www.wolterskluwer.com/fr-be/expert-insights/tax-form-281-50
Original PR description
The aim of this commit is to: - avoid reporting negative amount in a 281.50 form which are rejected by the administration. - avoid reporting form with 0 value everywhere which are rejected by the…
The aim of this commit is to:
- avoid reporting negative amount in a 281.50 form which are rejected by the administration.
- avoid reporting form with 0 value everywhere which are rejected by the administration.
- avoid reporting a form with an amount < 250 EUR
Context:
The administration stated that we don't need to make any report that would be above 250 EUR.
(art. 57, al. 3 CIR 92 et art. 30 AR/CIR 92)
https://www.wolterskluwer.com/fr-be/expert-insights/tax-form-281-50 https://travaillerensociete.indicator.be/main/newsadvice/52784/news/52785/news_story/533/ https://www.monastucesetconseils.be/2025-04/fiches-fiscales-281-50-pour-le-29-juin-2025-WAACPCAR_EU33150802
Before this commit:
Odoo could create a form with a negative amount as commission/fee/... This could result in the administration software converting the xml into a BOW file to generated an error and a file that will be rejected by Belcotax.
Same for form with 0 everywhere.
Also, accountants always end up deleting the 281.50 form below 250 EUR as those don't need to be reported.
After this commit:
Odoo don't report negative or null total amount as commission/fee/... and doesn't create any form if the total amounts are below 250 EUR saving accountants the burden to remove them.
task-id: None
This was discussed and done with TSB and DELC and is also the result of our past experiences reporting 281.50 forms which also involved CAHE, MAKR and CAL.
Forward-Port-Of: odoo/enterprise#85508Before this commit: Some of the names in the stock_type list were wrong, causing an invalid type error when validating delivery. After the commit: Added a lookup table to update the incorrect names to match names in FedEx documentation. Fedex docs: https://developer.fedex.com/api/en-is/catalog/ship/docs.html opw-4725488 Forward-Port-Of: odoo/enterprise#84762
Original PR description
Before this commit: Some of the names in the stock_type list were wrong, causing an invalid type error when validating delivery. After the commit: Added a lookup table to update the incorrect names to match names in FedEx documentation. Fedex docs: https://developer.fedex.com/api/en-is/catalog/ship/docs.html opw-4725488 Forward-Port-Of: odoo/enterprise#84762
Implement new Swiss municipality OFS number assignment for ERP systems based on 2025 AFC list. This commit updates the address validation and municipality assignment logic in the ERP system to align with the new "Liste des communes OFS 2025 pour l’attribution du numéro de commune au code postal" published by the Swiss Federal Tax Administration (AFC) for withholding tax purposes. Forward-Port-Of: odoo/enterprise#84859
Original PR description
Implement new Swiss municipality OFS number assignment for ERP systems based on 2025 AFC list. This commit updates the address validation and municipality assignment logic in the ERP system to align with the new "Liste des communes OFS 2025 pour l’attribution du numéro de commune au code postal" published by the Swiss Federal Tax Administration (AFC) for withholding tax purposes. Forward-Port-Of: odoo/enterprise#84859
For proper provision management we introduce accounts 2350 and 2351 task-4797323 Forward-Port-Of: odoo/enterprise#85574
Original PR description
For proper provision management we introduce accounts 2350 and 2351 task-4797323 Forward-Port-Of: odoo/enterprise#85574
Fix a bug where account moves paid with cash appears in a line with full 0 in the boe export of mod347 tax report. But it shouldn't create a line at all, so this commit remove the lines in this case. task-4613012 Forward-Port-Of: odoo/enterprise#84317
Original PR description
Fix a bug where account moves paid with cash appears in a line with full 0 in the boe export of mod347 tax report. But it shouldn't create a line at all, so this commit remove the lines in this case. task-4613012 Forward-Port-Of: odoo/enterprise#84317
When timezone of user is empty and the user clicks on Add Closing Day(s) button, a traceback will appear. Steps to reproduce the error: - Open Profile > Preferences > Select empty in timezone > Save - Install ``Appointments`` - Go to Appointments > Schedule > Resource Bookings > Add Closing Day(s) Traceback: ``` File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 19, in <lambda> leave_start_dt = fields.Datetime('Start Date', required=True, defa
Original PR description
When timezone of user is empty and the user clicks on Add Closing Day(s) button, a traceback will appear. Steps to reproduce the error: - Open Profile > Preferences > Select empty in timezone > Save…
When timezone of user is empty and the user clicks on Add Closing Day(s) button,
a traceback will appear.
Steps to reproduce the error:
- Open Profile > Preferences > Select empty in timezone > Save
- Install ``Appointments``
- Go to Appointments > Schedule > Resource Bookings > Add Closing Day(s)
Traceback:
```
File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 19, in <lambda>
leave_start_dt = fields.Datetime('Start Date', required=True, default=lambda self: self._default_time(0, 0))
File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 14, in _default_time
user_timezone = pytz.timezone(self.env.user.tz or self.env.context.get('tz', 'utc'))
File "/home/odoo/src/odoo/odoo/_monkeypatches/pytz.py", line 129, in timezone
return original_pytz_timezone(name)
File "__init__.py", line 183, in timezone
if zone.upper() == 'UTC':
AttributeError: 'bool' object has no attribute 'upper'
```
https://github.com/odoo/enterprise/blob/2c938b66fc1b526a360f4b199a47bcc53991bcb9/appointment/wizard/appointment_manage_leaves.py#L14
When the user selects an empty timezone, tz will be False.
So, It will lead to the above traceback.
Forward port https://github.com/odoo/enterprise/pull/64948 was closed in master,
so the issue is still present in saas-17.4 and all later versions.
sentry-6537084290
Forward-Port-Of: odoo/enterprise#83363This commit will do a backport of the python change made in this commit: https://github.com/odoo/enterprise/pull/77565/commits/7f26eefa932ec09297fbc4b8256ebe0b2976b231 task-4476707 Forward-Port-Of: odoo/enterprise#84728
Original PR description
This commit will do a backport of the python change made in this commit: https://github.com/odoo/enterprise/pull/77565/commits/7f26eefa932ec09297fbc4b8256ebe0b2976b231 task-4476707 Forward-Port-Of: odoo/enterprise#84728