Daily updates from Odoo
Monday, February 2, 2026
12 changes · master
Resolved issues and error corrections
This update fixes an issue where users wouldn't receive a warning when entering invalid email addresses during shared sign request declines. Now, the system validates email formats and displays a clear warning message, preventing incorrect data entry and improving the overall user experience. This ensures data integrity and reduces potential errors.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create a shared sign request. - Try to decline the sign request. - Enter an email address in an invalid format. Issue: - No warning is shown to the user for an invalid email and An RPC_ERROR appears in the console. - This happens because the _check_signer_email_validity constraint fails when signer_email is not valid. Solution: - Validate the email format when the user submits the refusal request. - Show a warning message if the email format is invalid. task-5454929 Forward-Port-Of: odoo/enterprise#103146
This update clarifies WhatsApp channel access restrictions for users. Now, a message displays below the invitation link, indicating which groups are allowed to join. This prevents confusion and ensures users understand who can participate in the conversation.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Users had no clear indication when a WhatsApp channel was restricted to a specific access group. This could lead to confusion about who was allowed to join the conversation through the invitation link. **Current behavior before PR:** --------------------------------- - The WhatsApp channel does not display any information about access restrictions. - Users cannot easily understand why some people cannot join the conversation. **Desired behavior after PR is merged:** ----------------------------------------- - An explicit message “Access restricted to group ‘Role / User’” is displayed below the WhatsApp channel invitation link. - Users can immediately understand that only members of the specified access group are allowed to join. **Task:** 5135950 **Related Community PR:** https://github.com/odoo/odoo/pull/236226
This update fixes an issue where users couldn't edit the 'Email From' and 'Reply To' fields when creating new email templates within marketing campaigns. The change restores the ability to modify these fields, ensuring users have full control over their email communications. This improves the flexibility and usability of the marketing automation features.
Original PR description
Currently when a user creates a new template from a marketing campaign, they can’t edit the `email_from` and `reply_to` fields, even though these should be editable in the template. **Steps to…
Currently when a user creates a new template from a marketing campaign, they can’t edit the `email_from` and `reply_to` fields, even though these should be editable in the template. **Steps to replicate:** * Install `marketing_automation` * marketing automation > Create a New campaign > Add a new activity * Mail template > Create a new template > Settings **Observed Behavior:** The fields `Send From` and `Reply To` are not editable which should be editable. **Root cause:** * After commit [1], the form view `mailing_mailing_view_form_marketing_activity` [2] was removed, so `email_from` and `reply_to` now come from the view [3]. Because that view inherits the `mass-mailing form`, its `readonly` rules apply (see [4]), and with `default_state` set to “done” (see [5]), those fields become `readonly` when creating a new mail template. **Solution:** Modify the readonly conditions to match how they were handled in earlier versions (see [6]). **Before:** <img width="1182" height="591" alt="image" src="https://github.com/user-attachments/assets/72006a7f-1ee5-40dd-8899-4eb932f503b7" /> **After:** <img width="1182" height="591" alt="image" src="https://github.com/user-attachments/assets/d5d6bdf2-1fb6-4e7b-9527-412c44986050" /> [1]: https://github.com/odoo/enterprise/commit/a469218b32943ddaa83271565e73311cfd188f84 [2]: https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/mailing_mailing_views.xml#L75-L143 [3]: https://github.com/odoo/enterprise/blob/307b23b0f6b377c43463a04aabf0b2f03c256072/marketing_automation/views/mailing_mailing_views.xml#L107 [4]: https://github.com/odoo/odoo/blob/9e04aadb83d482d05fc2fa66fa3c3bebb6ac1528/addons/mass_mailing/views/mailing_mailing_views.xml#L328-L337 [5]: https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/marketing_activity_views.xml#L23 [6]: https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/mailing_mailing_views.xml#L96 opw-5401422,5449345,5369836 Forward-Port-Of: odoo/enterprise#101807
This update resolves an issue where new appointments were sometimes created with duplicate default time slots. The fix ensures that default slots are only created once, preventing confusion and ensuring accurate appointment scheduling. This improves the user experience and data integrity.
Original PR description
Steps to reproduce: - Install website_appointment - Go to the frontend and create a new appointment from there - The appointment created has its default slots duplicated When creating an appointment type, it's possible that we end up creating the default slots two times by passing in the compute of the category and then the onchange linked to category_slot_scheduling. Technically, when we were in the onchange after the compute, slot_ids was populated by NewId records. So when assigning and creating a second time the default slots, the NewId would at the end become real records and the new one were added on top. Now we add a check on the previous category to create the default slot only when we came from a custom appointment and reset them if it is now a custom one. task-5499200 Forward-Port-Of: odoo/enterprise#104482
This update resolves an issue where users couldn't see all available Starshipit delivery services. The fix ensures Odoo sends complete order details to Starshipit, allowing users to accurately select the correct service based on their shipment information. This improves the user experience and ensures accurate delivery options.
Original PR description
Current behaviour: Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this…
Current behaviour: Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup. Expected behaviour: Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume). Steps to reproduce: 1. Create new delivery method 2. Configure Starshipit API credentials. 3. Attempt to select a service. 4. Observe that not all service is shown from the available options. Cause of the issue: Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods. Fix: Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them. Forward-Port-Of: odoo/enterprise#103316
This update corrects a technical issue within the IoT module where the ORM import was incorrectly configured. By switching to `useService` for importing the ORM, the system now functions correctly, ensuring data integrity and stability. This resolves a potential error reported in the system.
Original PR description
In odoo/enterprise#104794, we moved the test button logic from the form controller to a widged. The orm should now be imported through `useService` instead of the now undefined `model`.
This update corrects a visual issue where newly added timesheet entries were incorrectly appearing at the top of the helpdesk ticket list. The fix restores the default list view setting to add new entries at the bottom, ensuring a consistent and user-friendly experience. This improves the clarity and organization of timesheet data.
Original PR description
Steps to Reproduce: - Open the helpdesk ticket form view - Add a new Timesheet entry - Notice that the newly created timesheet appears at the top of the list Cause: The timesheet list view was configured with editable="top", which forces newly created records to be inserted at the top. Solution: Restore the list view configuration to use editable="bottom" ensuring new timesheet entries are consistently added at the bottom of the list. task-5309676
This update refines the bill auto-complete feature within the Enterprise accounting module. Previously, the feature could suggest bills and purchase orders, but it has now been restricted to only suggesting purchase orders. This change ensures data consistency and accuracy in purchase order processing.
Original PR description
Adjust a few test cases to reflect the change in how the auto-complete feature works, it used to be able to auto-complete from pruchase orders or bills, now it can only auto-complete form purchase orders task-5258726
This update resolves an issue preventing users with standard access rights from accessing the documents application. The fix restricts access to a sensitive field and limits visibility of certain features to system administrators, ensuring proper security and functionality for all users.
Original PR description
Internal Users with the "Access Rights" access right were not able to open the documents application, which raised an access error traceback on the `ai_sort_prompt` field - which has restricted access to only admins. The access error was raised because the `ai_sort_prompt` field was added to the search_panel_fields for users with Access Rights access rights. We changed it so it is only added when users have the document system adminstrator role. We also changed the document_service's start method to also define the documentSystem user which is the system adminstrator user. With that we could limit visibility of the System Prompt item in the cog menu to those users. task-5375110 Forward-Port-Of: odoo/enterprise#105741
This update resolves an issue where the default packaging type for service products in the Odoo Enterprise system was incorrectly configured. The previous XML ID no longer functioned, preventing proper EDI processing. This fix ensures service products are correctly packaged for electronic invoicing in Kenya.
Original PR description
Update the xmlid for the default packaging type for service products, the previous one `l10n_ke_edi_oscu.packaging_type_ou` seems to have never existed. opw-5220129 Forward-Port-Of: odoo/enterprise#105905
This update fixes an issue where document actions would fail when multiple languages were enabled and then one was disabled. The change ensures that actions are now filtered to only include those linked to currently active languages, preventing errors and improving stability. This impacts the Documents module.
Original PR description
Filter Embedded Actions Based on Active Languages ### Impacted versions: 18.0 and later ### Steps to reproduce: - Install at least 2 languages - Install documents and accounting or other app to have actions on select - Uninstall one language - You will get an error when trying to activate again actions on select (also appears on network interface) ### Current behavior: When a language is deactivated, its corresponding translations may still appear in server actions, leading to errors when trying to add them to the context. This issue is now resolved by filtering actions to only include those linked to active languages. Task: [5420820](https://www.odoo.com/odoo/project/49/tasks/5420820) Forward-Port-Of: odoo/enterprise#102938
This update fixes an issue where the UrbanPiper store identifier field was visually overflowing its container. The changes include wrapping the field and button in a container with flexible width and overflow-hidden styling, resulting in a cleaner and more user-friendly display for users interacting with the UrbanPiper POS integration.
Original PR description
Before this commit: --- - The UrbanPiper store identifier field could overflow its container. After this commit: --- - Wrap the store identifier field and action button in a container. - Apply `overflow-hidden` and flexible width to the store identifier field. task-5472992 Forward-Port-Of: odoo/enterprise#106075 Forward-Port-Of: odoo/enterprise#103464