Daily updates from Odoo
Navigate
Branch
Monday, June 29, 2026
241 changes
8 changes
Enhancements to existing features
This change lets operators adjust how long unused database connections stay open by using an environment variable. It helps reduce memory usage in environments with limited resources by closing idle connections sooner when needed.
Original PR description
In memory-scarce environments, the default 10-minute idle timeout may keep too many backend connections alive. Allow operators to override it via the ODOO_DB_MAX_IDLE_TIMEOUT environment variable to evict idle connections more aggressively. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: https://github.com/odoo/odoo/pull/271785
Resolved issues and error corrections
When a Google account is disconnected with the option to delete events, recurring calendar entries are now fully removed as well. This prevents leftover recurrence records from staying behind and keeps calendars cleaner and more consistent.
Original PR description
When we disconnect a google account with the delete events option enabled, we should also delete `calendar.recurrence` records, not just the base events Follow-up for odoo/odoo@ae52126522e3570e11845c3c04d0eb6b198b3848
This update corrects how taxes are handled and displayed across invoicing, purchasing, and sales screens. It also improves imported Italian invoices by preserving the correct tax mode, helping avoid inconsistent totals and reducing manual corrections.
Original PR description
- changing python constraint on document tax mode on account.move to SQL - removing custom component now resolved by just adding xml field required condition - specifying child type to target for css class overlap_badge_tab - style enhancements to the overlap_badge_tab - removing inconsistent rounding in purchase.order - adding document tax mode logic to account.tax compute_all method, adapted for sale_margin - adding missing document tax mode ‘tax_excluded’ setting to l10n_it_edi during account.move creation of imported invoices Following up: https://github.com/odoo/odoo/pull/251800
This fixes an issue in the website editor where changing theme styles could accidentally mark unrelated content as modified. As a result, saving after a style change no longer saves unrelated views, reducing unnecessary updates and helping keep site edits clean.
Original PR description
__Problem__ Since odoo/odoo@163a317c9d3, editing website styles would save some unrelated views. __To reproduce__ 1. Open the website builder. 2. Switch to the theme tab. 3. Edit a color. ⮕ Some unrelated elements become `o_dirty`. 4. Undo. ⮕ The elements remain `o_dirty`. 5. Save. ⮕ Views linked to those elements are unnecessarily saved. __Reason__ During normalization, we call `refreshInteractions` → `disableObserver` → `on_pending_mutations_staged_handlers`, which adds `o_dirty` via the `save_plugin`. __Quick fix__ Change the normalization sequence so that it runs first. At that point, there are no pending mutations yet, so `o_dirty` is not added. task-6333960
This update corrects a layout issue in website theme previews where shapes could appear too close together or with an unwanted gap. It helps previews look cleaner and more accurate, making it easier for users to evaluate themes before applying them.
Original PR description
task-6340483
The Shopee connector now handles customer identifiers that are larger than the previously expected limit, preventing errors when creating new contacts. For cases where the ID is too large for the existing database field, Odoo stores and matches it using an alternate contact reference so Shopee orders keep syncing properly.
Original PR description
When the Shopee connector was introduced, Shopee documented `buyer_user_id` as an int32. We therefore store it in an `Integer` field, which maps to a PostgreSQL int32 column. However, feedback showed that Shopee can send ids exceeding the int32 bounds, leading to a traceback when creating new contacts. Shopee has since updated their documentation to confirm the field is actually an int64. Since we are in stable and cannot change the column type, this commit falls back to the `ref` field of the `res.partner` model to store and match Shopee contacts whose identifier doesn't fit within an int32. opw-6325948 See also: - master: https://github.com/odoo/enterprise/pull/121507 - upgrade: https://github.com/odoo/upgrade/pull/10578 Forward-Port-Of: odoo/enterprise#121707 Forward-Port-Of: odoo/enterprise#121498
Miscellaneous changes
This pull request updates the saas-19.4 release information in Odoo’s release file. It helps keep the product versioning and release metadata aligned with the current branch, supporting a clean and consistent software release process.
This pull request appears to be a release coordination update for the SaaS 19.4 branch. It mainly prepares the branch for delivery and does not indicate a specific business feature or user-facing change.
6 changes
Enhancements to existing features
The check status button is now disabled when the user does not have permission to edit it. This avoids access errors and makes the behavior clearer when working across companies in a tax unit.
Original PR description
Before this commit: Only main company of tax unit have write access on check, so when main company is not selected and user tries to change status of check, access error is thrown. After this commit: Disable check status button if user don't have write access on check. task-5951364 Forward-Port-Of: odoo/odoo#271447
This change lets operators adjust how long idle database connections stay open by setting an environment variable. It helps reduce memory usage in environments with limited resources by closing unused connections sooner.
Original PR description
In memory-scarce environments, the default 10-minute idle timeout may keep too many backend connections alive. Allow operators to override it via the ODOO_DB_MAX_IDLE_TIMEOUT environment variable to evict idle connections more aggressively. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271785
Resolved issues and error corrections
Users can now sort project tasks by Planned Date in the portal without encountering an error. This restores a common sorting option and prevents the page from failing when customers review their tasks.
Original PR description
Currently, an error occurs when a user sorts tasks by Planned Date. **Steps to reproduce:** - Install the `project_enterprise` module with demo data. - Go to Projects in the portal (`/my/projects`),…
Currently, an error occurs when a user sorts tasks by Planned Date. **Steps to reproduce:** - Install the `project_enterprise` module with demo data. - Go to Projects in the portal (`/my/projects`), open any `project`, and sort the tasks by `Planned Date`. KeyError: 'order' After a [recent change], the sort order is retrieved from searchbar sortings. When sorting by Planned Date, it attempts to access the order key from the corresponding sorting configuration [1]. However, the planned_date_begin entry does not define an order key [2], which raises error when it tries to access order. This commit ensures that the order key is added with its value for planned_date_begin in searchbar sorting. [recent change]: https://github.com/odoo/odoo/commit/8be5dacf9fbfe8c23b04c876994bea2ce7cbb89a [1]: https://github.com/odoo/odoo/blob/2ae9b57b86cd0bc4816ff8ec207564631baa8ad6/addons/project/controllers/portal.py#L424 [2]- https://github.com/odoo/enterprise/blob/9dd3a9b2c09a6d23a3f71d3e531edd6d78b30277/project_enterprise/controllers/portal.py#L8-L11 sentry-7556050938 Forward-Port-Of: odoo/enterprise#121230 Forward-Port-Of: odoo/enterprise#121141
Flexible employees can now request a one-day time off on a public holiday when the time off type counts public holidays in the duration. This fixes cases where the request was wrongly rejected, making single-day and multi-day requests behave consistently.
Original PR description
Currently, flexible employees can request a multi-day leave spanning a public holiday when the leave type includes public holidays in duration. However, requesting the public holiday date alone is…
Currently, flexible employees can request a multi-day leave spanning a public holiday when the leave type includes public holidays in duration. However, requesting the public holiday date alone is rejected. ### **Steps to reproduce:** - Create a public holiday. - Create a time off type with "Public Holiday Included" enabled. - Select/create an employee with a flexible work schedule and its time zone must be same as admin. - Request a time off on the public holiday date only. ### **Observed Behavior:** The request is rejected because its duration is computed as 0 days. ### **Expected Behavior:** The request should be allowed and count as 1 day, consistent with the multi-day request behavior. ### **Root Cause:** At [1], a dedicated duration computation path is used for single-day leaves of flexible employees. This logic always retrieves overlapping public holidays and computes the leave duration based on the remaining intervals. As a result, a leave requested entirely on a public holiday is computed as 0 days, even when `include_public_holidays_in_duration` is enabled. [1]- https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/hr_holidays/models/hr_leave.py#L436-L444 ### **Fix:** This commit ensures that the `include_public_holidays_in_duration` setting is taken into account when computing single-day leave durations for flexible employees **opw-6284768** Forward-Port-Of: odoo/odoo#272217 Forward-Port-Of: odoo/odoo#269743
This update fixes the data sent when cancelling documents through the Mexican e-invoicing service. It ensures the certificate is encoded correctly again, so cancellation requests complete successfully instead of failing.
Original PR description
Issue: https://drive.google.com/file/d/1-57iHrMoBo79EbUaWuwkJut_7FfyzeLY/view
`_sw_cancel` sent `pem_certificate.decode('UTF-8')` as `b64Cer`, which used to work because `fields.Binary` returned base64-encoded bytes. Since binary fields now return a `BinaryValue`, `.decode()` returns the raw PEM content instead of base64, breaking the SW cancel API call.
Use `.to_base64() " to properly base64-encode the certificate, matching the pattern already used for `b64Key " and in `_sw_sign ".
related change for binary fields: [41fe2eb](https://github.com/odoo/odoo/commit/41fe2ebdb9cc)
task-6319057The website editor sidebar was adjusted so it keeps its intended width even when the browser is zoomed in. This prevents the preview from switching to mobile mode when users click Edit at 150% zoom, improving the editing experience.
Original PR description
Steps to reproduce: - Open a website page on Chrome/Firefox. - Set the browser zoom to 150%. - Click Edit. => The website preview switches to mobile view. Before this commit, [1] changed the sidebar to `content-box`, so the `border-start` class added one pixel to `$o-we-sidebar-width`. The sidebar then reached 289px instead of 288px, which made the preview fall below the desktop breakpoint at 150% zoom. After this commit, the sidebar width subtracts the Bootstrap border width so its total width stays at 288px and edit mode keeps the desktop view. [1]: https://github.com/odoo/odoo/commit/181b870c3c6cf28c3eac59a16c36b94ae11ae927 task-6251151 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272074
20 changes
New functionality added to Odoo
This update adds support for two additional food delivery providers: Food Zapp for the UAE and Enqueue for Saudi Arabia. It helps businesses using Odoo connect more easily with local delivery partners in these markets.
Original PR description
In this commit: - We are introducing two new providers, FoodZapp and Enqueue, for the UAE and KSA, respectively. Task-6263190,6263310 Forward-Port-Of: odoo/enterprise#121461
Enhancements to existing features
This change lets operators adjust how long unused database connections stay open by using an environment setting. It helps reduce memory usage in environments where keeping too many idle connections alive could strain resources.
Original PR description
In memory-scarce environments, the default 10-minute idle timeout may keep too many backend connections alive. Allow operators to override it via the ODOO_DB_MAX_IDLE_TIMEOUT environment variable to evict idle connections more aggressively. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271785
The check status button is now disabled for users who do not have permission to edit the check. This prevents access errors when a user tries to change a check’s status in a company where they do not have write access.
Original PR description
Before this commit: Only main company of tax unit have write access on check, so when main company is not selected and user tries to change status of check, access error is thrown. After this commit: Disable check status button if user don't have write access on check. task-5951364 Forward-Port-Of: odoo/odoo#271447
Resolved issues and error corrections
This fix prevents the translation dialog in Studio report editing from crashing in databases where the default English language is not installed. It ensures the base language is always included, so users can translate report content without interruption.
Original PR description
Steps: - Install web_studio in a db initialized with en_UK only (db init --languages en_UK db_name) - Install `fr_FR` language after - Open any report in studio report editor - Edit sources - Click on "FR" logo (translate option) - Traceback `_get_base_lang()` hardcodes 'en_US' as the source language for field translations. When a database is initialized without en_US (e.g. using en_UK), that code is absent from `_get_active_langs()`. The `_get_view_translations` controller would then build a languages dict where no entry has `is_base=True`, leaving `baseLang` undefined on the frontend and crashing the XML translation dialog at: https://github.com.com/odoo/enterprise/blob/fc37919036a365babb4ab7e39c8347b0069d4206/web_studio/static/src/client_action/report_editor/report_editor_xml/translate_xml.xml#L14 After this commit, `base_lang` record is added to the list used in languages opw-6239938
This update prevents text selection from being reset when a popover, such as the color picker, is closed by clicking back inside the editor. As a result, users keep the expected cursor and selection position, making text editing more reliable and consistent across browsers.
Original PR description
When a popover is used on top of an iframe, when clicking outside the popover but inside the iframe to close the popover, the click away is detected through a blur event. The close during the click…
When a popover is used on top of an iframe, when clicking outside the popover but inside the iframe to close the popover, the click away is detected through a blur event. The close during the click away is used by some features to apply the change. Setting the text color in the editor might modify the DOM structure and therefore needs to readjust the selection to match the new DOM nodes. When confirming a color, or when applying intermediary changes this behavior is required. But when the color confirmation happens because of a click away, this selection gets on the way of the selection made by clicking away. The sequence of events is as follows: - pointerdown in iframe: sets the selection based on the click - main window blur: color gets applied, and selection gets reset - pointermove in iframe: expands selection to new position This commit avoids this unwanted reset by detecting the click away through a pointerdown on the iframe - thus making the selection adjustment before the default browser handling of the event actually sets the selection on the clicked position. Steps to reproduce: - Edit a website page - Drop a text snippet - Select a word - Set a custom color using the color area - so that the color picker remains open - Click (and hold) in the empty area after the text paragraph - Move pointer by a few pixels => The text anchor remained the one of the former selection, but the focus was set according to the pointer position Note that Firefox did not blur the main window, therefore this change actually also unifies the behavior of Chrome and Firefox. The discrepancy between Chrome and Firefox's handling of the blur event in this situation seems to be related to either prioritizing the DOM specifications or the HTML specifications - and the way the are interpreted. The DOM Standard [1] relies on UIEvents [2] which states: "A user agent MUST dispatch this event when an event target loses focus." The HTML Standard defines how to compute the focus [3] and relies on nested browsing contexts [4]. Typically, the simpler readable description for developers says: "document.hasFocus() Returns true if key events are being routed through or to document; otherwise, returns false. Roughly speaking, this corresponds to document, or a document nested inside document, being focused." [1]: https://dom.spec.whatwg.org/#biblio-uievents [2]: https://w3c.github.io/uievents/#event-type-blur [3]: https://html.spec.whatwg.org/multipage/interaction.html#focus-processing-model [4]: https://html.spec.whatwg.org/multipage/document-sequences.html#nested-browsing-contexts task-6268573 Forward-Port-Of: odoo/odoo#269742
This fix ensures the editing toolbar disappears when a text block is deleted from the website builder. It improves the editing experience by preventing the toolbar from staying visible after the selected content is gone.
Original PR description
Commit 8df8b4f41809de75f9ca220d47274cc3166f1cd5 moved the check for selection inside `[data-prevent-closing-overlay]` to the `closeToolbar` plugin. But when this function is called from `selection_leave_handlers` it should not do that check, as it was done for the focus or click. This commit skips the check based on the selection when `closeToolbar` is called by `selection_leave_handlers`. Steps to reproduce: - Open website builder - Drop "Text Image" snippet - Select some text in the snippet - Click on the trash icon in the sidebar to remove the snippet - Bug: the toolbar is still shown task-6308364 Forward-Port-Of: odoo/odoo#270516
This update corrects the validation banner on public forum profiles so it shows the logged-in visitor’s own email status instead of another user’s private email address. It prevents accidental exposure of personal information while keeping the email verification message working as intended.
Original PR description
**Steps to reproduce:**
- Install website_forum module
- Create a new portal user and log in with it
- Go to the website forum to see that the account requires email verification
- Send the verification email to see the green banner ('an email was sent to XX')
- Add XP (karma) points to this user as admin (User > Smart actions > Karma)
- Switch back to the portal account
- Check any public user profile on the forum (`/profile/user/2?forum_id=2`)
- Green banner now displays the private email of the user you're checking
**Issue:**
On the `email_validation_banner` the user field is used for the validation
data, but it is overridden by `_prepare_user_profile_values` which is
setting the current page user.
**Fix:**
Properly set `user` to `env.user` in the template.
opw-6276809
Forward-Port-Of: odoo/odoo#269249This update fixes several issues in the rental webshop test flow so it runs reliably again. It ensures demo payment data is only prepared when available, allows weekend rentals in the test setup, and makes the shop search the intended product instead of picking from unrelated items.
Original PR description
## [FIX] website_sale_renting_planning: prepare payment if demo is installed Before this commit, the demo `payment.provider` for the tests was being created in `setUpClass` this caused an issue…
## [FIX] website_sale_renting_planning: prepare payment if demo is installed Before this commit, the demo `payment.provider` for the tests was being created in `setUpClass` this caused an issue because `payment_demo` is not a dependency of this module, therefore it may not be installed while these tests are running and cause the tests to error at setup. After this commit, the `payment.provider` creation was moved into the tests after the check for `payment_demo` installation, ensuring that `payment_demo` would exist when a `payment.provider` is prepared. https://runbot.odoo.com/odoo/runbot.build.error/940273 ## [FIX] website_sale_renting_planning: unforbid weekend in tests Before this commit, the company had `renting_forbidden_sat` and `renting_forbidden_sun` enabled which made it not possible to rent products from website if the rental date included a saturday or sunday. This commit fixes that but setting `renting_forbidden_sat` and `renting_forbidden_sun` to False and allowing rental on all days of the week. https://runbot.odoo.com/odoo/runbot.build.error/940312 ## [FIX] website_sale_renting_planning: search for product in shop page Before this commit, the website `/shop` page would display all published products in the db, this could cause the `website_sale_renting_planning_buy_product` tour to fail if the setup product is not in the first page. After this commit, the `/shop` page is now access with a search on the product to ensure there won't be other products in the first page. https://runbot.odoo.com/odoo/runbot.build.error/940275 Forward-Port-Of: odoo/enterprise#121342
This change prevents an error that could occur when users add properties to a record, especially when other fields depend on those properties. The system now waits for the property data to finish loading before showing it, so the action completes reliably instead of failing.
Original PR description
Description of the issue/feature this PR addresses: This error occurs when a model has properties and a `computed` field or `onchange` method depends on them. `record.update()` is asynchronous. When…
Description of the issue/feature this PR addresses: This error occurs when a model has properties and a `computed` field or `onchange` method depends on them. `record.update()` is asynchronous. When an onchange or computed field is triggered, an additional request is sent to the server, increasing the time required to complete the update. See: https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/model/relational_model/record.js#L1207-L1211 However, `PropertiesField` is rendered before the `update` is completed. See: https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/views/fields/properties/properties_field.js#L86 As a result, the property labels are not yet available and the following traceback is raised: `TypeError: Cannot read properties of undefined (reading 'getRootNode') ` After this commit, the update is awaited before rendering PropertiesField, ensuring that the property labels are available. **Steps to reproduce:** 1. Install the example module. [project_task_property.zip](https://github.com/user-attachments/files/29138424/project_task_property.zip) 2. Open or create a project task. 3. From the Action menu, click `Add Properties`. The error is raised. <img width="1520" height="956" alt="image" src="https://github.com/user-attachments/assets/a3051ddf-5af0-4d3a-8ff7-c3fb4f7a69d2" /> TT63331 @Tecnativa @pedrobaeza --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272571 Forward-Port-Of: odoo/odoo#271082
This change makes the “undo reconciliation” action bypass extra validation checks so the reconciliation line can be reset correctly. It helps users reverse a reconciliation without getting blocked by checks that are not needed in this flow.
Original PR description
When undoing the reconciliation from the "undo reconciliation" button. We want to bypass all the checks to be able to reset the line. no task id
This fix prevents the website editor from switching to mobile view when users zoom their browser to 150% and click Edit. It keeps the sidebar within the expected width so the editing experience remains consistent on desktop screens.
Original PR description
Steps to reproduce: - Open a website page on Chrome/Firefox. - Set the browser zoom to 150%. - Click Edit. => The website preview switches to mobile view. Before this commit, [1] changed the sidebar to `content-box`, so the `border-start` class added one pixel to `$o-we-sidebar-width`. The sidebar then reached 289px instead of 288px, which made the preview fall below the desktop breakpoint at 150% zoom. After this commit, the sidebar width subtracts the Bootstrap border width so its total width stays at 288px and edit mode keeps the desktop view. [1]: https://github.com/odoo/odoo/commit/181b870c3c6cf28c3eac59a16c36b94ae11ae927 task-6251151 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272074
This fix ensures that the delivery and billing addresses chosen during checkout are kept when the cart is refreshed in the background. It prevents the order from silently reverting to a default company address, avoiding confusion and extra corrections after payment.
Original PR description
Steps to reproduce: =================== 1. Add several delivery addresses & billing addresses 2. Add a product to the cart and go to checkout. 3. Select a specific delivery address and a different…
Steps to reproduce: =================== 1. Add several delivery addresses & billing addresses 2. Add a product to the cart and go to checkout. 3. Select a specific delivery address and a different invoice address. 4. Pay and click "Skip" immediately on that page. 5. Open the resulting sales order. => The delivery address is reset to the company's first delivery child instead of the one selected during checkout. Root cause: =========== `partner_shipping_id` and `partner_invoice_id` are stored computed fields (compute + store + readonly=False) that depend on `partner_id`. Any write that includes `partner_id`, even writing the same value, retriggers the compute and overwrites a manually selected address with the result of `partner_id.address_get()`. `_get_and_cache_current_cart` resurrects the customer's draft cart when it is no longer referenced in the session and re-runs `_update_address(partner, ['partner_id'])` on it to refresh the pricelist and fiscal position. Clicking "Skip" runs `sale_reset()`, which clears the session cart key while the order is still draft, so the next cart access takes that abandoned-cart branch and the redundant `partner_id` write discards the selected delivery/invoice address. Waiting a few seconds lets the order reach the 'sale' state first, so the draft search no longer matches and the address is kept, which is why the issue is timing dependent. Fix: ==== In `_update_address`, when partner_id is written, keep the delivery and invoice addresses already set on the cart if they still belong to the new partner's company (same `commercial_partner_id`) by writing them in the same `write()` so the recompute does not override them. Addresses that do not belong to the new partner are still recomputed to the partner's defaults. opw-6267188 Forward-Port-Of: odoo/odoo#270300
The system no longer logs a warning for every document upload when automatic OCR is turned off. This keeps logs cleaner and avoids confusing messages that do not require any action.
Original PR description
The warning "Automatic OCR does not apply to this document" was logged for every upload when automatic OCR isn't enabled, it isn't very useful. opw-[6232122](https://www.odoo.com/odoo/unassigned-tasks/6232122) Forward-Port-Of: odoo/enterprise#120741
This change prevents portal users from hitting an access error when viewing Knowledge articles that contain item lists with author or last-edited information. It ensures shared articles load correctly for external users instead of failing or hiding content.
Original PR description
Problem: Since saas-19.2 (99f38be260c3c5523306e4ffcb4cf18436d40568), portal users crash when opening a Knowledge article containing items with "Created by" or "Last edited by" columns. Cause: Portal…
Problem: Since saas-19.2 (99f38be260c3c5523306e4ffcb4cf18436d40568), portal users crash when opening a Knowledge article containing items with "Created by" or "Last edited by" columns. Cause: Portal users are restricted to their own res.users record. Reading create_uid and last_edition_uid of internal users raises an AccessError. This was not raised in 19.0. Specifically, the `many2one_avatar_user` field widget defines `write_date` in `relatedFields`, which forces the RPC to read the `write_date` field of the target user. Since portal users cannot read other users' records, it raises an AccessError. Solution: Only include `write_date` in the field widget's `relatedFields` if the current user is an internal user. For portal users, `relatedFields` will be empty, avoiding the AccessError. Steps to reproduce: 1. Create a Knowledge article. 2. Add an "Item list" element. 3. Add some items to the list. 4. Share the article with a portal user. 5. Open the article as the portal user. 6. Observe that only the list header is visible and the items are not displayed. opw-6199714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents font and style changes from being applied outside the editable area when users edit website content. It ensures formatting is saved correctly in website builder and translation editing, avoiding cases where changes were previously lost after saving.
Original PR description
Commit e0cf601ab6fc1d7cb007fcb16ee4bb6097ba6fdd added a condition to apply format on the parent of fully selected unsplittable nodes. But this could lead to format applied outside of `contenteditable=true` nodes in some cases of website builder. This commit adds a condition to only apply format outside the unsplittable if it is not the node with `contenteditable`. Steps to reproduce: - In event page, open website builder - Double click on "Starts" in the sidebar inside the event page - Change font size - Save - Bug: the changed font size is not save (a span with the font class was created outside the savable element) ### - In translate mode - Select a whole translation span - Change font size - Save - Bug: the changed font size is not save (the font class was added on the translation span) task-6308352 Forward-Port-Of: odoo/odoo#271888 Forward-Port-Of: odoo/odoo#270401
Neutralized databases will now use the test VAT validation service instead of accidentally contacting the live production service. This reduces the risk of sending test data to real external systems while keeping custom service settings unchanged.
Original PR description
Neutralized databases don't always have demo data, so they talk to production VIES endpoint. With this change, the production endpoint is replaced with the test one. If some database has a custom endpoint, nothing is done. @moduon MT-15142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272036
This update corrects how half-day time off is calculated for French companies, especially for part-time employees whose schedule does not match the company schedule. It ensures leave durations are shown accurately and prevents certain leaves from being extended incorrectly when they end in the morning.
Original PR description
**Steps to reproduce** - Use a french company with `l10n_fr_hr_holidays` installed - Change the duration type of the time off type set as the "Company Paid Time Off Type" in the French Time Off…
**Steps to reproduce** - Use a french company with `l10n_fr_hr_holidays` installed - Change the duration type of the time off type set as the "Company Paid Time Off Type" in the French Time Off Localization settings to "Half-Day" - Company Working Schedule: - Attendance on a day from 10 to 19, Day Period: Full Day - Part-time employee Working Schedule: - Attendance on the same day from 11 to 12, Day Period: Morning - Attendance on the same day from 13 to 19, Day Period: Afternoon - Create a full day time off for the part time employee on that day, using the time off type set as the "Company Paid Time Off Type" (start am, end pm) -> Excepted: time off duration is 1 day -> Actual: time off duration is 0.89 day **Change** Now that `request_unit_half` of a leave is a simple related to the `request_unit` of the leave type, it becomes important to not rely on a call to `_get_durations` using the company's calendar to compute the leave's duration, as it may not be fully accurate when the company's working hours and employee's working hours are not aligned. Continuation of 05e71eb206eb02a8d15708e6fb532a732a767d6d `_get_fr_date_from_to` is also adapted to take into account multi-day leaves ending in the morning while the employee works in the afternoon (in which case it should not be extended in case the employee doesn't work the next day). opw-6000011 Forward-Port-Of: odoo/odoo#269890 Forward-Port-Of: odoo/odoo#253059
Ledgers that do not contain any journals for the currently active companies will no longer be shown. This reduces confusion by removing entries that would not be relevant or useful in the current company context.
Original PR description
When a ledger does not include any journal of the active companies, do not display it because it does not make sence for these companies. task-6280033
The Mexican e-invoicing document now shows the correct payment amount and exchange rate when a payment is made in a foreign currency. This prevents incorrect payment information from appearing after updating payments on an invoice, helping ensure the CFDI matches the real transaction.
Original PR description
The rate and payment amount shown on the CFDI document generated after updating payments was wrong when the payment was made in a foreign currency. Steps to reproduce: ------------------- * Create a journal that use USD as currency and set the rate to 20 MXN for 1 USD * Create an invoice in MXN and make sure it is set to PPD * Add any product to the invoice for 300$ and post it * Send the invoice to CFDI (a first document should be generated) * Create a payment of 15 USD in the new journal and reconcile it with the invoice * Go back to the invoice and click on "Update payments" to generate the second CFDI document > Observation: The payment document shows an amount of 300 USD with a rate of 1 instead of 15 USD with a rate of 20. Why the fix: ------------ We make sure to use the amount from the statement line when there is one. opw-5974519 Forward-Port-Of: odoo/enterprise#121410 Forward-Port-Of: odoo/enterprise#115779
Documentation and clarification updates
This change adds a contributor license agreement file for David Sonnet. It is an administrative/legal update that confirms the contributor has signed the Odoo Individual Contributor License Agreement, with no functional impact on the product.
Original PR description
Signing the Odoo Individual Contributor License Agreement v1.0. Adds `doc/cla/individual/dsonnet.md`. --- I confirm I have read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270526
28 changes
New functionality added to Odoo
This update adds two new delivery provider options for online orders: Food Zapp for the UAE and Enqueue for Saudi Arabia. It gives businesses in these markets more delivery integration choices and helps expand local delivery support.
Original PR description
In this commit: - We are introducing two new providers, FoodZapp and Enqueue, for the UAE and KSA, respectively. Task-6263190,6263310 Forward-Port-Of: odoo/enterprise#121461
Enhancements to existing features
This change lets administrators adjust how long idle database connections are kept open. It helps reduce memory usage in environments where keeping too many unused connections alive can strain system resources.
Original PR description
In memory-scarce environments, the default 10-minute idle timeout may keep too many backend connections alive. Allow operators to override it via the ODOO_DB_MAX_IDLE_TIMEOUT environment variable to evict idle connections more aggressively. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271785
The leave validation message now includes more useful context when an employee’s time off request cannot be processed. This makes it much easier for users and support teams to identify which employee and leave record caused the problem, especially when many records are updated at once.
Original PR description
The current message is pretty useless as of now when a lot of leaves are being written to, notably when creating a public holiday, which sets the state of all the leaves overlapping the public holiday's day to be reevaluated, and if an error occurs, you have to go through every employee's leave allocation and leaves taken to hopefully find one who might have to many days taken/not enough allocated. This extra information will be a huge QOL improvement, for the customer who will be able to troubleshoot his issue himself more easily, but also for our support team as the only way to debug those kind of issues now is to put a breakpoint there and see what employee has an issue. opw-4411999 Forward-Port-Of: odoo/odoo#270888 Forward-Port-Of: odoo/odoo#200376
The Point of Sale receipt now shows the tax base amount for every tax group again, matching the 19.0 receipt layout. This makes the tax breakdown easier to read and avoids receipts looking like a flat list when multiple tax groups share the same base amount.
Original PR description
Revert the receipt tax summary design back to the 19.0 format, ensuring that the base amount is always displayed for each tax group. Before this commit, when all tax groups shared the same tax base, the base amount was hidden, leading to a flat tax listing. Now, the template always renders the tax groups in the format: "Tax [Name] on [Base Amount] [Tax Amount]" task-id: 6296906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update restores the company address on Colombian invoices when using the Folder or Wave layouts. It also preserves the invoice title layout so PDF exports remain readable and complete.
Original PR description
Issue: On Wave and Folder layout, the address of the company doesn't appear on invoices. Steps to reproduce: - In a Colombian company, - Set company layout to Folder - Add a long tag line, - Create an invoice, - Send it to DIAN - Export to PDF Current behavior: - Company address is missing in the header Cause: Tag line + logo and address take 100% of the display width. However, loca add a QR code on the left, so it takes QR Code + 100% width. Therefore, address was out of the PDF. Moreover, for Folder layout, some resizing was done and as soon as there was a tag_line, the `rem` was downsized, allowing the invoice title: "Factura Electrónica de Venta SETP/*\*\*/\*\*\*\*" to be displayed entirely. The fix of the previous issue stopped the resizing, then the invoice title got overridden by the QR Code (same as without tag_line before this fix). opw-6239030
Imported bill quantities are now kept at the correct precision when matching them to purchase orders. This prevents small rounding differences that could make invoiced quantities off by a cent in some cases.
Original PR description
When importing an XML bill and linkin git to a purcahse order, the invoiced quantity may be computed incorrectly, due to a decimal precision mismatch. Steps to reproduce: - Import an XML bill having a line with quantity 1800.0 - Link to a purchase order with the same line Issue: The invoiced quantity will be computed with 1 cent difference (1800.01) Analysis: Because the system forced a decimal precision of 13 for 'Product Unit of Measure', quantity is imported as 1800.0000000000016. Later, when computing the invoiced quantity, the system round the quantity using 'UP' strategy, rounding the amount to 1800.01 opw-6194824 Forward-Port-Of: odoo/odoo#270916 Forward-Port-Of: odoo/odoo#266283
This fix makes the text editor toolbar disappear at the right time when a snippet is removed from a page. It prevents the toolbar from staying visible after deleting content, improving the editing experience in the website builder.
Original PR description
Commit 8df8b4f41809de75f9ca220d47274cc3166f1cd5 moved the check for selection inside `[data-prevent-closing-overlay]` to the `closeToolbar` plugin. But when this function is called from `selection_leave_handlers` it should not do that check, as it was done for the focus or click. This commit skips the check based on the selection when `closeToolbar` is called by `selection_leave_handlers`. Steps to reproduce: - Open website builder - Drop "Text Image" snippet - Select some text in the snippet - Click on the trash icon in the sidebar to remove the snippet - Bug: the toolbar is still shown task-6308364 Forward-Port-Of: odoo/odoo#270516
This update corrects the validation message shown on public forum profiles so it uses the signed-in user’s information instead of the profile being viewed. It prevents another user's private email address from appearing in the green email verification banner.
Original PR description
**Steps to reproduce:**
- Install website_forum module
- Create a new portal user and log in with it
- Go to the website forum to see that the account requires email verification
- Send the verification email to see the green banner ('an email was sent to XX')
- Add XP (karma) points to this user as admin (User > Smart actions > Karma)
- Switch back to the portal account
- Check any public user profile on the forum (`/profile/user/2?forum_id=2`)
- Green banner now displays the private email of the user you're checking
**Issue:**
On the `email_validation_banner` the user field is used for the validation
data, but it is overridden by `_prepare_user_profile_values` which is
setting the current page user.
**Fix:**
Properly set `user` to `env.user` in the template.
opw-6276809
Forward-Port-Of: odoo/odoo#269249This update fixes several issues in the website rental and planning tests so they run more reliably. It ensures payment setup only happens when the required demo data is available, allows weekend rentals in the test setup, and makes the product search more targeted so the correct item is found on the shop page.
Original PR description
## [FIX] website_sale_renting_planning: prepare payment if demo is installed Before this commit, the demo `payment.provider` for the tests was being created in `setUpClass` this caused an issue…
## [FIX] website_sale_renting_planning: prepare payment if demo is installed Before this commit, the demo `payment.provider` for the tests was being created in `setUpClass` this caused an issue because `payment_demo` is not a dependency of this module, therefore it may not be installed while these tests are running and cause the tests to error at setup. After this commit, the `payment.provider` creation was moved into the tests after the check for `payment_demo` installation, ensuring that `payment_demo` would exist when a `payment.provider` is prepared. https://runbot.odoo.com/odoo/runbot.build.error/940273 ## [FIX] website_sale_renting_planning: unforbid weekend in tests Before this commit, the company had `renting_forbidden_sat` and `renting_forbidden_sun` enabled which made it not possible to rent products from website if the rental date included a saturday or sunday. This commit fixes that but setting `renting_forbidden_sat` and `renting_forbidden_sun` to False and allowing rental on all days of the week. https://runbot.odoo.com/odoo/runbot.build.error/940312 ## [FIX] website_sale_renting_planning: search for product in shop page Before this commit, the website `/shop` page would display all published products in the db, this could cause the `website_sale_renting_planning_buy_product` tour to fail if the setup product is not in the first page. After this commit, the `/shop` page is now access with a search on the product to ensure there won't be other products in the first page. https://runbot.odoo.com/odoo/runbot.build.error/940275 Forward-Port-Of: odoo/enterprise#121342
The website editor sidebar was adjusted so it no longer becomes one pixel wider than intended at certain browser zoom levels. This prevents the page preview from switching to mobile view when users click Edit at 150% zoom, keeping the editing experience consistent.
Original PR description
Steps to reproduce: - Open a website page on Chrome/Firefox. - Set the browser zoom to 150%. - Click Edit. => The website preview switches to mobile view. Before this commit, [1] changed the sidebar to `content-box`, so the `border-start` class added one pixel to `$o-we-sidebar-width`. The sidebar then reached 289px instead of 288px, which made the preview fall below the desktop breakpoint at 150% zoom. After this commit, the sidebar width subtracts the Bootstrap border width so its total width stays at 288px and edit mode keeps the desktop view. [1]: https://github.com/odoo/odoo/commit/181b870c3c6cf28c3eac59a16c36b94ae11ae927 task-6251151 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272074
This change prevents the text selection from being reset unexpectedly when a user closes the color picker by clicking elsewhere in the editor. It makes text editing behave more reliably and consistently across browsers, especially when applying text colors in website content.
Original PR description
When a popover is used on top of an iframe, when clicking outside the popover but inside the iframe to close the popover, the click away is detected through a blur event. The close during the click…
When a popover is used on top of an iframe, when clicking outside the popover but inside the iframe to close the popover, the click away is detected through a blur event. The close during the click away is used by some features to apply the change. Setting the text color in the editor might modify the DOM structure and therefore needs to readjust the selection to match the new DOM nodes. When confirming a color, or when applying intermediary changes this behavior is required. But when the color confirmation happens because of a click away, this selection gets on the way of the selection made by clicking away. The sequence of events is as follows: - pointerdown in iframe: sets the selection based on the click - main window blur: color gets applied, and selection gets reset - pointermove in iframe: expands selection to new position This commit avoids this unwanted reset by detecting the click away through a pointerdown on the iframe - thus making the selection adjustment before the default browser handling of the event actually sets the selection on the clicked position. Steps to reproduce: - Edit a website page - Drop a text snippet - Select a word - Set a custom color using the color area - so that the color picker remains open - Click (and hold) in the empty area after the text paragraph - Move pointer by a few pixels => The text anchor remained the one of the former selection, but the focus was set according to the pointer position Note that Firefox did not blur the main window, therefore this change actually also unifies the behavior of Chrome and Firefox. The discrepancy between Chrome and Firefox's handling of the blur event in this situation seems to be related to either prioritizing the DOM specifications or the HTML specifications - and the way the are interpreted. The DOM Standard [1] relies on UIEvents [2] which states: "A user agent MUST dispatch this event when an event target loses focus." The HTML Standard defines how to compute the focus [3] and relies on nested browsing contexts [4]. Typically, the simpler readable description for developers says: "document.hasFocus() Returns true if key events are being routed through or to document; otherwise, returns false. Roughly speaking, this corresponds to document, or a document nested inside document, being focused." [1]: https://dom.spec.whatwg.org/#biblio-uievents [2]: https://w3c.github.io/uievents/#event-type-blur [3]: https://html.spec.whatwg.org/multipage/interaction.html#focus-processing-model [4]: https://html.spec.whatwg.org/multipage/document-sequences.html#nested-browsing-contexts task-6268573 Forward-Port-Of: odoo/odoo#269742
This fix ensures that Point of Sale receipts show the customer’s change as a positive amount when they pay more than the order total. It removes a misleading negative sign so receipts are clearer and more accurate for customers and staff.
Original PR description
**Issue:** The printed receipt in Point of Sale displayed a negative change amount when the customer paid more than the order total. **Before:** The receipt showed the change as a negative value…
**Issue:** The printed receipt in Point of Sale displayed a negative change amount when the customer paid more than the order total. **Before:** The receipt showed the change as a negative value (e.g., `-$5,504.00`), which was misleading for customers. **After:** The receipt now correctly displays the change as a positive value (e.g., `$5,504.00`). **Steps to Reproduce:** 1. Open a Point of Sale session 2. Add products to the cart (example total: `$49,496.00`) 3. Select the **Cash** payment method 4. Enter an amount greater than the order total (example: `$55,000.00`) 5. Observe that the **Change** field displays a negative value 6. Confirm the payment 7. Print the receipt and observe that the change amount is also negative **Root Cause:** The issue was caused by an unnecessary negation in the `export_for_printing()` method in `pos_order.js`. The `get_change()` method already returns the correct positive change amount. However, the code applied an extra negation (`-this.get_change()`), which converted the value into a negative amount before rendering it on the receipt. **Fix:** Removed the unnecessary negation in `export_for_printing()` so the receipt now displays the correct positive change amount. Video reproducing the issue: [[Click here to view the video](https://drive.google.com/file/d/1QnQ47qlTFvv98K0J_NzreBVeIh-J2XcF/view?usp=sharing)] opw-6211988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269978 Forward-Port-Of: odoo/odoo#264681
This change fixes a test in the salary configurator so it correctly includes an employee’s private address. It helps ensure the salary setup process is validated properly and avoids false test failures during development.
Original PR description
Task-6329628 Forward-Port-Of: odoo/enterprise#121626
Fixed an issue where the delivery and billing addresses chosen during checkout could be replaced later if the cart was refreshed in the background. This makes sure customers keep the address they selected, preventing incorrect order details when they finish buying quickly.
Original PR description
Steps to reproduce: =================== 1. Add several delivery addresses & billing addresses 2. Add a product to the cart and go to checkout. 3. Select a specific delivery address and a different…
Steps to reproduce: =================== 1. Add several delivery addresses & billing addresses 2. Add a product to the cart and go to checkout. 3. Select a specific delivery address and a different invoice address. 4. Pay and click "Skip" immediately on that page. 5. Open the resulting sales order. => The delivery address is reset to the company's first delivery child instead of the one selected during checkout. Root cause: =========== `partner_shipping_id` and `partner_invoice_id` are stored computed fields (compute + store + readonly=False) that depend on `partner_id`. Any write that includes `partner_id`, even writing the same value, retriggers the compute and overwrites a manually selected address with the result of `partner_id.address_get()`. `_get_and_cache_current_cart` resurrects the customer's draft cart when it is no longer referenced in the session and re-runs `_update_address(partner, ['partner_id'])` on it to refresh the pricelist and fiscal position. Clicking "Skip" runs `sale_reset()`, which clears the session cart key while the order is still draft, so the next cart access takes that abandoned-cart branch and the redundant `partner_id` write discards the selected delivery/invoice address. Waiting a few seconds lets the order reach the 'sale' state first, so the draft search no longer matches and the address is kept, which is why the issue is timing dependent. Fix: ==== In `_update_address`, when partner_id is written, keep the delivery and invoice addresses already set on the cart if they still belong to the new partner's company (same `commercial_partner_id`) by writing them in the same `write()` so the recompute does not override them. Addresses that do not belong to the new partner are still recomputed to the partner's defaults. opw-6267188 Forward-Port-Of: odoo/odoo#270300
This change stops a repetitive warning from appearing when automatic OCR is turned off. It makes uploads cleaner and reduces noise for users, without changing how documents are processed.
Original PR description
The warning "Automatic OCR does not apply to this document" was logged for every upload when automatic OCR isn't enabled, it isn't very useful. opw-[6232122](https://www.odoo.com/odoo/unassigned-tasks/6232122) Forward-Port-Of: odoo/enterprise#120741
This update corrects how one Luxembourg equity account is classified and simplifies the calculation used for the “Profit or loss brought forward” line in the balance sheet. It helps ensure the report shows the right figures more reliably for year-end accounting.
Original PR description
This commit addresses the account type for the current year earnings and simplifies the calculation for the "Result brought forward" line in the Luxembourg balance sheet reports.
Modifications:
* Changed the account type of account 142 ("Result for the financial year") from `equity_unaffected` to standard `equity`.
* Simplified the formula for the Balance Sheet line "Profit or loss brought forward" (codes `LU_BS_319` and `LU_BSABR_319`).
* The new formula simply targets the `14` accounts while explicitly excluding `142`.
Enterprise PR: odoo/enterprise#121891
Ticket [link](https://www.odoo.com/odoo/project.task/6059571)
opw-6059571
Forward-Port-Of: odoo/odoo#272362This fixes an issue where changing lot numbers on tracked products could unexpectedly alter quantities or drop reservations in stock operations. The update ensures lots stay linked correctly, quantities remain consistent, and reservations are adjusted in a predictable way when users edit delivery or receipt lines.
Original PR description
### Issue: Editing the `lot_ids` of a move of a `lot` tracked product from the picking form view leads to wildly unexpected results. This happens only with tracking by `lot` not by serial. ###…
### Issue:
Editing the `lot_ids` of a move of a `lot` tracked product from the picking form view leads to wildly unexpected results. This happens only with tracking by `lot` not by serial.
### Concrete Issue 1:
1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Create and confirm a delivery for 5 units of P
4. Set the quantity of the move to 5 from the Form picking view > save
5. Create and set 2 lots: LOT1, LOT2 on the serial numbers field
6. Save
#### > The quantity of the move has been updated to 2, only the first lot is set and it has been for this quantity of 2
### Concrete Issues 2 and 3:
1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Update the onhand quantity of P:
- 1 units of LOT001 in Shelf1
- 2 units of LOT001 in Shelf2
- 2 units of LOT002 in Stock
4. Create and confirm a delivery for 5 units of P
5. Remove LOT002 from the Serial numbers in the Form picking view > save
#### > The quantity of the move is updated to 1 (only the 1 unit of LOT001 from Shelf2 is kept)
5'. Remove LOT002 and put it back
#### > The quantity is updated from 5 to 2 if you save, only LOT001 is kept.
### Cause of the issue:
The `_onchange_lot_ids` and `_set_lot_ids` methods have been tailored to work appropriately only with `serial` tracking, updating the quantities considering a 1 to 1 quantity, lot matching:
https://github.com/odoo/odoo/blob/c9715982134220aa8fa525d0cf6a8d47eaeb6ed6/addons/stock/models/stock_move.py#L623-L645
However, for lot tracked product the situation is much more subtle to handle.
### Behavior after the fix:
Editing the `lot_ids` on tracked products should adapt the reservation following these rules:
- Existing move lines with a valid lot or lot name should be kept unchanged.
- Removing a lot should delete its related move lines and adjust the move quantity accordingly.
- Each newly assigned lot must be linked to at least one move line of the move.
If the move is expected to bypass reservation (e.g. receipts, final move of a production,...):
- Assignment should be performed, in priority, on an existing free move line.
- If no suitable free move line exists, a new move line should be created with the largest possible quantity that does not cause the total assigned quantity to exceed the move demand.
- If such a quantity cannot be assigned, the new move line should be created with a quantity of 1 in the product.uom_id.
If the move is expected to be reserved (e.g. internal transfer, deliveries,...):
- Each new lot should be assigned from an existing quants with the maximum available quantity to satisfy at best the remaining demand.
- If no available quantity can be assigned from existing quants, the lot should be assigned a minimum quantity of 1 in product.uom_id.
### Additional note on the fix:
Since move that do bypass reservation use a different detailed operation view relying on lot_names form move line rather than lot_id from existing quants it is important to set both the `lot_name` as well as the `lot_id` on move lines for the changes to be visible in the detailed operations view.
### Note:
The current fix populated records on which the `label_production_view_pdf` report was tested (by the test_report) highlighting a template error:
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/mrp/report/mrp_production_templates.xml#L187
The value provided to the t-field being something else than a field but rather an or close between two fields.
opw-6173914
opw-5881661
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#263037This change prevents text styling from being applied outside the editable area in the website editor. As a result, formatting changes such as font size are now saved correctly in website builder and translation views.
Original PR description
Commit e0cf601ab6fc1d7cb007fcb16ee4bb6097ba6fdd added a condition to apply format on the parent of fully selected unsplittable nodes. But this could lead to format applied outside of `contenteditable=true` nodes in some cases of website builder. This commit adds a condition to only apply format outside the unsplittable if it is not the node with `contenteditable`. Steps to reproduce: - In event page, open website builder - Double click on "Starts" in the sidebar inside the event page - Change font size - Save - Bug: the changed font size is not save (a span with the font class was created outside the savable element) ### - In translate mode - Select a whole translation span - Change font size - Save - Bug: the changed font size is not save (the font class was added on the translation span) task-6308352 Forward-Port-Of: odoo/odoo#271888 Forward-Port-Of: odoo/odoo#270401
This update fixes how a year-end earnings account is classified in Luxembourg accounting, so it is treated like a standard equity account. It also simplifies the balance sheet formula for carried-forward profit or loss, which helps ensure the report shows the correct amount more reliably.
Original PR description
This commit addresses the account type for the current year earnings and simplifies the calculation for the "Result brought forward" line in the Luxembourg balance sheet reports.
Modifications:
* Changed the account type of account 142 ("Result for the financial year") from `equity_unaffected` to standard `equity`.
* Simplified the formula for the Balance Sheet line "Profit or loss brought forward" (codes `LU_BS_319` and `LU_BSABR_319`).
* The new formula simply targets the `14` accounts while explicitly excluding `142`.
Community PR: odoo/odoo#272362
Ticket [link](https://www.odoo.com/odoo/project.task/6059571)
opw-6059571
Forward-Port-Of: odoo/enterprise#121891Scheduling a document activity from several records at once could fail with an error. The system now correctly checks each selected record, so users can schedule activities in bulk without interruption.
Original PR description
### Steps to reproduce: - Install 'Accounting' - From 'Accounting' > 'Journal Entries', Select multiple records from the list view. - Try to schedule a 'Document' activity. > Traceback: `KeyError:…
### Steps to reproduce:
- Install 'Accounting'
- From 'Accounting' > 'Journal Entries', Select multiple records from the list view.
- Try to schedule a 'Document' activity.
> Traceback: `KeyError: account.move(X, X)`
### Cause of Issue:
When scheduling an activity for multiple records, `_onchange_activity_user_id` calls `_mail_get_operation_for_mail_message_operation('create')` on the entire batch of records. This method returns a dictionary mapping *individual* records to their required operations. However, then it was attempted to retrieve the operation values using the whole thread (which now contains 2 records) as a key causing a `KeyError` since only individual records existed as keys. https://github.com/odoo/odoo/blob/337efb069f6cf2cb9478a970f075fd139c1e8e0a/addons/mail/wizard/mail_activity_schedule.py#L463
### Fix:
For each required operation type, filter the records requiring it from the `thread` recordset and evaluate `check_access` on those specific records, making access checking efficient.
opw-6290303
Forward-Port-Of: odoo/odoo#270277This update removes a receipt customization that pointed to an element no longer used in the standard point of sale receipt. It ensures the Belgian black box receipt continues to work correctly after the receipt layout change, avoiding display or rendering issues.
Original PR description
In the community point_of_sale module, the `<t id="tax_base">` element was removed from the order receipt template in order to restore the 19.0 tax summary design (always displaying the tax base). Remove the xpath in pos_blackbox_be that was targeting this deleted element. task-id: 6296906
This update makes reset (neutralized) databases use the test VAT validation service instead of the live production one. It helps avoid sending unnecessary checks to the real external service, while leaving any custom setup unchanged.
Original PR description
Neutralized databases don't always have demo data, so they talk to production VIES endpoint. With this change, the production endpoint is replaced with the test one. If some database has a custom endpoint, nothing is done. @moduon MT-15142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272036
When an email from a mass mailing campaign bounces, the contact’s bounce count is now updated reliably. This fixes cases where bounce notifications came from a different sender address, which previously caused some bounces to be missed.
Original PR description
Previously, when a mailing campaign sent out an email to a mailing.contact, and that email bounced, the bounce would not increment the contact's bounce count. This commit makes it so that the bounce count is correctly updated when a mailing campaign sends an email that bounces. task-4893615 Forward-Port-Of: odoo/odoo#226362
This change stops private tasks from being used as parent tasks in projects. It helps avoid accidental exposure or linking of tasks that should remain restricted, keeping task hierarchies more consistent and secure.
Original PR description
In this commit, we ensure that private tasks can never be selected as parent tasks. task-5119141 Forward-Port-Of: odoo/odoo#272263 Forward-Port-Of: odoo/odoo#270795
Swiss sales invoices now generate a payment reference even when the customer is outside Switzerland or Liechtenstein, as long as a QR-IBAN is configured. This ensures the invoice PDF continues to display payment communication and bank details, making it easier for customers to pay correctly.
Original PR description
Issue: When an invoice (sales journal) uses "Switzerland" localization and the invoice is issued to a customer outside Switzerland/Liechtenstein, no payment reference is generated. This causes the…
Issue: When an invoice (sales journal) uses "Switzerland" localization and the invoice is issued to a customer outside Switzerland/Liechtenstein, no payment reference is generated. This causes the invoice PDF to hide payment communication and bank account details. Other localizations like Belgian companies, uses Belgian references, the reference is always generated regardless of customer country. Steps to reproduce: - Configure a Swiss company with a QR IBAN bank account - Set the sales journal Communication Standard to Switzerland - Create and confirm an invoice for a non swiss customer (US, BE) - Observe in the pdf and in the other info tab -> no payment reference or payment details Cause: `get_l10n_ch_qrr_number()` was using on `l10n_ch_is_qr_valid()`, which conflicts QR-bill printability (partner country, currency) with payment reference generation. When the customer is outside CH/LI, `l10n_ch_is_qr_valid()` is False and no QRR reference is generated. Solution: Decouple QRR reference generation from QR bill printability. The Swiss communication standard now generates a QRR format reference when a QR-IBAN is configured, regardless of customer's country or currency. opw-6222417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266861
Documentation and clarification updates
This change adds a signed Odoo Individual Contributor License Agreement for David Sonnet. It is an administrative/legal update that allows the contributor’s work to be accepted under Odoo’s contribution process, with no functional impact on the product.
Original PR description
Signing the Odoo Individual Contributor License Agreement v1.0. Adds `doc/cla/individual/dsonnet.md`. --- I confirm I have read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270526
Miscellaneous changes
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
2 changes
Enhancements to existing features
This update adds missing translations across Point of Sale screens, dialogs, alerts, and error messages. It helps users in different languages understand prompts and issues more clearly, improving the overall POS experience.
Original PR description
pos* = All POS module In this commit: -------------------------------- Add missing translations for user-visible strings across POS modules. - Translated dialogs, errors, alerts, and other UI-visible messages - Updated Python-side UserError, ValidationError, and warning messages Task-5406947 Related PR-https://github.com/odoo/odoo/pull/239972 Forward-Port-Of: odoo/enterprise#121690 Forward-Port-Of: odoo/enterprise#102094
Resolved issues and error corrections
When a new file is uploaded in Documents, its action buttons now appear right away. This removes the need to deselect and reselect the file just to access common actions, making the workflow smoother and faster.
Original PR description
Bug === When uploading a new file in documents, it's selected, but the actions are not visible (we need to unselect - select the record to see the actions). Task-5408471 Forward-Port-Of: odoo/enterprise#114770
9 changes
Enhancements to existing features
When a leave update fails, the system now provides more useful details about which employee’s leave caused the issue. This makes it much easier for customers and support teams to identify and resolve allocation or time-off balance problems without manually checking every record.
Original PR description
The current message is pretty useless as of now when a lot of leaves are being written to, notably when creating a public holiday, which sets the state of all the leaves overlapping the public holiday's day to be reevaluated, and if an error occurs, you have to go through every employee's leave allocation and leaves taken to hopefully find one who might have to many days taken/not enough allocated. This extra information will be a huge QOL improvement, for the customer who will be able to troubleshoot his issue himself more easily, but also for our support team as the only way to debug those kind of issues now is to put a breakpoint there and see what employee has an issue. opw-4411999 Forward-Port-Of: odoo/odoo#270888 Forward-Port-Of: odoo/odoo#200376
This change lets operators adjust how long unused database connections stay open. It helps systems with limited memory release idle connections sooner, which can improve stability and reduce resource usage.
Original PR description
In memory-scarce environments, the default 10-minute idle timeout may keep too many backend connections alive. Allow operators to override it via the ODOO_DB_MAX_IDLE_TIMEOUT environment variable to evict idle connections more aggressively. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271785
Resolved issues and error corrections
Users can now remove the currency selection in the payment register without triggering an error. This fixes a crash in the Argentine withholding flow and makes the payment process more reliable for affected companies.
Original PR description
When the user removes the currency from the payment register, a traceback is raised. Steps to reproduce the error: - Install ``l10n_ar_withholding`` module - Switch to ``(AR) Exento`` company - Create a new invoice > Confirm > Pay > Unset the currency Traceback: ```py ValueError: Expected singleton: res.currency() ``` https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/l10n_ar_withholding/wizards/account_payment_register.py#L27 This line causes a traceback with an empty currency when the user removes the currency from the payment register. sentry-7362499567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255825
This fix ensures that when a dropship delivery is only partially completed, the inventory valuation is calculated using the delivered quantity instead of the originally planned quantity. As a result, accounting values now match the actual goods received and prevent overstated costs.
Original PR description
**Problem:** partial quantities in a dropship picking is not taken into account for the svl quantity (it's always the full initial quantity) **Steps to reproduce:** - create a storable product with…
**Problem:** partial quantities in a dropship picking is not taken into account for the svl quantity (it's always the full initial quantity) **Steps to reproduce:** - create a storable product with dropship route - set the category as avco auto - set a vendor in the purchase tab with a price of 10 - confirm a SO for a quantity of 2 - confirm the related PO with a unit price of 10 - on the dropship picking change the quantity to 1 - validate without backorder - click on the valuation smart button **Current behavior:** - the svls have quantities of 2 and -2 - the related amls have debit/credit of 20 **Expected behavior:** - the svls should have quantities of 1 and -1 - the related amls should have debit/credit of 10 **Cause of the issue:** when creating the svls we use the move's product_qty instead of its quantity https://github.com/odoo/odoo/blob/c97629d5efb82aed191de211593c539686cae65b/addons/stock_account/models/stock_move.py#L290 **fix:** product_qty is expressed in the uom of the product and quantity in the uom of the move so we need to add a uom conversion to the fix opw-6113031 Forward-Port-Of: odoo/odoo#271531 Forward-Port-Of: odoo/odoo#270823
This fix ensures that attendees see the proper success message after completing a website event quiz. It improves the clarity of the user experience by showing the right confirmation message at the right time.
Original PR description
opw-6332274 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272371
Imported bill quantities are now handled with the correct precision when matched to a purchase order. This prevents small rounding errors that could slightly overstate the invoiced amount, such as turning 1800.0 into 1800.01.
Original PR description
When importing an XML bill and linkin git to a purcahse order, the invoiced quantity may be computed incorrectly, due to a decimal precision mismatch. Steps to reproduce: - Import an XML bill having a line with quantity 1800.0 - Link to a purchase order with the same line Issue: The invoiced quantity will be computed with 1 cent difference (1800.01) Analysis: Because the system forced a decimal precision of 13 for 'Product Unit of Measure', quantity is imported as 1800.0000000000016. Later, when computing the invoiced quantity, the system round the quantity using 'UP' strategy, rounding the amount to 1800.01 opw-6194824 Forward-Port-Of: odoo/odoo#270916 Forward-Port-Of: odoo/odoo#266283
This update fixes a bug in the rich text editor that could cause an error when users inserted a file and then used editor commands. It also improves how the editor keeps track of selections during paste actions, making editing more reliable and preventing unexpected interruptions.
Original PR description
### Steps to reproduce: - Insert a file using /file command and upload a file. - Type any powerbox command (e.g. /file, /media) - Press Enter to select the command - IndexSizeError: Failed to execute…
### Steps to reproduce: - Insert a file using /file command and upload a file. - Type any powerbox command (e.g. /file, /media) - Press Enter to select the command - IndexSizeError: Failed to execute 'setBaseAndExtent' on 'Selection': There is no child at offset 5. ### Description of the issue/feature this PR addresses: - makeSavePoint() of history_plugin uses preserveSelection() to save current selection. However, preserved selections remain registered in the cursor update mechanism and continue to be updated when the editor adjusts cursors during DOM changes. - During normalization, updateFeffs() updates all preserved cursors. Because the savepoint selection is stored using preserveSelection(), it is updated as well and can become inconsistent with the DOM state that the savepoint later restores, resulting in an IndexSizeError. ### Solution (backport-https://github.com/odoo/odoo/commit/1eb0e6de8f566d260ecb6c0dae3436e87ffe8436): - Update preserved cursors after steps restoration so they stay in sync with the restored DOM state. - Stage the selection in the clipboard plugin after `before_paste_handlers`, ensuring the selection reflects the final adjusted state before pasting. - Fix `selectFullText` to trigger `pointerup` to have a correct staged selection. task-6298761 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270085
The website profile banner now uses the currently logged-in user when checking email validation status. This prevents another person's private email address from appearing on public forum profile pages.
Original PR description
**Steps to reproduce:**
- Install website_forum module
- Create a new portal user and log in with it
- Go to the website forum to see that the account requires email verification
- Send the verification email to see the green banner ('an email was sent to XX')
- Add XP (karma) points to this user as admin (User > Smart actions > Karma)
- Switch back to the portal account
- Check any public user profile on the forum (`/profile/user/2?forum_id=2`)
- Green banner now displays the private email of the user you're checking
**Issue:**
On the `email_validation_banner` the user field is used for the validation
data, but it is overridden by `_prepare_user_profile_values` which is
setting the current page user.
**Fix:**
Properly set `user` to `env.user` in the template.
opw-6276809
Forward-Port-Of: odoo/odoo#269249Documentation and clarification updates
This change adds a signed Individual Contributor License Agreement for David Sonnet. It is an administrative/legal update that allows the contribution to be accepted and tracked properly, with no functional impact on users.
Original PR description
Signing the Odoo Individual Contributor License Agreement v1.0. Adds `doc/cla/individual/dsonnet.md`. --- I confirm I have read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270526
1 change
Enhancements to existing features
This change ensures only real buyer address details are sent to Fiskaly when they are available. If address information is missing, the system now omits those fields instead of sending placeholder values like "N/A", reducing the risk of inaccurate compliance data.
Original PR description
In this commit: ------------------- - Buyer address fields are optional and should only be sent to Fiskaly when they are actually available. - Avoid sending placeholder values like "N/A". If the data is not present, the fields should simply be omitted from the request. task: 6113133 Forward-Port-Of: odoo/enterprise#113621
10 changes
New functionality added to Odoo
This adds an Elster integration so users in Germany can submit tax returns directly from Odoo. It reduces manual work by connecting tax reporting in Odoo with the official filing flow, provided the required IAP service is deployed first.
Original PR description
This module enables users to submit their tax returns to Elster directly from Odoo. see IAP: https://github.com/odoo/iap-apps/pull/1513 ( must be deployed first ) task-5193637
This update adds demo data so repair task examples come with products already available to select. It helps users explore the feature more easily and makes demonstrations and testing more realistic.
Original PR description
Add demo data for products to pick up on tasks Task-3765169
Enhancements to existing features
The search dropdown in Web Studio now stays in the correct state when users click the search field while it is already open. This prevents the menu from closing and immediately reopening, making the interface feel more stable and predictable.
Original PR description
When clicking on the search input while the search dropdown is already open, it closes it on pointer-down and reopens it on pointer-up. This commit fixes the issue with a check on a data attribute. task-6190769
Resolved issues and error corrections
When a new language is installed, the DIAN email templates will now be translated automatically. This fixes a gap that only affected languages added after the Colombian electronic invoicing module was already in place, so users will see the templates in their chosen language without extra manual work.
Original PR description
### Issue: When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated Languages already installed when `l10n_co_dian` is installed are correctly…
### Issue: When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated Languages already installed when `l10n_co_dian` is installed are correctly translated, as the copy happens at that moment Only languages installed afterwards are affected ### Cause: The DIAN email templates are created dynamically via `_create_dian_mail_templates` as copies of the `account` templates Because they are created at runtime, no translations exist for their XML IDs in the `l10n_co_dian` `.po` files The `TranslationImporter` finds nothing to import for them The fix hooks into `_load_module_terms` to sync translations from the source `account` templates to the DIAN ones whenever a new language is installed `TranslationImporter.save()` is used without `force_overwrite`, so existing translations on `noupdate` records are never replaced This is the standard way to push translations while preserving any manually modified values ### Notes: Languages installed before this fix are not updated Only newly installed languages will get the synced translations ### Steps to reproduce: - Install `l10n_co_dian` - Enable Developer Mode in Settings - Install any language (e.g. `fr_FR`) - Go in Settings > Technical > Email > Email Templates - Search for DIAN and open Invoice or Credit Note Before the fix, the DIAN invoice and credit note templates had untranslated name, description and body_html opw-6269979 Forward-Port-Of: odoo/enterprise#120855
Users can now sort project tasks by Planned Date in the portal without encountering an error. This resolves a broken sorting option so project teams can browse tasks more reliably.
Original PR description
Currently, an error occurs when a user sorts tasks by Planned Date. **Steps to reproduce:** - Install the `project_enterprise` module with demo data. - Go to Projects in the portal (`/my/projects`),…
Currently, an error occurs when a user sorts tasks by Planned Date. **Steps to reproduce:** - Install the `project_enterprise` module with demo data. - Go to Projects in the portal (`/my/projects`), open any `project`, and sort the tasks by `Planned Date`. KeyError: 'order' After a [recent change], the sort order is retrieved from searchbar sortings. When sorting by Planned Date, it attempts to access the order key from the corresponding sorting configuration [1]. However, the planned_date_begin entry does not define an order key [2], which raises error when it tries to access order. This commit ensures that the order key is added with its value for planned_date_begin in searchbar sorting. [recent change]: https://github.com/odoo/odoo/commit/8be5dacf9fbfe8c23b04c876994bea2ce7cbb89a [1]: https://github.com/odoo/odoo/blob/2ae9b57b86cd0bc4816ff8ec207564631baa8ad6/addons/project/controllers/portal.py#L424 [2]- https://github.com/odoo/enterprise/blob/9dd3a9b2c09a6d23a3f71d3e531edd6d78b30277/project_enterprise/controllers/portal.py#L8-L11 sentry-7556050938 Forward-Port-Of: odoo/enterprise#121230 Forward-Port-Of: odoo/enterprise#121141
The Documents quick button on an employee form now opens in the same page instead of launching a new one. This makes navigation smoother and avoids interrupting the user’s workflow.
Original PR description
Issue: ---------------------------------------- When on an employee form, clicking the "Documents" button opens a new page instead of staying on the same. Steps to reproduce: ---------------------------------------- - Install `documents_hr` - Go on an employee form - Click the "Documents" button - It opens a new page Cause: ---------------------------------------- The `'ir.actions.act_url'` opens a new page by default. Solution: ---------------------------------------- Add `'target': 'self',` to make it open the URL in the same page. opw-6284677 Forward-Port-Of: odoo/enterprise#120285
This update prevents errors when Shopee sends customer identifiers that are larger than the system expected. If an ID is too large to fit in the usual field, it is now stored and matched in a different customer reference field so contacts can still be created correctly.
Original PR description
When the Shopee connector was introduced, Shopee documented `buyer_user_id` as an int32. We therefore store it in an `Integer` field, which maps to a PostgreSQL int32 column. However, feedback showed that Shopee can send ids exceeding the int32 bounds, leading to a traceback when creating new contacts. Shopee has since updated their documentation to confirm the field is actually an int64. Since we are in stable and cannot change the column type, this commit falls back to the `ref` field of the `res.partner` model to store and match Shopee contacts whose identifier doesn't fit within an int32. opw-6325948 See also: - master: https://github.com/odoo/enterprise/pull/121507 - upgrade: https://github.com/odoo/upgrade/pull/10578 Forward-Port-Of: odoo/enterprise#121707 Forward-Port-Of: odoo/enterprise#121498
This fix prevents the AI from appearing to create project tasks twice when a creation request hits an error. It now checks that the required information is valid before showing the preview or confirming the action, which makes the user experience more reliable and avoids duplicate-looking prompts.
Original PR description
This commit removes an issue where the LLM would retry on error when performing a creation which would give the impression that it created items twice. To do so, this commit now validates that the fields exists before calling the `create()` method, and before showing the preview to the user. Ensuring it avoids throwing an error after the message has been confirmed (resulting in the double preview). task-6229596 Forward-Port-Of: odoo/enterprise#118044
This change makes sure only users with the proper accounting permissions can access detailed move line data in reports. It closes a gap where some users could reach the model but still rely on filtering rules that were no longer enough, improving protection of sensitive accounting information.
Original PR description
Using check_access on the model alone is not enough, as some groups (like portal) could have access to the model itself but rely on record rules (which we now bypass) for filtering access to actual records. This check is there for extra-safety (the access rules to account.report should anyway prevent access) ; we fix it by explicitly checking the user has the proper accounting groups. Forward-Port-Of: odoo/enterprise#120749
This update fixes a timing issue in the WhatsApp channel test so the system waits for the connection to be ready before sending the seen-status update. As a result, the test can reliably confirm that seen indicators appear correctly, preventing false failures in validation.
Original PR description
The "Allow SeenIndicators in WhatsApp Channels" test delivers the seen update over the bus with `_sendone`, but nothing waited for the websocket to subscribe to the channel first. When the notification was sent before the subscription landed it was dropped, the member's seen_message_id was never updated client-side and the seen indicators never rendered, so the assertion timed out. The current user is a member of the channel, so it is subscribed at connection time: wait for the subscription together with `start()` (listener registered first) before opening the channel and sending the notification. https://runbot.odoo.com/odoo/error/242021 Forward-Port-Of: odoo/enterprise#121857
12 changes
Enhancements to existing features
This change lets operators adjust how long unused database connections stay open. It helps reduce memory usage in environments with limited resources by closing idle connections more aggressively when needed.
Original PR description
In memory-scarce environments, the default 10-minute idle timeout may keep too many backend connections alive. Allow operators to override it via the ODOO_DB_MAX_IDLE_TIMEOUT environment variable to evict idle connections more aggressively. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271785
Polish invoices sent outside KSeF now include a QR code and the KSeF reference number on the PDF. This helps recipients quickly verify and access the invoice information in line with local invoicing requirements.
Original PR description
While communicating outside KSeF, invoices must have a QR Code and their KSeF number displayed. QR Code content spec is available here: https://github.com/CIRFMF/ksef-api/blob/main/kody-qr.md task-6334901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix ensures users see the appropriate success message after completing an event quiz. It improves the post-quiz experience by making the confirmation message match the actual outcome, reducing confusion for participants.
Original PR description
opw-6332274 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272371
The report editor in Studio now keeps the translation button enabled when editing report sources. This makes it easier for users working in multiple languages to translate report content without the button appearing disabled.
Original PR description
The translate button greys itself when isClickable is false. The report editor reuses that button with its own component and always edits an existing ir.ui.view, so it defines isClickable returning true to stay active. Steps to reproduce: 1. Activate a second language in Settings > Translations > Languages 2. Open any report in Studio and edit its sources with the XML editor => The translate button next to the resource selector looks greyed out Ticket [link](https://www.odoo.com/odoo/project.task/6260427) opw-6260427
This fix ensures that once an appointment is canceled, it no longer prevents the available capacity of a resource from being reduced. As a result, users can update resource availability without running into an error caused by bookings that are no longer active.
Original PR description
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type using resources 3. Create a resource with capacity `4` 4. Book an appointment on that resource with reserved capacity `4` 5.…
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type using resources 3. Create a resource with capacity `4` 4. Book an appointment on that resource with reserved capacity `4` 5. Try to reduce the resource capacity 6. Cancel the appointment 7. Try again to reduce the resource capacity Current behavior: - Reducing the resource capacity raises: `The capacity used can not be lesser than the capacity reserved` Issue: - Canceled appointments still prevent lowering the resource capacity, even though the booking is no longer active. Cause: - Canceling an appointment only archives the related `calendar.event`, it does not remove the corresponding `appointment.booking.line`. That booking line keeps its previous `capacity_reserved` value, while `capacity_used` is a stored computed field depending on the resource capacity. When the resource capacity is reduced after cancellation, the archived booking line is recomputed with the new lower resource capacity and this violates the SQL constraint Solution: - For inactive booking lines: Set `capacity_used = capacity_reserved` opw-6036053
Spreadsheets now block inserting pivots that rely on unsupported relationship fields, avoiding errors caused by non-numeric record IDs. Users will see the insert option disabled with a helpful message, so they know why the pivot cannot be added.
Original PR description
Prevent inserting a pivot into a spreadsheet when it contains groupbys on relations whose IDs are not numeric (e.g. account.root uses string IDs), as the pivot table engine does not support them. The insert button is now disabled with an appropriate tooltip. Task: 6023622
When opening a customer from an invoice or similar form, the page title and breadcrumb will now show only the customer name, not the full multiline address. This makes the navigation area much cleaner and easier to read.
Original PR description
- Create a new Invoice; - Assign a Customer with a multiline address; - Click on the internal link (arrow icon) of the Customer field. Before this commit, the form view title and the breadcrumb would contain not only the customer's name but also their full address. This resulted in an excessively large and unreadable breadcrumb. Now, only the name is retained. This commit applies the same behavior already used in many2one fields: the display name is split by line breaks, and only the first line is kept for the title and breadcrumb. task-id 6329662 Forward-Port-Of: odoo/odoo#272059
This fix makes the UNSPSC code 10171500, "Organic fertilizers and plant nutrients," available again in the product accounting list. It matters because users relying on product classification can now find and select the correct code for their products.
Original PR description
The code 10171500 - Organic fertilizers and plant nutrients wasn't appearing. In the file that has the unspsc product codes this one was set to False. Steps to reproduce: - Activate module product_unspsc. - Go to product > accounting. - Verify that this code is not listed. Ticket [link](https://www.odoo.com/odoo/project.task/4461974) opw-4461974 Forward-Port-Of: odoo/enterprise#121914
This update prevents the Balance Sheet report from crashing when an analytic account is selected. It removes an unnecessary check that was causing the system to loop until it hit a recursion error, improving report reliability for users working with analytic accounting.
Original PR description
Steps to reproduce ================== - Activate Analytic Accounting. - Go to Accounting > Accounting > Reconcile. - Open Studio. - Add a new many2many field. - Set Journal Item as the related model. - Go to Reporting > Balance Sheet. - Select an analytic account. => RecursionError: maximum recursion depth exceeded Cause of the issue ================== Calling `self.env['account.move.line'].fields_get()` will cause a recursion error. `account.report::_prepare_lines_for_analytic_groupby()` calls `account.move.line::_where_calc()` which in turns calls _prepare_lines_for_analytic_groupby again Solution ======== It turns out we don't actually need to retrieve the groupable attribute, thus bypassing the error. opw-6129149
This fix ensures card payments made in Point of Sale are marked as paid once the session is closed and the payment has been reconciled. It prevents customer payments from remaining stuck in the “In progress” status in Accounting, improving payment tracking and reducing manual follow-up.
Original PR description
**Steps to reproduce:** - Go to the PoS, make a sale, pay by card - Close the session - Go to the accounting module, customer, payment - The payment is stuck in the "In progress" stage **Why the fix:** The bank payments' state were never taken into account and never changed so it stayed in the 'in_process' state. The _compute_state() function in the account module that is supposed to take care of this does nothing for the bank payments from the PoS, because it only checks if the liquidity is equal to zero, which does not happen in this context. It should happen when we manually matching payments and that's how it's used in the Account module, but it's not compatible with the PoS session closure. We now change the payment's state to paid if the payment has been reconciled at the session's closure. opw-5438029
Instagram posts with images will now fail cleanly instead of causing the server request to crash when the network times out. This improves reliability and gives users a clearer failure message, including guidance to use a smaller image when the issue is likely caused by image size or processing time.
Original PR description
Making an Instagram containing an image can crash the server with an unhandled `ReadTimeout` instead of marking the post as failed. ### Cause When creating a media container, Odoo passes a URL pointing to its own server and Instagram fetches the image from it server-side before responding. The timeout therefore covers network latency, Instagram's download speed from the Odoo server, and image processing time, making it prone to being exceeded. When it is, `requests` raises a `ReadTimeout` which is unhandled, leading to a raw RPC error instead of a clean `state='failed'`. ### Fix Catch the network errors and mark the post as failed instead of letting them crash the request. Timeouts get a message suggesting a smaller image, since they are usually caused by Instagram fetching and processing a large image server-side. Any other request error falls back to a generic message. opw-6015997
Documentation and clarification updates
This change adds the contributor’s signed Odoo Individual Contributor License Agreement to the repository. It is an administrative/legal update that confirms the contribution can be accepted under Odoo’s licensing terms.
Original PR description
Signing the Odoo Individual Contributor License Agreement v1.0. Adds `doc/cla/individual/dsonnet.md`. --- I confirm I have read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270526
4 changes
Resolved issues and error corrections
This change fixes the message shown to users after they complete an event quiz, so they now see the correct success confirmation. It improves the user experience by making the completion result clear and accurate.
Original PR description
opw-6332274 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272371
Users can now rename custom fields in Studio using labels written in scripts like Arabic without triggering an invalid technical name. This avoids a confusing error and makes field customization work more smoothly for multilingual teams.
Original PR description
Steps: - Install web_studio - Add any field (example char field) to any view - Rename it in arabic, example `السَّلَامُ عَلَيْكُمْ` - Error Custom field names cannot contain double underscores Webclient (view_editor_model) escape every non-alphabetic chars, so new label value contains nothing but a space which will be replaced by a _ this new label value will be concatenated to `x_studio_`. Resulting to the string `x_studio__`. A solution should be to prevent changing the technical name if the new label value (escaped) is empty. opw-6311027
This fix ensures the SAF-T export uses the proper account grouping code instead of cutting the value incorrectly. It prevents reports from showing the wrong grouping number, helping keep accounting exports aligned with official requirements.
Original PR description
Steps to reproduce: - change 1920 Banck account to 19204321 - go in general ledger and export to "SAF-T" Issue: The grouping code is 4321 Grouping code should match official grouping code. As a matter of fact the chart of account seems to match thos grouping account if we slice them correctly. opw-6285078
This change prevents the Spanish Veri*factu* e-invoicing module from running into memory or timeout issues during installation on databases that already contain accounting entries. It makes the setup process more reliable and reduces the risk of failed installs for existing customers.
Original PR description
### Description: When trying to install the module `l10n_es_edi_verifactu` on a database that already has moves, it is possible to encounter a timeout or a memory error. This is caused by the compute `l10n_es_edi_verifactu_state` and `l10n_es_edi_verifactu_clave_regimen`, both compute linked to the new model `l10n_es_edi_verifactu.document`. ### Reference: opw-6293590