Daily updates from Odoo
Wednesday, March 11, 2026
113 changes
31 changes
Resolved issues and error corrections
This update fixes an issue where the 'Create Page' button in the edit menu didn't correctly use the automatically generated, slugified URL for new pages. The change ensures that newly created pages are properly linked through the menu, improving the user experience and preventing broken links.
Original PR description
The "Create Page" button was added in edit menu dialog in commit 990b7c045bf27280c64433510d6e43fba5b3a4b0. The button creates a page using the link in the menu for the url of the page, but the actual page creation may use a different url (as it slugifies it). This commit uses the url returned by the server on page creation to update the url of the menu, and correctly redirect to the new page. Steps to reproduce: - In edit menu > menu item, create a menu with url `/abc,xyz` - In edit menu, click "Create Page" - The page is created with a url that is slugified - Bug: but the menu does not use the slugified new url, and the url to which we redirect is not that one either task-5895401 Forward-Port-Of: odoo/odoo#246472
This update fixes a minor visual issue in the member list within Odoo, specifically improving the alignment and spacing of the star icon and member names. The changes enhance the overall readability and aesthetics of the interface, providing a slightly cleaner user experience. This is a cosmetic improvement.
Original PR description
- reduced spacing with the member name - better vertical alignment of name and star icon - some spacing with the "..." button when member name is long Before / After <img width="241" height="205" alt="Screenshot 2026-03-06 at 15 16 44" src="https://github.com/user-attachments/assets/448a8d5c-36a4-4018-89f3-cf89dabdac8a" /> <img width="237" height="195" alt="Screenshot 2026-03-06 at 15 15 47" src="https://github.com/user-attachments/assets/29968c76-51f8-498e-ac9a-98861d3360a2" /> Before / After <img width="241" height="206" alt="Screenshot 2026-03-06 at 15 16 56" src="https://github.com/user-attachments/assets/96a0ee34-ec87-418f-8ecd-0025dfe79387" /> <img width="244" height="197" alt="Screenshot 2026-03-06 at 15 16 10" src="https://github.com/user-attachments/assets/9a4dc28c-8ba3-4992-8230-0aa4f8af382c" /> Forward-Port-Of: odoo/odoo#252481
This update fixes an issue where the 'Today' button in the Gantt view didn't reliably return to the current date after navigating from yesterday. The fix ensures the button functions as expected, providing a consistent user experience when viewing schedules. This improves usability for users managing appointments and tasks.
Original PR description
**Version:** 18.0 **Steps to reproduce:** - Install Attendance modules. - Navigate to yesterday using the arrow button. - Then click on Today button. **Issue:** The view does not return to the current day when Today button is clicked. **Cause:** The condition to check this scenario fails for this case. **Fix:** Updated the condition to include the this scenario. task-5451384 Forward-Port-Of: odoo/enterprise#109245 Forward-Port-Of: odoo/enterprise#103139
This update fixes an issue where the sale preview became bloated when using combo products with the 'Hide Composition' option selected. The change prevents the system from displaying incorrect zero-priced sections, resulting in a cleaner and more efficient preview. This improves the user experience when managing quotes with combo items.
Original PR description
**Behavior:** When a combo product is added under a section and the 'Hide Composition' option is selected the system will try to get a list of the prices grouped by different taxes, however since combo items usually don't cost anything and are not under any tax group, the quotation preview will try show the section's total prices under no tax which will likely amount to 0$ This results in a bloated preview. Solution: Only accept a grouping under a specific tax (be it no tax or a real tax) if the total price != 0$ **Steps to reproduce:** - Create a combo product containing a product that is taxed - Create a quote with a section - Add the product under the section - Check 'Hide Composition' in the section's options - Preview the sale - You'll notice the section duplicated with no tax and no price opw-5481931 Forward-Port-Of: odoo/odoo#245866
This update resolves an issue preventing users from creating sales orders when specific project user group permissions were restricted. The fix adjusts how the system accesses project information, now allowing creation regardless of project group settings. This ensures broader usability and eliminates a restriction on sales order creation.
Original PR description
Issue: --- Users cannot create so without project user group. Steps to reproduce: --- 1- Install `sale_timesheet`, `sale_project` 2- Change demo user access: - Sales: own documents - Timesheets: own documents - Project: No 3- Login demo user and create a SO. SO creation fails on `read` operation on `project_count`. Cause and Fix: --- This is due to `_compute_show_hours_recorded_button`, which needs `project_count` to be computed. However, `SO.project_count` is only accessible by `project.group_project_user`. This can be fixed by a `compute_sudo` on show_hours_recorded_button. Security-wise this should be fine, as `show_hours_recorded_button` itself is only accessible by `hr_timesheet.group_hr_timesheet_user`. opw-5944881 Forward-Port-Of: odoo/odoo#250694
This update resolves a bug where renewing a subscription while another process was closing it resulted in the subscription being incorrectly marked as churned. The fix ensures that subscriptions are only processed when their status is active, preventing this race condition and ensuring accurate subscription management.
Original PR description
Steps to reproduce: - Have a subscription ready to expire/auto-close. - Trigger the `_cron_subscription_expiration` cron. - While the cron is processing earlier batches, manually renew the subscription. - The renewed subscription is incorrectly marked as closed/churned. Cause: The cron searches for all expired/unpaid subscriptions at the very beginning and processes them in batches of 30. If a subscription is renewed concurrently (Race condition), its ID is already in the `subscriptions_close` list, causing the cron to close it regardless of its new state. Solution: Inside the batch processing loop, consider only subscriptions that are strictly still in `SUBSCRIPTION_PROGRESS_STATE`. Task: 5929077 Forward-Port-Of: odoo/enterprise#107157
A previous shortcut in the asset management module was causing users to navigate to the wrong view instead of the previous asset. This update corrects this issue by changing the shortcut from ALT+P to ALT+SHIFT+P, aligning with existing shortcuts and improving usability.
Original PR description
# How to reproduce - Have atleast two assets - Go to the last asset - Type ALT + P on your keyboard # The problem We enter the Posted Entries view instead of going to the previous asset # Why This PR (https://github.com/odoo/enterprise/pull/67840) added shortcuts to the asset form view, but used ALT + P for the Posted Entries. This shortcut is already used on all form views for the "previous page" button. After consulting with the developer of the original PR, we decided to move the Posted Entries shortcut to ALT + SHIFT + P opw-5948523 Forward-Port-Of: odoo/enterprise#109022
This update resolves an issue where German addresses submitted to Amazon were being incorrectly formatted, causing delivery validation failures. The fix swaps the order of address fields to align with Amazon's requirements, ensuring accurate address data and successful deliveries for German customers. This improves the overall customer experience.
Original PR description
When filling in a German address on Amazon, customers are presented with two fields: - Street, and - Building or company name. The street is sent as AddressLine2, while the building/company name is sent as AddressLine1. However, delivery providers validate address existence, which fails when address line 1 is not a street name. To resolve this, we swap these two fields for German addresses. opw-4668178 Forward-Port-Of: odoo/enterprise#109215
This update addresses instability in the HTML editor's automated testing process. The team identified that waiting for visual elements to load wasn't reliable due to testing bot delays. The fix focuses on more robust function call timing to ensure tests consistently pass, improving overall editor stability.
Original PR description
Forward-Port-Of: odoo/odoo#252306 Forward-Port-Of: odoo/odoo#251122
This update corrects a display issue where single-day time off requests were incorrectly shown as multi-day events in the Calendar app. The fix ensures that one-day leaves are accurately represented as single-day events, regardless of the user's timezone, preventing confusion and improving calendar accuracy.
Original PR description
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC.…
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`) In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to: - holiday.date_from: September 17, 2025 at 03:00 UTC - holiday.date_to: September 18, 2025 at 12:00 UTC causing a single-day leave to be displayed as a two-day event. **After fix:** - start_value: September 17, 2025 at 12:00 - stop_value: September 17, 2025 at 11:59 **Steps to Reproduce:** 1. Set the user timezone to "America/Los_Angeles" 2. Set the browser timezone to the same timezone 3. Create a one-day time off request (e.g., September 17, 2025) 4. Open the Calendar app: the event spans across two days opw-4744817 Forward-Port-Of: odoo/odoo#242264 Forward-Port-Of: odoo/odoo#224298
This update corrects a recent change that broke the ability to customize invoice headers in the l10n_latam invoice document. The fix ensures that custom header configurations work as intended, allowing for consistent branding and formatting. This resolves an issue impacting invoice presentation for Latin American clients.
Original PR description
The document layout was made more flexible [1], but in the process the custom_header feature broke. The xpath was targeting a `<tr>` instead of the `<div>` it was meant to replace. Change it to target the right `<div>` in a slightly more robust way. Also consistently add the same header classes to the replacement `<div>`s in all the themes. [1] https://github.com/odoo/odoo/pull/237109 task-5949275 Backport of https://github.com/odoo/odoo/pull/251341. Forward-Port-Of: odoo/odoo#252916
This update resolves an issue where printing basic receipts would fail if the point-of-sale (POS) name was too long. The fix limits the POS name length to prevent a technical error that disrupted receipt generation. This ensures all receipt types, particularly basic receipts, can be printed correctly.
Original PR description
When printing a basic receipt, if the pos name is too long a traceback will occurs when printing the basic receipt. Steps to reproduce: * Create a pos with a name of 46 character or more * Setup the italian fiscal printer * Enable Basic Receipt printing * Open point of sale * Create an order and validate it * Try "Print Basic receipt" Traceback: RangeError: Invalid count value: -15 at String.repeat () If the data being printed is longer than the maximum number of character in a line (MAX_CHARS = 46), paddingLeft becomes negative which cause an error in repeat(). [Similar solution](https://github.com/odoo/enterprise/blob/18.0/l10n_it_pos/static/src/app/fiscal_printer/commands/print_rec_message/print_rec_message.js#L35) [opw-5270697](https://www.odoo.com/odoo/project/49/tasks/5270697) Forward-Port-Of: odoo/enterprise#109766 Forward-Port-Of: odoo/enterprise#109527
This update fixes an issue where sign requests generated from HR wizards didn't automatically use the validity dates set on sign templates. Now, all sign requests created through these wizards will adhere to the template's expiration settings, ensuring accurate tracking and preventing outdated requests.
Original PR description
Before, when sending sign requests from the HR custom wizards, the validity date defined on the sign template was not applied to the generated signature requests. As a result, requests were created without respecting the template’s configured expiration. task-5928110 Forward-Port-Of: odoo/enterprise#107076
This update fixes an issue where part-time employees were incorrectly showing their full-time hours (40) instead of their actual weekly hours (24) in the attendance calendar. The change ensures the system accurately reflects the employee's flexible schedule, improving reporting and scheduling accuracy.
Original PR description
### Issue: When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.…
### Issue:
When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.
Steps to reproduce:
- Have an employee with a part-time flexible schedule
- `full_time_required_hours`: 40
- `hours_per_week`: 24
- `hours_per_day`: 8
- Go in Attendances
- Hover the employee
- It shows ...h/40h but it should show ...h/24h
Cause:
In `_attendance_intervals_batch()` we build theoretical attendances for flexible employees. Starting at the start of the week, we add an attendance of `hours_per_day` each day until we reached `full_time_required_hours`.
In the case above, we would return five attendances of 8h, ignoring `hours_per_week`.
Then `_get_attendance_intervals_days_data()` counts the hours to display them in the Gantt view.
Solution:
In `_attendance_intervals_batch()` we use `hours_per_week` instead of `full_time_required_hours` as the weekly limit of hours per week.
A lot of tests needed to be adapted, as they were specifying `full_time_required_hours` but not `hours_per_week` when creating calendars.
opw-5973117
Forward-Port-Of: odoo/enterprise#109873
Forward-Port-Of: odoo/enterprise#109645This update fixes an issue where part-time flexible employees were incorrectly displaying their full-time work hours (40) instead of their actual weekly hours (24). The change ensures that the system accurately reflects the employee's scheduled hours, improving accuracy and reporting.
Original PR description
### Issue: When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.…
### Issue:
When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.
### Steps to reproduce:
- Have an employee with a part-time flexible schedule
- `full_time_required_hours`: 40
- `hours_per_week`: 24
- `hours_per_day`: 8
- Go in Attendances
- Hover the employee
- It shows ...h/40h but it should show ...h/24h
### Cause:
In `_attendance_intervals_batch()` we build theoretical attendances for flexible employees. Starting at the start of the week, we add an attendance of `hours_per_day` each day until we reached `full_time_required_hours`.
In the case above, we would return five attendances of 8h, ignoring `hours_per_week`.
Then `_get_attendance_intervals_days_data()` counts the hours to display them in the Gantt view.
### Solution:
In `_attendance_intervals_batch()` we use `hours_per_week` instead of `full_time_required_hours` as the weekly limit of hours per week.
A lot of tests needed to be adapted, as they were specifying `full_time_required_hours` but not `hours_per_week` when creating calendars.
opw-5973117
Forward-Port-Of: odoo/odoo#252568
Forward-Port-Of: odoo/odoo#252190This update clarifies Odoo's logging system by removing the use of error and warning colors for process IDs (PIDs). This change improves readability and prevents users from misinterpreting log messages, leading to a more straightforward understanding of system activity.
Original PR description
At first glance people think there is a problem when the PID is colored using the same color logging.ERROR and logging.WARNING. For clarity we drop those two colors. There now are 11 (still prime) available colors.
This pull request reverts a recent change to the web_studio test suite. The previous modification incorrectly checked for a specific element count (exactly 3 times) instead of verifying it appears at least 3 times. This reversion ensures the test accurately reflects the expected behavior of the web_studio UI, preventing potential issues during development.
Original PR description
Revert modifications made in https://github.com/odoo/odoo/pull/245680 With that modification, we checked that element is exactly 3 times, But this is not the same to check that the element is at least preset 3 times.. Backport of odoo/enterprise#108294
This update resolves an error that occurred when opening the shop page, specifically when products had no variants configured. The fix ensures that the 'Add to Cart' button is correctly displayed or hidden based on product availability, preventing a technical error. This improves the overall stability and usability of the shop page.
Original PR description
Currently, an error occurs when the user opens the shop page. **Steps to Reproduce:** - Install `website_sale_stock` module. - Go to `Settings` and enable `Product Variants`. - Create a `product…
Currently, an error occurs when the user opens the shop page. **Steps to Reproduce:** - Install `website_sale_stock` module. - Go to `Settings` and enable `Product Variants`. - Create a `product template` of type `Goods`. - Enable `Track Inventory`. - In the `Sales tab`, disable `Sell when Out-of-Stock`. - In the `Attributes & Variants` tab, add one attribute with two values and save. - Delete all variants using the `Variants smart button` or from Inventory > Products > Product Variants. - Go to `Website` > `Shop`. **Error:** `ValueError: Expected singleton: product.product()` After [this commit], when opening the shop page, it calculates the quick add availability [1] for every product. It checks whether the product is sold out [2] to determine whether the quick add to cart button should be displayed or not. Since the product has no variants, it raises the error here [3]. Before 19.0, the quick add availability was calculated if the product had variants [4]. This commit ensures that if a product has no variants, it is treated as sold out. As a result, the quick add to cart button is not shown, as in the previous version. [this commit]: https://github.com/odoo/odoo/commit/43d5226b500d64c3902eb1528e5d8e461766982c [1]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L35-L39 [2]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L33 [3]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_product.py#L41 [4]: https://github.com/odoo/odoo/blob/18d9baa690d6b103fbf8dbe875b3e00b056dd873/addons/website_sale/views/templates.xml#L400-L403 sentry-7287364112 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250373
This update fixes a bug related to member removal confirmation messages and ensures that archived users cannot perform member removal actions. It improves the user experience by providing clearer notifications and enhances security by restricting access for inactive users. This change was part of a larger effort to improve stability and security.
Original PR description
*=im_livechat, test_discuss_full Purpose the commit: - To update the string the member removal confirmation dialog. - Restrict the actions usage for archived users. task-5944930 part of-5867464 Forward-Port-Of: odoo/odoo#248998
This update fixes a visual issue on the mobile POS tablet where the pill selection popup was positioned incorrectly, leading to a confusing user experience. The change adjusts the popup's starting position to the bottom of the screen, resulting in a cleaner and more intuitive interface for tablet users. This ensures a consistent and user-friendly experience.
Original PR description
Small modification of the pills selection popup in order to make it starting at the bottom of the screen and not with a fixed size, which caused in certain cases, weird UI. task: 5952769 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue preventing the Quote Builder from generating PDF quotes correctly. The change ensures compatibility with a newer version of the PDF library, specifically addressing a requirement for 'Fields' within AcroForm structures. This ensures Quote Builder continues to function as expected.
Original PR description
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall…
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0) 2- Enable Quote Builder. 3- Create a SO and in quite builder tab, select a document. 4- Print -> PDF Quote. This will lead to traceback. Cause: --- There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be supported in future. Instead we use pypdf==5.4.0. In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0): https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061 FIX: --- We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`: https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370 Note: --- In this fix, we replace `is_upper_version_pypdf2` with specific version comparison. To be precise `getNumPages` is depreciated in version 1.28.0 [2]. References: --- [1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0 [2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514 opw-5784464 Forward-Port-Of: odoo/odoo#250329
This update enhances the clarity of Odoo's server logs during data imports. Previously, it was difficult to quickly determine if an import was a dry run or a real import, or which specific model the data was being loaded into. This change makes it easier for support teams to investigate issues and resolve import problems efficiently.
Original PR description
When investigating support tickets (and the server logs), it is not always clear if: 1) The `info`` log from base_import refers to a dry run or a "real" import 2) The "done" log does not explicitly specify which model the data was imported to While an experienced user can still extrapolate what happened by the immediate context of the preceding/following log lines, it makes it unnecessary difficult to see at first glance where the data was imported to. This PR aims at rectifying it to improve the quality of life of people investigating the server logs. OPW-5999195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252783 Forward-Port-Of: odoo/odoo#252734
This update fixes a test failure related to live chat operator access. The system now correctly handles operator assignments, ensuring the test accurately validates description edit permissions. This change improves the reliability of our live chat functionality.
Original PR description
this PR is resolving [runbot error](https://runbot.odoo.com/odoo/runbot.build.error/241727) due to **/get_session** now creates the assigned operator as a channel member, so the previous non-member assertion became invalid and could fail depending on operator assignment. The test now uses a distinct livechat operator added after session creation to keep validating description edit access without relying on outdated membership assumptions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252736
This update resolves a technical problem where screenshots of spreadsheets were sometimes failing due to the spreadsheet being unexpectedly closed. The fix ensures that thumbnails are consistently saved, improving the reliability of spreadsheet sharing and reducing potential data loss. This was a priority fix to maintain a stable user experience.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update fixes an issue where POS receipts displayed duplicate company names and incorrectly showed the company name instead of the POS configuration name. The change ensures receipts now accurately display the POS configuration name once, improving the clarity and professionalism of customer receipts.
Original PR description
Before this commit: =================== The POS receipt displayed the company name twice, resulting in duplicated company information. Additionally, the company name was shown instead of the PoS config name. After this commit: ================== The receipt now correctly displays the POS config name only once. Duplicate company information has been removed to ensure a clean and accurate receipt layout. Task-5951599
This update fixes a technical issue preventing module overrides (like those in HR) from correctly updating VoIP contact status information. The change ensures VoIP data aligns with Odoo's extensibility standards, maintaining consistency between the real system and test environments. This improves the reliability of VoIP integrations.
Original PR description
`_store_voip_fields` was directly adding `"im_status"` to the stored partner fields. This bypassed `_store_im_status_fields`, so module overrides (notably HR-related ones) could not extend/adjust the IM status payload. Use `_store_im_status_fields(res)` from `_store_voip_fields` instead of hardcoding `"im_status"`. Also align the VoIP mock server `res.partner` contact payload with the real store payload by including the same contact fields and IM status data (`partner_share`, `im_status`, `im_status_access_token`, etc.). This keeps VoIP aligned with the extensibility contract and keeps tests on the same data shape as runtime. [H>A]
This update resolves an issue where the point-of-sale search feature wasn't consistently working due to a timing problem with updating the search input. A small delay has been added to ensure the search input is properly updated before triggering the search, guaranteeing accurate database lookups. This improves the reliability of the search function.
Original PR description
In some test, we try to search the database for a partner through the partner_list. To do this, we edit the partner_list input and trigger an "Enter" event. In some case, the value is not set to the state of the partner_list before we dispatch the event and result in no search in the database being done. This is partly due to the debounce of the input before setting the state of the partner list and due to some method running asynchronously every method triggered by the insertion of text. To fix this, we add a little sleep in the tour (200ms) to ensure that the state of the component is well updated before triggering the event. runbot-error: 238511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent issue prevented the automated update of POS price tags. This fix removes an outdated argument from the scheduled process, resolving a technical error that was disrupting the tag synchronization. This ensures the POS Pricer module functions correctly without interruption.
Original PR description
Currently, an error occurs when the scheduled action "POS Pricer: Tags Update Synchronization" runs. **Steps to Reproduce:** - Install the `pos_pricer` module. - Go to `Scheduled Actions` and run…
Currently, an error occurs when the scheduled action "POS Pricer: Tags Update Synchronization" runs.
**Steps to Reproduce:**
- Install the `pos_pricer` module.
- Go to `Scheduled Actions` and run `"POS Pricer: Tags Update Synchronization"`.
**Error:**
`
ValueError: TypeError("PricerStore._update_pricer_tags() got an unexpected keyword argument 'update_all'") while evaluating 'model.search(([("pricer_tag_ids", "!=", False)]))._update_pricer_tags(update_all=False)'`
This error occurs because, after this [recent commit], `_update_pricer_tags` was changed to
no longer accept the `update_all` argument and now relies on the `needs_pricer_update` instead.
However, the scheduled action still passes the `update_all` argument [1], which causes the
error when the cron job runs.
This commit removes the unexpected `update_all` argument from the tag update synchronization cron.
[recent commit]: https://github.com/odoo/enterprise/commit/166a8a240d0588f4e908ce09c4639da1216ba3b7
[1]- https://github.com/odoo/enterprise/blob/0ef7643bba5b3fa3d22ab122ef3b65f0d67c8fb7/pos_pricer/data/pricer_ir_cron.xml#L9
sentry-7324339777This update fixes a temporary issue that prevented a helpful training tour for restaurant staff within the Odoo POS system. The tour has been re-enabled with added checks to ensure order synchronization, particularly after printer errors, improving the user experience and training process.
Original PR description
In this commit: --- - Re-enable `test_course_restaurant_preparation_tour`, which was previously disabled to allow merging during freeze. - Add steps to ensure the order is properly synchronized. task-5958387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update caused crashes when creating YouTube posts in Odoo Enterprise. This fix removes an outdated dependency within the social_youtube module, resolving the crash. The change ensures stable saving of YouTube posts without impacting core functionality.
Original PR description
Bug: Following recent changes introduced in saas-19.2, creating and saving a YouTube post causes the flow to crash. Cause: A refactoring in the social module removed the `utm.source.mixin` dependency from the `social_post` model. This consequently removed the `name` attribute from the model. However, `social_youtube` still expected this attribute to exist, triggering the crash. Solution: Remove all references to the `name` attribute within the `social_youtube` module. We opted not to reintroduce the attribute on the model because it did not add significant functionality and has been superseded by other attributes.
This update fixes a minor issue where a warning about leaving a chatbot conversation was displayed even when the conversation was already closed. Now, the warning only appears when a chatbot conversation is actively in progress, providing a smoother and less disruptive user experience. This change ensures users aren't unnecessarily alerted about finished chats.
Original PR description
Before this commit: When a user finishes a chatbot script and the conversation is already ended, clicking on close / continue still triggers the leave conversation warning. After this commit: The leave conversation warning is no longer shown when the chatbot conversation is already closed or ended. The warning is only shown for active conversations. [Task-5882084](https://www.odoo.com/odoo/project/1519/tasks/5882084) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252750 Forward-Port-Of: odoo/odoo#247918
8 changes
Resolved issues and error corrections
This update corrects a bug where the VAT (Tax ID) was not appearing in document previews. The fix adds the necessary code to properly display the company's VAT information when generating invoices and preview documents. This ensures accurate and complete financial documents.
Original PR description
Steps to reproduce 1. Install `account`. 2. Go to Settings → Configure Document Layout. 3. Enter a value in the Tax ID field. 4. Generate a document (invoice / preview document). Issue Unlike other fields in the document layout, the `Tax ID` value is not updated and does not appear in the document preview. Cause The VAT (Tax ID) rendering logic was missing from the document layout template XML. Solution Add proper logic to display the Tax ID using the company VAT Before: <img width="1089" height="750" alt="image" src="https://github.com/user-attachments/assets/8d27808f-d605-447c-807a-d5f3450eef36" /> After: <img width="1080" height="722" alt="image" src="https://github.com/user-attachments/assets/0af04d77-a318-4e39-9a4b-0911f2446e60" /> opw-5373374 Related Enterprise PR : https://github.com/odoo/enterprise/pull/109924 Forward-Port-Of: odoo/odoo#247087 Forward-Port-Of: odoo/odoo#240234
A recent update to Odoo Enterprise's document layout, including VAT information, caused a test to fail. This fix addresses a problem where the test's editor selection wasn't correctly updated after adding the VAT block, preventing a key feature from functioning. The update ensures the test now passes, maintaining accurate VAT display.
Original PR description
Issue The test `test_edit_header_only_company` was failing after updating the document layout to include the VAT block in the company address section. Cause Adding the VAT line modified the DOM structure of the header layout. The tour step inserting the placeholder span no longer correctly set the editor selection, preventing the powerbox from opening and causing the test to fail. Solution Update the tour to explicitly reset the editor selection after inserting the span so that the powerbox can open correctly. opw-5373374 Related Community PR : https://github.com/odoo/odoo/pull/249225
This update improves the Knowledge app by automatically moving linked articles to the trash when an audit report is deleted. This prevents workspaces from becoming cluttered and reduces confusion about article relevance, leading to a cleaner and more organized user experience.
Original PR description
When a user deletes an audit report, the articles linked to that report currently remain visible in the Knowledge app. This can lead to cluttered workspaces and confusion about which articles are still relevant. To keep workspaces clean, these linked articles will now be automatically moved to the trash when the audit report is deleted. Task-5902448 Forward-Port-Of: odoo/enterprise#101234
This update resolves an issue where empty options were being saved and displayed in dropdown selectors within website forms. The fix ensures that empty 'Selection' fields are now automatically removed before saving, improving the user experience and data consistency. This was caused by a previous change affecting how form custom field values were handled.
Original PR description
**Description of the problem** Before this commit, the user could entry empty many2one options in a form, and these would be saved and displayed in the website as empty entries in a dropdown…
**Description of the problem** Before this commit, the user could entry empty many2one options in a form, and these would be saved and displayed in the website as empty entries in a dropdown selector. **How to reproduce the problem** 1. Drop a form 2. Add a "Selection" field (many2one) 3. Clear the text in one of the options in "Option List" 4. Save 5. The empty option is not removed, and shows up in the dropdown selector **Why the problem happens** Commit [1] introduced some changes to the action `SetFormCustomFieldValueListAction`, as a result, empty many2one options are not dropped anymore on apply. **Solution** The solution is applied on `BuilderList` (not only forms), as required by the task. `BuilderList.handleValueChange` now drops empty text fields before commiting changes, unless this violates `props.forbidLastItemRemoval`. The form action `setFormCustomFieldValueList` is changed such that the last entry is never removed even if its text is empty (unless `props.forbidLastItemRemoval` is false). task-5925171 [1]: https://github.com/odoo/odoo/commit/cb8469e9fe73f5c10b4e49d3462e0b23df2a047d
This update fixes an issue where sign requests generated from HR wizards didn't automatically use the expiration dates defined on the sign templates. Now, all sign requests will adhere to the template's configured validity period, ensuring accurate tracking and preventing outdated requests.
Original PR description
Before, when sending sign requests from the HR custom wizards, the validity date defined on the sign template was not applied to the generated signature requests. As a result, requests were created without respecting the template’s configured expiration. task-5928110 Forward-Port-Of: odoo/enterprise#107076
This update enhances the clarity of Odoo server logs related to data imports. Previously, it was difficult to quickly determine if an import was a dry run or a real import, or to see which specific model the data was imported into. This change makes it easier for support teams to investigate issues and improve the overall efficiency of data import troubleshooting.
Original PR description
When investigating support tickets (and the server logs), it is not always clear if: 1) The `info`` log from base_import refers to a dry run or a "real" import 2) The "done" log does not explicitly specify which model the data was imported to While an experienced user can still extrapolate what happened by the immediate context of the preceding/following log lines, it makes it unnecessary difficult to see at first glance where the data was imported to. This PR aims at rectifying it to improve the quality of life of people investigating the server logs. OPW-5999195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252783 Forward-Port-Of: odoo/odoo#252734
This update resolves a technical error that occurred when processing refunds in the Spanish Point of Sale (POS) module. Specifically, a 'singleton error' was triggered due to incorrect data being passed during refund operations. The fix ensures the correct order ID is used, preventing the error and ensuring refunds are processed smoothly.
Original PR description
Step to reproduce: - install l10n_es_pos - create a pos, open its setting and set its `Simplified Invoice` with a journal - start pos, create a order and refund it Observation: - we receive a singleton error for account.move Cause: - when calling `get_invoice_name` method, we pass `order_server_ids` which contains order and refund order id, hence two ids are passed Fix: - instead of using `order_server_ids` we use 'order.id' i.e. current order opw-5870707 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251519 Forward-Port-Of: odoo/odoo#247986
This update resolves an issue where the system incorrectly interpreted date columns in import files. Specifically, it fixed a bug where date formats like '2500/1222' were wrongly identified as '%Y.%m.%d'. This ensures that import files with various date formats are now processed accurately, preventing import errors and improving data reliability.
Original PR description
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)…
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)  First column: Client ref Second column: committment date Third column: Customer ## Current behavior before PR: When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d format . This is an error because that column does not contain a date . The reason is that check_patterns when convert the pattern to reg ex using `def to_re(pattern):` on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex . ## Desired behavior after PR is merged: No error should appear and the correct date format from the right date column should be guessed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252488 Forward-Port-Of: odoo/odoo#196477
7 changes
Resolved issues and error corrections
This update corrects a previous issue where users with the invoicing & banks role couldn't access certain transaction views. The change ensures these users have the necessary permissions to view duplicate and missing transactions, aligning with recent improvements in Odoo 19.0. This ensures consistent functionality for key user groups.
Original PR description
In 19.0 we made a fix to allow users with the invoicing & banks role, to have access to duplicate transaction and missing transaction. https://github.com/odoo/enterprise/commit/748660f7ad9ca30d59f00e69d42a24864f1764d3 https://github.com/odoo/enterprise/commit/6edc057a9c0459af2b6d625415b700daf6280520 This commit will allow user with that role to access those menus task-5998895 Forward-Port-Of: odoo/enterprise#109941
This update resolves a technical problem that occasionally prevented the spreadsheet edition from saving thumbnails correctly. The issue stemmed from a race condition where the spreadsheet was unexpectedly closed during the thumbnail capture process, causing errors. This fix ensures thumbnails are reliably saved for spreadsheets.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update resolves an issue where documents couldn't be opened after their names were changed. The fix corrects a technical error in the document management system related to how attachments were handled. This ensures documents can now be reliably opened and used after a name change.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Open a document in full screen and click on info icon on top right 3. Edit the name and close full screen document and chatter 4. Try to open the same document Issue: - Traceback occures `TypeError: Cannot read properties of undefined (reading 'insert')` Cause: - In file document_service `this.store.Attachment` was used instead of `this.store["ir.attachment"]` After this commit https://github.com/odoo/odoo/commit/70153559c34ffd18c67b83c39ee397ecb0a90b4a we renamed the Attachment model opw-5483625 Forward-Port-Of: odoo/enterprise#109567 Forward-Port-Of: odoo/enterprise#105602
A previous shortcut conflict in the asset management module caused users to incorrectly navigate to the Posted Entries view instead of the previous asset. This update resolves this issue by changing the shortcut to ALT + SHIFT + P, aligning with existing shortcuts and improving usability.
Original PR description
# How to reproduce - Have atleast two assets - Go to the last asset - Type ALT + P on your keyboard # The problem We enter the Posted Entries view instead of going to the previous asset # Why This PR (https://github.com/odoo/enterprise/pull/67840) added shortcuts to the asset form view, but used ALT + P for the Posted Entries. This shortcut is already used on all form views for the "previous page" button. After consulting with the developer of the original PR, we decided to move the Posted Entries shortcut to ALT + SHIFT + P opw-5948523 Forward-Port-Of: odoo/enterprise#109022
This update corrects a bug where users without HR document centralization enabled were seeing all documents, not just their own employee documents, when using the 'documents' smart button. The fix restores the intended behavior for companies without this HR setting, ensuring employees only access their own files.
Original PR description
Steps: - uncheck the "Human Resources" file centralization option - go to an employee, click the documents smart button -> You see every documents, not only the ones from the employee PR https://github.com/odoo/enterprise/pull/93782 aimed at restoring the previous behaviour of the employee documents button and accesses for companies without the hr documents settings enabled, but forgot the domain on the employee smartbutton action. opw-5857914 Forward-Port-Of: odoo/enterprise#107224
This update resolves an issue where users were unable to set both a start and end date simultaneously within the web_studio feature. The fix prevents the creation of invalid date range fields, ensuring data consistency and a smoother user experience when configuring forms and workflows. This improves the reliability of the studio interface.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a bug preventing the 'group payment' button from appearing when multiple bills were selected has been resolved. This ensures accurate payment tracking and a smoother user experience.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#106894
19 changes
Resolved issues and error corrections
This update resolves an issue where the HTML editor wasn't accurately reflecting changes made by users. Previously, multiple edits could occur before the field was correctly marked as dirty, preventing users from seeing updates. This fix ensures that the HTML editor accurately tracks changes and updates the FormStatusIndicator correctly.
Original PR description
Prior to this commit, it was possible to: - make change A inside a html_field - save/commitChanges - make change B inside the html_field, before the end of the save/commitChanges - the field ends up incorrectly marked as "not dirty" (user can't use the FormStatusIndicator) even though change B was not committed yet. Solution: Give an id to the dirtiness, and associate that id with an extracted value from the editor. When the record update is done, mark the field as not dirty ONLY IF the current dirty id is the same as the id previously associated with the extracted value, else the field stays dirty. task-5976348 Forward-Port-Of: odoo/odoo#252655
This update resolves an issue preventing barcode scanning of product packaging when a product doesn't have a barcode defined. The fix ensures that the system now searches for the product when a barcode is scanned on packaging, allowing for seamless barcode scanning functionality within the Point of Sale module. This improves the user experience and accuracy of sales transactions.
Original PR description
Step to reproduce - Create a product - Add two attributes: 1. One with Instantly creation mode 2. One with Never creation mode - Define packaging from the Sales tab - Add a barcode on the variant packaging ex: 111356,11357 - Scan the packaging barcode in POS Observation: - we get a traceback `TypeError: Cannot read properties of undefined (reading 'product_template_attribute_value_ids')` Cause: - when we do not have barcode on product, when opening `openConfigurator` - (as we have few varianst) product get undefined. https://github.com/odoo/odoo/blob/f229f23d7bf3d837ff5577c36145bf2ba410ea22/addons/point_of_sale/static/src/app/services/pos_store.js#L738 - Hence the traceback Fix: - For the case, when packaging has barcode but not the product, we search for product in that case too. opw-5886570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248838
This update fixes an issue where refund payments in Point of Sale were incorrectly created as 'inbound' instead of 'outbound'. When processing refunds with the 'Identify Customer on the Card' payment method, this change ensures accurate payment record creation, improving financial reporting and reconciliation within the invoicing system. The fix was implemented to address a specific workflow and is considered a minor improvement.
Original PR description
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS…
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS session - Go to Invoicing → Customers → Payments Observation: - Two payment records are created - Both payments have payment_type = inbound - The refund payment should be outbound Cause: - When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records - The method does not adjust payment_type for refund transactions Fix: - Add helpers to swap destination and outstanding accounts - Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority - Ensure refund payments are created as `outbound` few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228 https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8 opw-5437456 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247760
This update enhances the clarity of Odoo's server logs during data imports. Previously, it was difficult to quickly determine if an import was a dry run or a real import, or to see which model the data was imported into. This change makes it easier for support teams to investigate issues and improve the overall efficiency of data import troubleshooting.
Original PR description
When investigating support tickets (and the server logs), it is not always clear if: 1) The `info`` log from base_import refers to a dry run or a "real" import 2) The "done" log does not explicitly specify which model the data was imported to While an experienced user can still extrapolate what happened by the immediate context of the preceding/following log lines, it makes it unnecessary difficult to see at first glance where the data was imported to. This PR aims at rectifying it to improve the quality of life of people investigating the server logs. OPW-5999195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252783 Forward-Port-Of: odoo/odoo#252734
This update resolves an issue where the system incorrectly interpreted date columns in import files. Specifically, it fixed a problem where date formats like '2500/1222' were mistakenly identified as '%Y.%m.%d'. This ensures that import files with various date formats are processed accurately, preventing import errors and data inconsistencies.
Original PR description
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)…
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)  First column: Client ref Second column: committment date Third column: Customer ## Current behavior before PR: When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d format . This is an error because that column does not contain a date . The reason is that check_patterns when convert the pattern to reg ex using `def to_re(pattern):` on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex . ## Desired behavior after PR is merged: No error should appear and the correct date format from the right date column should be guessed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252488 Forward-Port-Of: odoo/odoo#196477
This update corrects a bug that caused incorrect currency conversions during batch payment reconciliation in foreign currency journals. Specifically, when reconciling bank statements, the system was using the wrong currency for calculations, leading to inaccurate balances. This fix ensures accurate currency conversions for a more reliable reconciliation process.
Original PR description
When reconciling a batch payment in a foreign currency journal where payments do not have outstanding accounts, the resulting bank statement lines could use the wrong currency for balance conversion. Steps to reproduce: - Create a journal in a foreign currency (e.g., CHF) - Create two invoices in company currency (e.g., EUR) - Pay both invoices using the foreign journal - Create a batch payment for these payments. - Reconcile a bank statement line against this batch payment. Issue: Reconciliation make use of the payments amount in the wrong currency. Analysis: During the reconciliation of a batch payment, the system creates new amls from the payment values. However, the currency of the computed amount should be the source payment currency, and not the invoice line currency. opw-5887218
This update resolves an issue in the Odoo Report Editor where certain field types were not correctly supported. The change prevents users from attempting to select fields with properties through the /field command, aligning with how properties are handled in other report elements. This ensures more reliable report generation.
Original PR description
Properties are not supported in ir.qweb but only as t-out, while t-field doesn't support them. For this reason and the fact that properties have a path the model field selector barely handles we do not allow those field to be selected in the /field command task-5999790
This update fixes an issue where selecting an office on the Jobs page would remove the previously applied country filter. The fix ensures that country filters remain active and functional when users select offices, improving the user experience for job searches. This change was made to ensure accurate filtering results.
Original PR description
Steps to reproduce: =================== 1. Navigate to the Jobs page. 2. Filter a specific country 3. Select all offices -> The country filter will be removed Cause: ====== the "All Offices" link inside job_filter_by_offices, the href uses 'all_countries=1' if is_remote else current_country_path but current_country_path is not defined anywhere Solution: ========= Switch to current_country_param Note: ===== The fix will be adapted in later versions opw-5947819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252477
This update resolves an issue that occurred when users attempted to remove a company association from an expense record. The fix ensures the system handles company removal gracefully, preventing a technical error that could disrupt expense management. This improves the reliability of the expense tracking process.
Original PR description
Currently an error occurs when user tries to remove company on an expense. Steps to replicate: - Install `hr_expense` and create a new company. (make sure you have more than one company). - Create new expense and remove the value from company field. Error: `ValueError: Compute method failed to assign hr.expense(<NewId origin=7>,).is_editable` Cause: - Removing the company triggers the [compute] that skips the loop if company is not assigned [1], which causes this error. Solution: - Assign `is_editable` as False when company is false. [compute]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L304-L363 [1]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L326-L331 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241507
This update resolves an issue where changing the note on a food item after a quantity update would cause an error. The fix ensures that the note update process works reliably, preventing disruptions in order management within the POS system. This improves the overall user experience for restaurant staff.
Original PR description
**Steps to Reproduce:** - Install `pos_restaurant_preparation_display`. - Open Register for POS "**Restaurant**" Shop. - Choose table > select food-item > send the order. - Update food-item quantity > send the updated order. - Update food-item '**Kitchen Note**' > send the note. **Error:** `TypeError - 'NoneType' object is not subscriptable` **Cause:** When the food quantity is updated, a new preparation entry is created for the increased quantity. During the first iteration, the display and order quantities are already merged correctly. However, in a subsequent iteration, the original key no longer exists in `quantity_data`. As a result, accessing a None value leads to a traceback. **Fix:** This commit skips the merge step when the original quantity entry has already been merged. sentry-7197024946 Forward-Port-Of: odoo/enterprise#104889
This update resolves an issue where Odoo invoices for Danish customers were incorrectly formatted according to Peppol standards. The change skips adding redundant information to ensure compliance with regulations, preventing invoice submission errors. This ensures seamless integration with Peppol networks for Danish businesses.
Original PR description
Currently, if a Danish partner has a reference set, Odoo adds it under PartyIdentification. This violates Peppol `DK-R-013`, which mandates using schemeID when PartyIdentification is used. Adding the Danish schemeID would also trigger another error, `PEPPOL-COMMON-R042`, as the organization number (CVR) must be included in the `_text`. Including schemeID seem therefore unnecessary since it will appear in CompanyID. Steps to reproduce: - Create a Danish company and enable Peppol - Create a Danish customer with a reference - Create an invoice and submit to Peppol, `DK-R-013` error occurs opw-5921602 Forward-Port-Of: odoo/odoo#251737
This update removes an unnecessary check for local network connectivity when opening cashboxes via IoT. Because Stable IoT Boxes are now reachable through a websocket, this redundant step has been removed, streamlining the process. This change improves the reliability of cashbox operations.
Original PR description
Stable IoT Boxes can be reached using websocket, so it doesn't make sense to check the connectivity on local network before sending the "open cashbox" action. We then removed this check. Forward-Port-Of: odoo/enterprise#107397
This update fixes an issue where sandwich leave durations were incorrectly calculated when public holidays were involved. The fix ensures that all date calculations are properly localized to the company's timezone, guaranteeing accurate leave duration calculations for employees. This improves the reliability of leave management.
Original PR description
Steps to Reproduce: 1. Install the `l10n_in_hr_holidays` module. 2. Enable the "sandwich leave" option for the time off type. 3. Create public holidays that last the entire day, for example from 00:00 to 23:59. 4. Create a leave around the public holiday 5. Duration should be 3 days instead of 1 Cause: When creating a dictionary for company-specific public holidays, the dates from and to are not converted to the company's timezone when calculating the days between public holidays. Fix: To resolve this, the first step is to localize the `date_from` and `date_to` to the company's timezone before counting the days between the public holidays. Task-6012992 Forward-Port-Of: odoo/odoo#252466
A recent issue causing Distro builds to fail during the quality control tour has been resolved. The fix increases a delay in the tour process to ensure backend operations complete before the user interface updates, preventing UI elements from disappearing during the test. This improves the reliability of our automated testing environment.
Original PR description
Distro builds was failing with:
```js
FAILED: [8/14] Tour test_quality_check_packages_lots_tour →
Step .o_line_button.o_toggle_sublines
{
'trigger': '.o_line_button.o_toggle_sublines',
'run': 'click'
},
```
- This issue occurs due to a timing race condition in the barcode client action.
After scanning lots and clicking Put in Pack, backend calls are
still processing (updating move lines and packages) while the frontend re-renders the UI,
the tour continued before these operations were fully completed,
so the `.o_toggle_sublines` button was not yet available in the DOM.
This caused intermittent failures, mainly in slower CI environments like Distro builds/runbot.
- To fix this, the tour step_delay has been increased from 100 to 300,
giving enough time for backend processing and UI rendering
to complete before executing the next step.
---
runbot error:238452
Forward-Port-Of: odoo/enterprise#107766This update resolves an issue where users could incorrectly set both a start and end date simultaneously within the web_studio interface, leading to a validation error. The fix prevents this conflicting input, ensuring date range fields function as expected and improving data accuracy. This change impacts the usability of date-based fields in project configurations.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
This update resolves an issue where incoming emails with attachments using the 'bin/plain' MIME type would cause the system to crash. The fix now gracefully handles this attachment type by converting it to a standard format, ensuring all emails are processed correctly and preventing disruptions to vendor bill creation.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (specifically, 2 payments instead of 4). This change improves the user experience by providing accurate information about the payment schedule. Additionally, the 'group payment' button is now correctly hidden when necessary.
Original PR description
[FIX] account: right number of payments skipped in send wizard Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/odoo#247830
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a bug preventing the 'group payment' button from appearing under certain circumstances has been resolved. This ensures accurate payment tracking and a smoother user experience.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#106894
This update fixes a bug in how scrap quantities are calculated for products. Previously, if a product didn't have a related Bill of Materials, the calculation would stop, leading to incorrect scrap quantities being reported. Now, all products are correctly processed, ensuring accurate scrap tracking.
Original PR description
### Description of the issue/feature this PR addresses: The `_compute_scrap_qty` method in **mrp/models/stock_scrap.py** exits early with return when a record has no BOM, preventing the computation of `scrap_qty` for remaining records in the recordset. ### Current behavior before PR: When iterating over a multi-record recordset, if any record lacks a `bom_id`, the method does return `super(...)._compute_scrap_qty()`, which exits the entire loop. Records after that one are never computed and keep the default value of 1. ### Desired behavior after PR is merged: Records without a `bom_id` delegate to `super()._compute_scrap_qty()` and the loop continues (continue) to the next record, ensuring all records in the recordset are properly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252149
4 changes
Resolved issues and error corrections
This update fixes a bug that caused renewed subscriptions to be incorrectly marked as churned. The issue stemmed from a race condition during the automated subscription expiration process. The fix ensures that subscriptions are only processed when their status is still active, preventing this error and maintaining accurate subscription records.
Original PR description
Steps to reproduce: - Have a subscription ready to expire/auto-close. - Trigger the `_cron_subscription_expiration` cron. - While the cron is processing earlier batches, manually renew the subscription. - The renewed subscription is incorrectly marked as closed/churned. Cause: The cron searches for all expired/unpaid subscriptions at the very beginning and processes them in batches of 30. If a subscription is renewed concurrently (Race condition), its ID is already in the `subscriptions_close` list, causing the cron to close it regardless of its new state. Solution: Inside the batch processing loop, consider only subscriptions that are strictly still in `SUBSCRIPTION_PROGRESS_STATE`. Task: 5929077 Forward-Port-Of: odoo/enterprise#107157
This update resolves an issue where changing the 'Kitchen Note' on a POS order after a quantity update would cause an error. The fix ensures that the note update process works reliably, regardless of previous quantity changes, preventing order processing disruptions.
Original PR description
**Steps to Reproduce:** - Install `pos_restaurant_preparation_display`. - Open Register for POS "**Restaurant**" Shop. - Choose table > select food-item > send the order. - Update food-item quantity > send the updated order. - Update food-item '**Kitchen Note**' > send the note. **Error:** `TypeError - 'NoneType' object is not subscriptable` **Cause:** When the food quantity is updated, a new preparation entry is created for the increased quantity. During the first iteration, the display and order quantities are already merged correctly. However, in a subsequent iteration, the original key no longer exists in `quantity_data`. As a result, accessing a None value leads to a traceback. **Fix:** This commit skips the merge step when the original quantity entry has already been merged. sentry-7197024946 Forward-Port-Of: odoo/enterprise#104889
A recent issue causing tour tests to fail in our automated build process has been resolved. The fix increases the delay in the tour to ensure backend operations complete before the user interface updates, preventing UI elements from disappearing during the test. This improves the reliability of our automated testing.
Original PR description
Distro builds was failing with:
```js
FAILED: [8/14] Tour test_quality_check_packages_lots_tour →
Step .o_line_button.o_toggle_sublines
{
'trigger': '.o_line_button.o_toggle_sublines',
'run': 'click'
},
```
- This issue occurs due to a timing race condition in the barcode client action.
After scanning lots and clicking Put in Pack, backend calls are
still processing (updating move lines and packages) while the frontend re-renders the UI,
the tour continued before these operations were fully completed,
so the `.o_toggle_sublines` button was not yet available in the DOM.
This caused intermittent failures, mainly in slower CI environments like Distro builds/runbot.
- To fix this, the tour step_delay has been increased from 100 to 300,
giving enough time for backend processing and UI rendering
to complete before executing the next step.
---
runbot error:238452
Forward-Port-Of: odoo/enterprise#107766This update resolves an issue where users were unable to correctly set both a start and end date for date range fields within the Web Studio design tool. The fix prevents the system from accepting both date fields simultaneously, ensuring data integrity and preventing invalid date range configurations. This improves the overall usability of Web Studio for creating date-based views.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
12 changes
Resolved issues and error corrections
This update resolves an issue where renewing a subscription while another renewal process was running would incorrectly mark the subscription as churned. The fix ensures that subscriptions are only processed when their status indicates they should be renewed, preventing this race condition and ensuring accurate subscription management.
Original PR description
Steps to reproduce: - Have a subscription ready to expire/auto-close. - Trigger the `_cron_subscription_expiration` cron. - While the cron is processing earlier batches, manually renew the subscription. - The renewed subscription is incorrectly marked as closed/churned. Cause: The cron searches for all expired/unpaid subscriptions at the very beginning and processes them in batches of 30. If a subscription is renewed concurrently (Race condition), its ID is already in the `subscriptions_close` list, causing the cron to close it regardless of its new state. Solution: Inside the batch processing loop, consider only subscriptions that are strictly still in `SUBSCRIPTION_PROGRESS_STATE`. Task: 5929077 Forward-Port-Of: odoo/enterprise#107157
This update resolves an issue where autofilling pivot formulas in certain scenarios caused errors and incorrect data formatting. The fix ensures that pivot formulas work reliably, preventing crashes and maintaining the intended positional structure within pivot tables. This improves the accuracy and usability of the enterprise reporting feature.
Original PR description
If we autofill a positional pivot formula in the dimension perpendicular to the positional header, it would not work correctly: - We would crash if the position wasn't in the original pivot table - We would drop the positional part otherwise (`"#country_id", 1` would become `"country_id", 25`). Task: [5909266](https://www.odoo.com/web#id=5909266&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109631
This update resolves an issue where printing basic receipts would fail if the point-of-sale (POS) name was too long. The fix limits the receipt name length to 46 characters to prevent a technical error that disrupted the printing process. This ensures basic receipts are always printed correctly.
Original PR description
When printing a basic receipt, if the pos name is too long a traceback will occurs when printing the basic receipt. Steps to reproduce: * Create a pos with a name of 46 character or more * Setup the italian fiscal printer * Enable Basic Receipt printing * Open point of sale * Create an order and validate it * Try "Print Basic receipt" Traceback: RangeError: Invalid count value: -15 at String.repeat () If the data being printed is longer than the maximum number of character in a line (MAX_CHARS = 46), paddingLeft becomes negative which cause an error in repeat(). [Similar solution](https://github.com/odoo/enterprise/blob/18.0/l10n_it_pos/static/src/app/fiscal_printer/commands/print_rec_message/print_rec_message.js#L35) [opw-5270697](https://www.odoo.com/odoo/project/49/tasks/5270697) Forward-Port-Of: odoo/enterprise#109766 Forward-Port-Of: odoo/enterprise#109527
This update fixes an issue where sign requests generated from HR wizards didn't automatically use the expiration dates defined on the sign templates. Now, all sign requests will adhere to the template's configured validity period, ensuring accurate tracking and preventing outdated requests.
Original PR description
Before, when sending sign requests from the HR custom wizards, the validity date defined on the sign template was not applied to the generated signature requests. As a result, requests were created without respecting the template’s configured expiration. task-5928110 Forward-Port-Of: odoo/enterprise#107076
This update clarifies the error message displayed when an incorrect account is linked to the Expense Reimbursement salary rule. The change ensures employees receive clearer guidance on setting up their expense reimbursements correctly, preventing potential payment issues.
Original PR description
. Change the error message to say "The account linked to the salary rule Expense Reimbursement must be payable type." task-5965760
This update resolves a problem where spreadsheet thumbnails sometimes failed to save correctly due to a temporary disconnection during the screenshot process. The fix ensures thumbnails are reliably saved, improving the user experience when creating and sharing spreadsheets. This was a minor stability issue.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update resolves an issue preventing automated tests from correctly opening the POS session. The changes update tour selectors to target the 'Open Register' button and modify the UI rendering to ensure the button is consistently accessible. This improves the reliability of our test automation.
Original PR description
In this commit:
- The POS open UI button is now rendered through a widget and no longer exposes the `name=open_ui` attribute. As a result, the existing tour selectors could not locate the button.
- Update the tour triggers to use `button:contains('Open Register')` so the POS session can still be opened correctly during tests.
Task:5425256
Related PR:
- Community: https://github.com/odoo/odoo/pull/241641
- Upgrade: https://github.com/odoo/upgrade/pull/9205This update resolves an issue preventing correct validation of data properties within the Knowledge and Spreadsheet Edition modules. The fix ensures data integrity and proper functionality for these key features, improving overall system stability.
Original PR description
This commit corrects wrong props validation schema that could not work.
This update fixes a technical issue within Odoo's VoIP system. Previously, the system relied on a single data field for status updates, which created maintenance challenges and lacked crucial information like employee access tokens. This change ensures accurate and complete status updates, improving the reliability of the VoIP feature.
Original PR description
Just reading `im_status` instead of the dedicated method makes the maintenance harder and it is potentially problematic as it doesn't return the `im_status_access_token` nor the necessary extra information from employee records to compute out of office. https://github.com/odoo/odoo/pull/252008
This update resolves a minor visual issue in the Helpdesk module related to the 'Rotting days' field. The change improves the field's appearance and usability by applying a standard UI element. This ensures a consistent and polished user experience for Helpdesk users.
Original PR description
This commit fixes the UI of the 'Rotting days' field, by wrapping it in a o_input_box div and using the o_input_box_overlay_end and the o_input_box_overlay_inline classnames. task-6025631
This update removes a temporary flag from the account reports tour, signifying that it is now fully functional and reliable. This ensures users can consistently access and utilize the tour without encountering unexpected issues. The change improves the overall stability of the account reporting feature.
Original PR description
This commit removes the 'undeterministicTour_doNotCopy' flag from the 'account_reports_sections' tour. This indicates that the tour is now stable.
This update removes a temporary flag from the account reporting audit tour, signifying that it is now reliably functional. This ensures consistent and accurate reporting processes for users. The change improves stability and reduces potential issues with the audit tour.
Original PR description
This commit removes the 'undeterministicTour_doNotCopy' flag from the 'account_reports_audit' tour. This indicates that the tour is now stable.
9 changes
Resolved issues and error corrections
This update corrects an access error that prevented users with basic inventory permissions from creating deliveries with stock moves. The change ensures that access controls are properly enforced, preventing errors when saving new delivery records. This improves usability for users with limited access.
Original PR description
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld…
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld stock.move.l10n_uy_edi_addenda_ids This flow is tested by the `test_basic_stock_flow_with_minimal_access_rights` test after installing the `l10n_uy_edi_stock` module. Cause of the issue: Since [19.0](https://github.com/odoo/odoo/commit/4a822785ca850c7ae5b21039536333276b2c61af) the read access right of the comodel is checked when writing on a many2many field. However, only the `account.group_account_invoice` does have read access on the `l10n_uy_edi.addenda` model: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/security/ir.model.access.csv#L2 This is problematic as the `l10n_uy_edi_addenda_ids` field is added to the view even for users without read access rights on the comodel: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/views/account_move_views.xml#L43-L53 Even if the field is invisible it is now part of the fields checked by the onchange and the values saved by the picking `web_save`. In particular, creating a new picking from the form view and saving the record will try to write an `[]` value on the `stock.picking` `l10n_uy_edi_addenda_ids` field and trigger the access error. runbot-240937
This update corrects a bug that prevented the creation of 'Cash Supplement' cash moves in German POS systems. The original code incorrectly capitalized the type, leading to an error from the Fiskaly accounting system. Now, the correct casing is maintained, ensuring proper cash move processing.
Original PR description
When creating a cash move of type "Cash Supplement", the type sent was "Zuschussecht" instead of "ZuschussEcht", which caused is not an allowed type. Steps to reproduce: ------------------- * Setup a PoS with a TSS for a German localization * Start a session and open the cash control popup * Create a cash move of type "Cash Supplement" * Close the session > Observation: You get an error from Fiskaly that the type is not allowed Why the fix: ------------ When doing `.capitalize()` on a string it would make the first letter uppercase and the rest lowercase. In this case "ZuschussEcht" would become "Zuschussecht", which is not the correct type expected by Fiskaly We now keep the original casing for all the type. opw-5462364
This update fixes a bug where renewing a subscription while another process was closing it would incorrectly mark the subscription as churned. The change ensures the renewal process doesn't interfere with the subscription expiration process, preventing errors and maintaining accurate subscription status.
Original PR description
Steps to reproduce: - Have a subscription ready to expire/auto-close. - Trigger the `_cron_subscription_expiration` cron. - While the cron is processing earlier batches, manually renew the subscription. - The renewed subscription is incorrectly marked as closed/churned. Cause: The cron searches for all expired/unpaid subscriptions at the very beginning and processes them in batches of 30. If a subscription is renewed concurrently (Race condition), its ID is already in the `subscriptions_close` list, causing the cron to close it regardless of its new state. Solution: Inside the batch processing loop, consider only subscriptions that are strictly still in `SUBSCRIPTION_PROGRESS_STATE`. Task: 5929077 Forward-Port-Of: odoo/enterprise#107157
This update fixes a bug where the 'Reset' button was missing from Spanish informational reports. This was caused by a recent configuration change that made the standard reset button invisible. The fix adds a specific reset button for these reports, ensuring users can properly clear and regenerate them.
Original PR description
- The `Reset` button was missing from the dropdown menu for Spanish informational reports (Mod 130, 347, 349, 390). - This occurred because these reports were recently configured with `is_tax_return_type = False` in this [commit](https://github.com/odoo/enterprise/commit/d2b1d29542c0350c267fecffd70d3e288364d8ab). However, the standard reset button (`action_reset_tax_return_common`) is configured to be invisible when `is_tax_return` is false. - This fix adds a reset button specifically for these Spanish reports that appears when the report is completed. task-5214023
This update fixes an issue where the SEPA payment wizard incorrectly displayed the number of payments being skipped. The change ensures the warning message accurately reflects that only the first installment of each bill is being paid. Additionally, a visual bug related to the 'group payment' button has been resolved.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#106894
This update resolves an issue preventing power buttons from appearing in Odoo Studio reports. The fix defines necessary configuration within Studio's wysiwyg instance, ensuring correct table menu positioning and functionality. It also addresses a previous bug related to overlay definitions.
Original PR description
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu position calculation when the table cell is inside an iframe. Also Before localOverlayContainers was not defined in studio, so power buttons did not appear in studio reports. Now that localOverlayContainers is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250503 Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724 Forward-Port-Of: odoo/enterprise#109012
This update resolves a problem where Odoo Enterprise spreadsheets could crash when taking screenshots to save as thumbnails. The fix prevents the spreadsheet from being unexpectedly closed during the screenshot process, ensuring thumbnails are consistently saved. This improves spreadsheet reliability and data backup functionality.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update corrects a technical issue preventing electronic invoices under the RIMPE Emprendedor regime from being properly processed. The change ensures the correct string value is used for the invoice type, resolving a validation error related to the invoice's electronic signature. This ensures compliance with Ecuadorian tax regulations.
Original PR description
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:…
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values: CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value) CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE Steps to reproduce: Install l10n_ec_edi module Go to Settings > Invoicing > Ecuadorian Localization In Electronic Invoicing > Regime, select rimpe_emprendedor In Electronic Invoicing > Regime, configure a SRI Connection Post an customer invoice **Validation error occurring during the electronic signing process (using .p12 certificates):** `35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR ` Forward-Port-Of: odoo/enterprise#109147
This update resolves an issue preventing users with the invoicing & banks role in Odoo 19.0 from accessing key transaction management features. The change grants these users the necessary permissions to view and manage duplicate and missing transactions, improving their workflow efficiency. This fix was implemented based on previous commits to ensure proper role-based access control.
Original PR description
In 19.0 we made a fix to allow users with the invoicing & banks role, to have access to duplicate transaction and missing transaction. https://github.com/odoo/enterprise/commit/748660f7ad9ca30d59f00e69d42a24864f1764d3 https://github.com/odoo/enterprise/commit/6edc057a9c0459af2b6d625415b700daf6280520 This commit will allow user with that role to access those menus task-5998895 Forward-Port-Of: odoo/enterprise#109941
8 changes
Resolved issues and error corrections
This update resolves a minor typographical error – the repeated use of 'departement' (French spelling) in English-language parts of the Odoo system. This ensures consistent and accurate labeling within the HR attendance and base modules, improving the overall user experience. The fix was made to address a previously reported issue.
Original PR description
This PR fixes two occurrences of the typo 'departement' (French spelling) in English contexts. One in the search filter name of hr_attendance and another in a help string in the base module. Fixes #202198.
This pull request addresses a minor issue within the MRP (Materials Requirements Planning) module. The fix involves a temporary adjustment to improve functionality, ensuring smoother operation of related processes. This change focuses on internal improvements within the MRP system.
This update fixes a potential error in how Odoo fetches Instagram poll IDs. Previously, attempting to retrieve the ID before a poll was fully published would cause an API error. Now, Odoo checks the poll's status first, and only requests the ID when the poll is successfully published, preventing errors and ensuring reliable poll functionality.
Original PR description
Follow-up to 06256aa02cb92378933edd638259dd725a2d04c1 The Instagram API returns an error if the `ig_id` field is requested while the container is still processing. This commit splits the container status check into two steps: 1. Poll for `status_code` only to determine the current state. 2. If the status is `PUBLISHED`, perform a second request to fetch the `ig_id`. Updated the test mocks to simulate this restriction, ensuring that requesting `ig_id` on a non-published container results in a 400 error to prevent future regressions. opw-5081325
This update fixes an issue where the HTML editor would reset its selection after opening the command palette. The change ensures the current selection is maintained, providing a smoother and more intuitive editing experience. This improves usability and reduces potential frustration for users.
Original PR description
Before this commit: when the whole editable regains the focus, the selection in the editable is reset to the start of it. After this commit: We create a override for hotkey service to open the command palette with an onClose to refocus the editable area without losing the current selection. For the hotkey override, we pass the area option so it's only valid in the editable area. Outside the editable, the command palette is opened in the default way. task-5949705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a confusing error message in the Odoo stock module that previously didn't identify the specific package causing the issue. By adding the package name to the error, users can quickly diagnose and resolve problems, especially during large product transfers. This improves usability and reduces support requests.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249290
This update resolves an issue where emails with attachments using the 'bin/plain' MIME type would cause the system to fail to process them. The fix now handles this attachment type by falling back to a standard format, ensuring all incoming emails, including vendor bill creation, are correctly processed.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This change reverts a recent update that was causing unnecessary complexity in stock management. Previously, multiple stock transfers for the same supply chain were grouped together, streamlining the process for users. This prevents the creation of redundant pickings and reduces manual effort, particularly in scenarios like replenishing warehouses.
Original PR description
This reverts [1]. Let's quote the commit: > - `Observation`: the next transfers for both receipts are merged into a single > transfer, even though both receipts were created manually and not generated > from any common source document like PO/SO. The above behavior was and is the expected one for years and should not suddenly change on stable. Even the tests were protecting the cases but [1] have changed the `assert`. Commit [1] quickly leads to the creation of tickets. For instance, in the mentioned OPW, where the user resupplies a warehouse from another one: he now has several pickings for the same supply chain, which lead to extra work (e.g., printing all the pickings) [1] https://github.com/odoo/odoo/commit/840b42fd2365a652e53d607f38ac78ccb8dd63dc OPW-6011532
This update reverts a previous change that disrupted the initial state of quality control tests. This fix ensures that the tests are functioning correctly, preventing potential issues with product quality checks. The change is related to a previous revert and is tracked under OPW-6011532.
Original PR description
This reverts [1]. It happens because of a revert OC side, cf linked commit. [1] a01d8f0e15de973a94c360c3911e74b768a3aebc OPW-6011532
2 changes
Resolved issues and error corrections
This update resolves an issue where long titles in blog posts, events, and eLearning courses were causing horizontal page overflow and unnecessary scrollbars. The change ensures titles wrap correctly, maintaining readability and a clean user experience. This improves the visual presentation of content across key Odoo modules.
Original PR description
*:website_event, website_slides Before this commit, long titles in blog posts, events, and eLearning courses caused horizontal page overflow with an unnecessary scrollbar. This commit ensures long…
*:website_event, website_slides Before this commit, long titles in blog posts, events, and eLearning courses caused horizontal page overflow with an unnecessary scrollbar. This commit ensures long titles wrap correctly, preventing horizontal scrolling while keeping the text intact. Steps to reproduce the issue: 1. Install blog, events and eLearning modules 2. Add long titles to a blog post, event and course 3. Observe the text overflow causing a horizontal scrollbar | Before | After | | ------------- | ------------- | Blog Module | <img width="1631" height="422" alt="image" src="https://github.com/user-attachments/assets/8faa6e22-ac7a-4b59-9b54-f674978dc931" /> | <img width="1633" height="420" alt="image" src="https://github.com/user-attachments/assets/66a2de39-95e2-4871-827e-4965e571ed33" /> | | <img width="882" height="394" alt="image" src="https://github.com/user-attachments/assets/b807245f-0d84-47b6-a65b-ce0005037c50" /> | <img width="888" height="385" alt="image" src="https://github.com/user-attachments/assets/3c35cd12-08f2-4775-9c4d-d9d6e4555f00" /> | Event Module | <img width="1335" height="398" alt="image" src="https://github.com/user-attachments/assets/7d3af438-58f7-4a56-acd0-46e6dc90fe2a" /> | <img width="981" height="376" alt="image" src="https://github.com/user-attachments/assets/fb419243-4c0d-4c72-97ec-47812f81b378" /> | E-Learning Module | <img width="1534" height="317" alt="image" src="https://github.com/user-attachments/assets/3b03835c-c72b-40fb-bbf0-8fc91d3fafe5" /> | <img width="1423" height="393" alt="image" src="https://github.com/user-attachments/assets/551e332d-25af-453a-bfda-b669b04fdd39" /> | task-[5457179](https://www.odoo.com/odoo/project/974/tasks/5457179) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a recent issue where quotation documents with zero subtotal lines were being discarded during upload. The fix ensures that all lines, including those with a zero subtotal, are correctly processed, maintaining accurate quotation data. This resolves a regression introduced in a previous update.
Original PR description
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document upload. Steps to reproduce: --- 1- In sale app, upload a quotation document without line amount. (You could use the one attached in the ticket) 2- As you see, lines are discarded. Cause: --- This regression is introduced in https://github.com/odoo/odoo/pull/245862, to prevent lines with zero amount in accounting. The https://github.com/odoo/odoo/pull/245862 targets 16.0. However, the `sale_edi_ubl` is introduced on 18.0. Fix: --- Instead of `_retrieve_line_vals` (`_import_fill_invoice_line_values` on 16.0) returning `None` when `price_subtotal` is not present, it can keep returning `dict` with an extra key `price_subtotal`, and filter out unwanted line in `_retrieve_invoice_line_vals` itself. opw-5977735 Forward-Port-Of: odoo/odoo#251463