Saturday, September 13, 2025
32 changes · 19.0
Enhancements to existing features
Record creation is now faster when large HTML content is involved, such as marketing emails. The change avoids repeating an expensive processing step, reducing campaign processing time and memory use while keeping stored content properly cleaned.
Original PR description
Description ----------- When creating records with `vals` for HTML fields, there are two 'sanitization' operations happening: 1) Once in `convert_to_column`, when converting the `vals` for *database*…
Description ----------- When creating records with `vals` for HTML fields, there are two 'sanitization' operations happening: 1) Once in `convert_to_column`, when converting the `vals` for *database* insertion 2) Once post-insert in `convert_to_cache`, when converting the `vals` for insertion in the *cache* for the newly created records. This redundancy has a negative performance impact when creating many records where new HTML fields are set, e.g., mass-mailing, as potentially large HTML documents are parsed and validated, often with external libraries. To address this issue, this commit removes the insertion into *cache* of the HTML values for the newly created records. This removes the overhead of the second sanitization, speeding up the creation, and also helps with overall memory pressure, as we're not inserting large HTML fields into cache. The latter is particularly noticeable for long-running batch creation processes that do *not* commit intermediate results. The downside of this patch is the potential *cache-miss* (and therefore the subsequent *query*) if the HTML field of the newly created records is read. This is unlikely in business code because intrinsically, an HTML field is often just a data 'blob' that has no logical usage. In the rare case where it needs to be read after creation, since the value in the database is already sanitized, re-sanitization is not necessary for insertion in the cache. Given these considerations, the trade-off seems reasonable to make. Benchmark --------- In a scenario for a marketing campaign with 1000 recipients, using a *mid-sized* email template and emulating a typical campaign, the results were: | Method | Before | After | Speed up | |-------------------------------|----------|-----------|----------| | `_process_mass_mailing_queue` | 2.84 min | 1.55 min | 1.8x | | `create` | 2.11 min | 50.23 sec | 2.5x | This represents roughly a *2x* performance improvement in processing an email campaign. * more detailed benchmarks are available in the task's description Reference --------- task-4962646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225207 Forward-Port-Of: odoo/odoo#223875
Payroll contract templates now copy the right country-specific fields when creating employee contracts. This helps reduce missing local payroll details and improves consistency across supported country payroll setups, with tests added to confirm the behavior.
Original PR description
This commit implements _get_whitelist_fields_from_template() method across all HR payroll localizations to ensure that localization-specific fields are properly copied when creating contracts from templates. Additionally, comprehensive test coverage has been added for all localizations to validate the whitelist functionality and ensure proper template loading behavior. task-4954283 X-original-commit: b6c5609de48e631f1a7158f6c91fea35e97d4b78
Odoo notifications have been redesigned to be smaller, clearer, and more consistent across apps. They now include a progress bar so users can see when temporary messages will disappear, improving usability without changing core business workflows.
Original PR description
A big part of the notification behaviour that was in the notification service has been move to the component "Notification". With this comes also a visual cleaning of the notification. Smaller, more compact and with a progress bar that show when the notification will disappear. TASK-ID: 4334047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Notifications have been redesigned to be smaller, clearer, and less distracting across the application. Users can now better understand when temporary messages will disappear thanks to a visible progress indicator, improving day-to-day usability.
Original PR description
A big part of the notification behaviour that was in the notification service has been move to the component "Notification". With this comes also a visual cleaning of the notification. Smaller, more compact and with a progress bar that show when the notification will disappear. TASK-ID: 4334047
The Barcode app now better supports putting packages inside other packages, including scanning multiple packages into a larger package and unpacking them when needed. Package lines are grouped and labeled by their full outer package structure, making warehouse operations clearer and reducing handling mistakes.
Original PR description
Add some improvement for the pack in pack feature in the Barcode app, like an "Unpack" button or the package lines groupement by their outermost package dest. See commits' message for more details. [task-5065193](https://www.odoo.com/odoo/966/tasks/5065193)
Clicking an @mention in Mail now opens the person's avatar card instead of taking the user directly to a chat. This helps users view relevant contact details while staying in their current conversation or workflow.
Original PR description
Purpose of this commit: Previously, clicking on an @mention would navigate the user directly to a chat session with the corresponding partner. This commit changes that behavior to open the partner's avatar card popover instead, giving the user immediate access to more detailed information without leaving the current context. task-3816952 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Peppol connections in neutralized databases are now kept fully offline for existing records, preventing failed or unintended network calls. New Peppol connections from those databases are directed to the test network, and support teams get clearer debug information about connection mode and type.
Original PR description
Previously existing Peppol connections were only switched to `test`. This is not enough and incorrect: - someone connected in production does not necessarily have a registration on the test network,…
Previously existing Peppol connections were only switched to `test`. This is not enough and incorrect: - someone connected in production does not necessarily have a registration on the test network, therefore the database is in an inconsistent state, and calls to the test network are very likely to fail - if you create a new connection to Peppol on a neutralized database, since the system parameter was not changed, the new connection was on production After this commit: - existing connections are switched in `demo` where everything is mocked locally, no call to the network (whether it's `test` or `prod` can happen) - the system parameter is switched to `test`, therefore new connections will register to the Peppol test network - Also added some fields on the Edi Proxy User to display the mode of the user, as well as the proxy_type in list view. (Those records are only accessible in debug already.) <img width="579" height="333" alt="image" src="https://github.com/user-attachments/assets/87847726-d954-4f68-8336-07771747365f" /> task-none (report from PMAX + WTA) Forward-Port-Of: odoo/odoo#226435
Users can now work with approvers on their own approval requests without triggering access errors. The change also prevents request owners from adding, editing, or deleting approvers directly, keeping approval controls consistent and reliable.
Original PR description
Fixed an issue happening when trying to add approvers to one's own request, and remove their ability to delete approvers from the request Task-4897775 Forward-Port-Of: odoo/enterprise#94515 Forward-Port-Of: odoo/enterprise#92309
Coupons meant for a customer's next order can no longer be claimed on the order that generated them. This prevents unintended discounts and keeps loyalty program rules applied as configured.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a next-order coupon program; 2. create an order that would generate a coupon; 3. confirm order; 4. click on the "Reward" button. Issue ----- It's possible to claim the reward on the current order. Cause ----- When retrieving claimable rewards, it checks the coupons generated by the current order using `coupon_point_ids`, but does not verify whether the program should be applicable to the current order. Solution -------- If the program only applies on future orders, and the coupon's `order_id` is the current order, skip the coupon when retrieving claimable rewards. opw-4910922 opw-4948757 Forward-Port-Of: odoo/odoo#221536
This fix stops pricelists from referencing each other in a loop, which could previously cause the online shop to crash with a server error. Businesses can now configure dependent pricelist rules more safely, with invalid circular setups blocked before they affect customers.
Original PR description
Steps ----- 1. Create a selectable pricelist A; 2. create a selectable pricelist B; 3. add a rule to pricelist B which uses pricelist A; 4. add a rule to pricelist A which uses pricelist B; 5. go to /shop & select one of the pricelists. Issue ----- > 500: Internal Server Error > Error while render the template > RecursionError: maximum recursion depth exceeded in comparison Cause ----- The `_check_pricelist_recursion` constraint only checks if a pricelist item's `base_pricelist_id` is the same as the item's `pricelist_id`. It can therefore not detect if two or more pricelists have a mutually recursive dependence relationship. Solution -------- Use a depth-first search to ensure any dependent pricelist doesn't depend on a parent pricelist. opw-5070604 Forward-Port-Of: odoo/odoo#226251
This update fixes several issues with packages placed inside other packages during stock transfers. It makes package moves, deletions, and on-screen package information more consistent, helping warehouse teams avoid confusing or incorrect package records.
Original PR description
Various fixes following the pack in pack introduced in #203987 Summary of the changes: - Allow the deletion of a container package even if it was used in a picking, as long as it was only ever used as a container (so it has no `stock.move.line` related to it). - A bunch of visual changes. - Display the full current package name for ongoing pickings in the `Pick From` column. - When relocating packages, if their container are completely moved as well, move the container as well instead of removing them from it. - Adjust the `package_m2o` widget so it is less costly - Use `SelectCreateDialog` for the 'Move a Pack' button. - Fixes an issue where adding a new package on top of packages and their destination container at the same time would leave some unnecessary data behind. For more information, check the commit descriptions. Task-5065793 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures online orders paid entirely with a gift card still go through the same stock availability checks as other payment methods. It prevents customers from completing checkout when items became unavailable after being added to the cart, reducing overselling and fulfillment issues.
Original PR description
In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The…
In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The other payment methods fail successfully but if gift card is used, the order can be validated. To reproduce: 1- Create a product and add quantity on stock. 2- Uncheck `Conitnue Selling` in `Out-of-Stock` 3- Publish the product on the website 4- Create a gift card 5- Add the product to the cart using portal user 7- Using admin user, set the quantity to less than ordered quantity 8- Using portal user, proceed to payment, and use the gift card. Then checkout. 9- As you see, the order is validated The issue is because `_check_cart_is_ready_to_be_paid()` which is supposed to check the stock, is only called inside `shop_payment_transaction()`. However, when checking out with gift card, this method is not called. To solve the issue, we can call `_check_cart_is_ready_to_be_paid()` also inside payment validate flow. However this only be called when a gift card is used solely. (The case `order.amount_total` is 0) opw-4941658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226394 Forward-Port-Of: odoo/odoo#222306
This fixes several live chat meeting issues that could cause crashes, incorrect display, cropped permission warnings, and missing picture-in-picture support. Users should have a smoother and more consistent calling experience when using live chat on websites.
Original PR description
This PR fixes several issues with the call meeting view: - crash when opening call settings - wrong style in website, because the full screen component is not mounted in the shadow DOM. - permission icons are cropped - crash when typing component is shown - pip assets are not loaded in the live chat
Checkout payments using a saved payment method are now held until the order is validated. This prevents customers from being charged or payment requests being sent when a last-minute checkout issue, such as an expired coupon, makes the order invalid.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a saved Stripe payment token; 2. create a discount coupon program & a coupon; 3. go to /shop & add a product to your cart; 4. go to checkout; 5. apply coupon; 6. before finalizing payment, set coupon program expiration to yesterday; 7. finalize payment. Issue ----- An error appears, because of the reward change, but a payment request has already been sent. Cause ----- For token transactions, `_send_payment_request` is called immediately upon creation, i.e. before the `WebsiteSale` controller is able to validate the transaction using `_validate_transaction_for_order`. Solution -------- If the payment flow happens via token, add a `delay_payment_request` context value. When creating a token transaction in `PaymentPortal`, only call `_send_payment_request` if this value is not set in the current context. opw-5013284 Forward-Port-Of: odoo/odoo#226067 Forward-Port-Of: odoo/odoo#225008
Point of sale payments through Adyen now handle cancellation and service availability errors more reliably. This helps prevent payments from getting stuck while waiting for a card response and makes checkout issues clearer when Adyen is unavailable.
Original PR description
When we try to cancel a processing payment, we can get stuck with a in the state waiting card, if there is no anwser from adyen. Also when we call Adyen to process payment, the value returned by data.silentCall is false, so we don't get error when the service is not available --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226587
This fix ensures payment button actions are ready as soon as the checkout payment flow is prepared. It prevents cases where PayPal-related payment events could fire before the button was listening, helping customers complete payments without missed clicks or stalled actions.
Original PR description
In commit 3e5f87b5de143eadf80e9c96e61fe24e621a939e event listeners were initialized on start. However when the event was triggered in payment_paypal it started to add the listeners. So at the moment were the event was triggered there was no listeners on the button to execute. Therefore The event listeners needed to be initialized on setup not on start. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where logged-in users starting a livechat could be added twice under different identities, which stopped the feedback panel from appearing after the chat ended. Livechat sessions now keep the correct participant record so customers can consistently leave feedback.
Original PR description
Before this PR, when a logged-in user had a guest in context and started a livechat, 2 discuss.channel.member records were created: one for the guest and one for the logged-in user. This prevented the feedback panel from being shown after the livechat ended. This PR fixes the issue by only adding the guest as a channel member when the user is not logged in. Steps to reproduce: - Start a livechat as a visitor and end it -> feedback panel is shown. - Log in as any user. - Start a livechat and end it -> feedback panel is not shown when clicking Continue or Close.
Fixes an issue where confirming a generated purchase order could fail when two make-to-order manufactured products shared the same component. The change keeps the related manufacturing references separate, allowing the purchase order confirmation to proceed normally.
Original PR description
Steps to reproduce the bug: With MTO enabled Create 2 finished products sharing 1 common component Create a sale order for those 2 products Try to confirm the generated purchase order for the component: ValueError: Expected singleton: mrp.production.group(x, y) Origin: Each generated mrp.production creates its own mrp.production.group and a purchase.order is generated with only 1 line for the whole quantity. Fix: Since it is for the reception picking, skip updating the production group --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website editors can now open and adjust settings for older snippets even when their stored version differs from the current template version. This removes a frustrating warning/blocker and helps users continue editing existing pages without extra technical intervention.
Original PR description
* : html_builder. For UX reasons, the block preventing users from accessing the options of a snippet when its version (XML, CSS, JS) differed from the one declared in the snippet's template has been removed. Users can now freely access options for outdated snippets. task-4297808
Express checkout now hides Click & Collect delivery options when multiple pickup stores are configured, because shoppers cannot choose a store in that flow. This prevents customers from accidentally selecting an in-store pickup option without knowing where the order will be collected, while still allowing it when there is only one pickup location.
Original PR description
Before this commit, when entering the express checkout flow, Click & Collect (C&C) delivery methods (DM) were included in the list of possible delivery methods available for express checkout. However, the express checkout flow does not allow customers to select which store they want to pick up their order from. After this commit, C&C DMs are excluded from the list if they have more than one store configured. If only one store is configured, the customer implicitly knows where they will need to pick up their order. Forward-Port-Of: odoo/odoo#226770 Forward-Port-Of: odoo/odoo#226329
UPS shipping rates can now be retrieved for orders that include combo products. This prevents valid deliveries from being blocked when combo items are present, while still checking for products that are missing required weight information.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit 59a79a5bc51 fixed a bug in 8 shipping connectors, preventing the retrieval of the shipping rate if combo products were present, but failed to fix it in `delivery_ups_rest`. Solution -------- Use `_get_invalid_delivery_weight_lines` helper method to check if there are any lines where a weight is expected, but is lacking. opw-4940973 Forward-Port-Of: odoo/enterprise#93737
Mollie payments that remain open, such as SEPA bank transfers, are now treated as pending instead of triggering an invalid status error. This prevents checkout confusion and allows customers to complete bank-transfer payment flows normally.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Mollie as a payment provider; 2. set up an eCommerce order in EUR; 3. go to checkout; 4. pay via Mollie; 5. pick SEPA bank transfer as payment method; 6. leave the transaction open. Issue ----- When returning from the redirect, we get the following error message: > Mollie: Received data with invalid payment status: open Cause ----- An 'open' payment indicates the payment has been created, but nothing else has happened yet[^1]. This is the expected status for bank transfers, but is currently not getting handled in `_process_notification_data`, leading to the error. [^1]: https://docs.mollie.com/docs/status-change Solution -------- Handle 'open' payments the same as 'pending' ones. opw-4894556 Forward-Port-Of: odoo/odoo#226755 Forward-Port-Of: odoo/odoo#225875
This update refreshes Odoo Spreadsheet with fixes for pivot table calculated measures, improving accuracy when totals are used. It also makes spreadsheet navigation easier when many tabs are open and reduces accidental figure dragging, creating a smoother user experience.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f443c9aed [REL] 19.0.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f443c9aed [REL] 19.0.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/0e24e1730 [FIX] pivot: calculated measure from totals [Task: 5061631](https://www.odoo.com/odoo/2328/tasks/5061631) https://github.com/odoo/o-spreadsheet/commit/c541ecf11 [FIX] pivot: add aggregator to calculated measure id [Task: 5061631](https://www.odoo.com/odoo/2328/tasks/5061631) https://github.com/odoo/o-spreadsheet/commit/6bf3609fd [IMP] carousels: add dropdown when too many tabs [Task: 5059476](https://www.odoo.com/odoo/2328/tasks/5059476) https://github.com/odoo/o-spreadsheet/commit/2e401cce2 [IMP] figures: add drag threshold [Task: 5059476](https://www.odoo.com/odoo/2328/tasks/5059476) https://github.com/odoo/o-spreadsheet/commit/a96ba1bb8 [IMP] test: add `expect.toHaveStyle` jest matcher [Task: 5059476](https://www.odoo.com/odoo/2328/tasks/5059476) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix makes the website editor’s background positioning tool behave correctly across desktop, mobile preview, scrolling, and visual effects. Users can now adjust background images more accurately without overlay glitches, missing masks, or confusing loading visuals.
Original PR description
__Current behavior before commit:__ The background position overlay action allows the user to move the background image of the editing element. To do that it copies it inside an overlay which is…
__Current behavior before commit:__ The background position overlay action allows the user to move the background image of the editing element. To do that it copies it inside an overlay which is outside the iframe since the [Website refactoring]. This creates multiple challenges because the overlay needs to perfectly align with the editing element behind it which is not a trivial task for several reasons: - The iframe can have different sizes and positions when toggling the mobile preview. - The editing element can be anywhere on the page, and it can move if the user scrolls. - Some scroll effects depend on the dimensions of the viewport which is different in and out of the iframe. Furthermore the `overlay` plugin currently used is designed for contextual menus and pop-ups. It forces the overlay content to always be fully visible in the window and it hides the content if it is bigger. This makes it unsuitable for the purpose of positioning a background image. Here are several bugs that arise from the above: - The overlay doesn't appear if the editing element is taller than the window. - When the overlay is open, it's only possible to scroll while the mouse is hovering the scrollbar. - The overlay image doesn't follow the editing element after scrolling. - The overlay dark mask doesn't cover the whole iframe window. - The loading spinner and its dark overlay is displayed while the background position overlay is on. - If the Scroll Effect is set to "Zoom Out" with maximum intensity, the overlay is not correctly positioned. - If the Scroll Effect is set to "Fixed", the overlay **is** correctly positioned but the background position doesn't align with the one behind it. - In the mobile preview the overlay doesn't cover the iframe. - etc. __Description of the fix:__ Several things are now done differently to fix these issues: - The `overlay` service is used instead of the plugin. This way we have a better control over the positioning of the overlay. - The overlay positioning is more robust to take into account the mobile preview iframe position, the page scrolling and a possible browser zoom. - We stop using an image copy, instead the editing element `background-position` is directly modified making it a perfect wysiwyg. To do this, the overlay dark mask is kept but the portion in front of the editing element is cut-out to highlight it. An invisble dragger element is there to be able to listen to mouse event for the dragging. Also, the content of the section is made invisible so that only the background is shown. [Website refactoring]: https://github.com/odoo/odoo/pull/187419 Related to task-4367641 Forward-Port-Of: odoo/odoo#219179
This fix stops changing one product line’s scheduled date from automatically changing the scheduled dates of other lines on the same stock receipt when delivery features are installed. It helps keep warehouse planning accurate and prevents unexpected timing changes during receipt updates.
Original PR description
### Steps to reproduce: - Install stock_delivery - Create and confirm a receipt for 2 products: - 1 x P1 - 1 x P2 - Modify the scheduled date of P1 to the day before - Save the picking #### Expected…
### Steps to reproduce:
- Install stock_delivery
- Create and confirm a receipt for 2 products:
- 1 x P1
- 1 x P2
- Modify the scheduled date of P1 to the day before
- Save the picking
#### Expected behavior:
The scheduled date of the picking is updated but not the one of the other move.
#### Current behavior:
The the move scheduled date is also updated.
### Cause of the issue:
Modifying the scheduled date of the move will trigger a call of the onchange on the picking because the `stock_move_ids` field has changed via a `Command.update` on its scheduled date:
https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/web/static/src/model/relational_model/record.js#L1214-L1219 However, this onchange will trigger a call of the
`_compute_scheduled_date` on the new records to determine if its value has changed and set the scheduled date of the picking to one day before: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L846-L851 This is problematic because since each of these changes happen before the save of the real record, the inverse method of the scheduled date will be called and set the scheduled date of the other moves at save: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L897-L901
### Note:
This is not reproducible without `stock_delivery`, changing the scheduled of a `move_ids_without_package` will only trigger the onchange of the `stock.picking` model (and hence the compute on the new records) in case the `move_ids_without_package` is flagged as `onchange=1` by the `get_view`:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/addons/base/models/ir_ui_view.py#L1218-L1225 But, since `move_ids_without_package` do not have `_onchange_methods` they will only be flagged as such if they are in the dependencies of a field present in the view:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/models.py#L7363-L7370 This is the case as soon as `stock_delivery` is installed because of the `is_return_picking` field:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/addons/stock_delivery/models/stock_picking.py#L37-L38
opw-5017423
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#225690
Forward-Port-Of: odoo/odoo#224986Fixes how Odoo calculates the standard cost for FIFO-tracked products when stock is shipped out. This helps keep inventory valuation and product costs accurate after outgoing stock movements.
Original PR description
Ensure that the standard price is correctly computed when a FIFO product has outgoing stock moves. Due to the need of the old FIFO value before marking the moves as 'done', `_update_standard_price` has to be called in `_action_done` instead of `_set_value`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where booking a resource-based appointment could incorrectly reduce availability for a staff member assigned as responsible. This prevents customers from being sent back to the calendar with an error when a user-based appointment slot should still be available.
Original PR description
In [1], we introduced capacity for users. Therefore, capacity is handled by using booking lines, with capacity reserved / used set on them. However, unlike the resources, the user is not stored and…
In [1], we introduced capacity for users. Therefore, capacity is handled by using booking lines, with capacity reserved / used set on them. However, unlike the resources, the user is not stored and is related as the responsible (user_id) of the meeting instead. This has a side effect: if there are resource booking lines on a meeting, and a responsible is set (manually or the appointment type creator as a default responsible, as done in appointment module), then those booking lines may end up counting as booked capacity for the responsible as well! Therefore, we now make sure that the appointment type linked to the meeting is scheduled based on users when searching for booking lines in the remaining capacity computation. STEPS TO REPRODUCE ================== 0. Create a new db and install website_appointment 1. Log in as mitchell Admin 2. Create an appointment_type R based on resources, with a resource R1 and an appointment_type U based on users, with only Mitchell Admin set as staff user 3. Log out and book R on a given slot S 4. Once done, go to appointment U and try to book the same slot S 5. Once you submit the form, you are brought back to the calendar selection screen with an error message (code 'failed-staff-user') TEST ==== A test is added covering most cases, both when getting slots and when directly measuring the user's remaining capacity. 1: https://github.com/odoo/enterprise/commit/bce7e94650c337a9046958a7689c81db5b2a4c73 Task-5080374 Forward-Port-Of: odoo/enterprise#94339
Fixes an issue where customers could see an Internal Server Error when adding a Stripe payment method. Validation-only payment setup is now handled correctly, improving the reliability of saving payment methods without affecting normal payments.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Configure Stripe; 2. go to `/my/payment_method`; 3. create a payment token. Issue ----- > Internal Server Error Cause ----- Commit 5db75d32d718a added a…
Versions
--------
- saas-18.4+
Steps
-----
1. Configure Stripe;
2. go to `/my/payment_method`;
3. create a payment token.
Issue
-----
> Internal Server Error
Cause
-----
Commit 5db75d32d718a added a method that compares notification data values to the transaction values. For most operations, the structure of Stripe notification data is similar, but for `SetupIntent` responses, these don't include an amount or currency value (unless the currency is supported by Indian eMandates, in which case it's part of a `mandate_options` dict)[^1].
The error is the result of `payment_data.get('currency').upper()`. Because there is no currency value, `upper` gets called on `None`.
Additionally, when the transaction amount is zero (as is expected for validation operations), the base `_compare_notification_data` method assumes the amount is missing, throwing a validation error.
[^1]: https://docs.stripe.com/api/setup_intents/confirm
Solution
--------
- Skip comparing notification data for validation transactions.
- If the `currency` value is in fact missing unexpectedly, fall back on the empty string, so that we get to the intended validation error.
opw-5008858
Forward-Port-Of: odoo/odoo#222591The Spanish balance sheet now avoids counting accounts 551 and 5525 twice under Other Current Payables. This prevents overstated payable amounts and gives finance teams a more accurate report when reviewing company liabilities.
Original PR description
**Steps to reproduce:** 1. Install `l10n_es_reports` and `accounting`. 2. Switch company to `ES Company`. 3. Create a journal entry using account 551 or 5525. 4. Open the Balance Sheet from…
**Steps to reproduce:** 1. Install `l10n_es_reports` and `accounting`. 2. Switch company to `ES Company`. 3. Create a journal entry using account 551 or 5525. 4. Open the Balance Sheet from *Accounting → Reporting → Balance Sheet*. **Observed behavior:** - In the Balance Sheet, under *3. Other Current Payables*, the amount shown is double the journal entry. - Drilling down shows the correct amount in the journal entry, but the Balance Sheet line is overstated. **Root cause:** * In the expression for *3. Other Current Payables*, accounts **551** and **5525** were included twice: * once in credits and again in the balance, leading to double counting. **Reference:** * BOE: https://www.boe.es/eli/es/rd/2007/11/16/1514/con#cuenta * PR with related changes: [odoo/enterprise#82447](https://github.com/odoo/enterprise/pull/82447) **Solution:** - Removed accounts 551 and 5525 from the balance calculation to prevent duplication. opw-5056965 Forward-Port-Of: odoo/enterprise#94310
Service products in Indian POS GST reports are now reported with a quantity of zero, as required by the GST portal. This prevents validation errors during filing while keeping goods quantities unchanged.
Original PR description
Before this PR: - Service products in POS GSTR lines were reported with their actual quantity. - This caused GST portal validation error: `RET191355: The Quantity entered is not valid`. After this PR: - For service-type products, `qty` is always set to `0`. - For goods, `qty` continues to reflect the actual ordered quantity. OPW: 5070636 Forward-Port-Of: odoo/enterprise#94522 Forward-Port-Of: odoo/enterprise#94272
This fix prevents an error when users create Mexican customer credit notes and enter a CFDI Origin. It helps accounting teams save these documents reliably without being blocked by a system error.
Original PR description
Currently, an error occurs when creating a customer credit note with a CFDI Origin.
**Steps to reproduce:**
- Install the `l10n_mx_edi` module and switch to `ESCUELA KEMPER URGATE` company.
- Navigate to: Invoicing > Customers > Credit Notes > New.
- Set `CFDI Origin` to `01|E19C50D2-1292-5817-BDDE-2666967C7471` and click `Save`.
**Error:**
`TypeError: unhashable type: 'list'`
**Root Cause:**
At [1], the code incorrectly uses `relationado_data['03', []]` instead of `relationado_data.get('03', [])`. The tuple `('03', [])` is treated as a dictionary key, which leads to an `error`.
**Fix:**
This commit ensures users can correctly set the CFDI Origin.
[1]
https://github.com/odoo/enterprise/blob/14b31a3631a97dd61ebd662fb768485e5a509c2c/l10n_mx_edi/models/account_move.py#L500
sentry-6823395705
Forward-Port-Of: odoo/enterprise#92876Users can no longer add signature fields before a PDF page is ready, preventing errors during document setup. Cleanup of temporary page elements is now handled more safely, improving stability when PDF pages reload.
Original PR description
Fixed an issue where users could drag and drop sign items before the target PDF page was fully loaded, which caused runtime errors. The system now blocks adding new sign items until the target page has finished loading. Also fixed a problem with cleaning up dummy elements: these were sometimes removed incorrectly when the iframe re-rendered the pages, as the cleanup was already handled automatically. task-5065598 Forward-Port-Of: odoo/enterprise#94666 Forward-Port-Of: odoo/enterprise#94001