Thursday, July 9, 2026
22 changes · saas-19.4
Enhancements to existing features
Belgian payroll rules now include updated employment bonus parameters effective 1 July 2026 and 1 September 2026. This helps ensure payslip calculations stay aligned with the latest Belgian payroll requirements.
Original PR description
Update the employment bonus parameters for 1st July 2026 and 1st September 2026. task-6369633 Forward-Port-Of: odoo/enterprise#123311 Forward-Port-Of: odoo/enterprise#123262
The bank reconciliation widget now sends less unnecessary data to the browser and precomputes some information on the server. This should make opening and using bank reconciliation faster on very large databases, improving accountant productivity.
Original PR description
When opening the bank rec widget on huge DB's, it takes
a lot of time to load everything.
This commit aims to improve the loading performances by
removing some JS fields:
1 - reconciled_lines_ids: We only use the first element of
this recordset in JS, so we add a new computed field
to only send 1 record to the JS
2 - hasAttachment: replace the long JS computation of
`get hasAttachment` with a python computed field.
3 - Replace matched_credit_ids and matched_debit_ids
with exchange_diff_partial_ids.
Linked:https://github.com/odoo/odoo/pull/269119
task-6275945
Forward-Port-Of: odoo/enterprise#119557Searching for customers in Point of Sale is now more responsive when many partners exist. The system now shows only a practical number of results and waits a bit longer before re-running the search while typing, which reduces delays and improves the user experience.
Original PR description
Before this commit, when high number of partners were loaded in the POS, searching for a partner was slow. The main issue was that all of the filtered partners based on the search query were being rendered, while in reality, if a query returns lots of results, the search query is not refined enough and the user is likely to type more characters to narrow down the search. So in this commit, we limit the number of rendered partners to 200, which is a reasonable number of results to display and does not cause performance issues. Moreover, the debounce time of the search input has been increased from 100ms to 500ms to further reduce the number of times the search function is called while the user is typing. opw-6215958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268658 Forward-Port-Of: odoo/odoo#264300
Resolved issues and error corrections
Australian payroll payslips now refresh an employee's income stream type before calculating the sheet. This prevents payroll users from hitting an error when an employee's income category was updated after a payslip had already been created.
Original PR description
When an employee's Income Stream Type is changed after a payslip has been created, computing the sheet for payslip will raise a traceback. Steps to reproduce the error: - Install…
When an employee's Income Stream Type is changed after a payslip has been created, computing the sheet for payslip will raise a traceback. Steps to reproduce the error: - Install ``l10n_au_hr_payroll_account`` module with demo data - Switch to ``My Australian Company`` company - Create a new payslip for ``Dennis Cactus`` Employee > Save - Go to Employees > Open the ``Dennis Cactus`` employee > In Payroll tab, Income Stream Type: Other specified payments > Save - Go back to payslip > click the compute sheet button Traceback: ```py KeyError: 'OSP' ``` https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll/models/hr_payslip.py#L175-L178 The ``l10n_au_income_stream_type`` field on the payslip is a computed field that only depends on ``employee_id``. As a result, changing the employee's Income Stream Type does not trigger a recomputation of the corresponding field on existing payslip. So, when the ``payslip_ytd_totals`` field is computed, it uses the old value of ``l10n_au_income_stream_type`` field at [1], The resulting ``payslip_ytd_totals`` is then used to build the ``totals`` dictionary, and eventually, when the employee's current ``income_stream_type`` is used to access ``totals``, the mismatch key leads to the above traceback. https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll_account/models/hr_payslip.py#L75-L88 [1]: https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll/models/hr_payslip.py#L269-L272 solution: I added ``l10n_au_income_stream_type`` to ``add_to_compute()`` in ``compute_sheet()``. This ensures that stale values of ``l10n_au_income_stream_type`` on existing payslips are recomputed when the payslip sheet is computed. sentry-7536819310 Forward-Port-Of: odoo/enterprise#123288 Forward-Port-Of: odoo/enterprise#120143
This fix ensures sales orders cannot add recurring subscription products from the catalog unless a subscription plan is set. It closes a validation gap so users get the same warning whether they add products manually or through the catalog view, helping prevent incorrect subscription orders.
Original PR description
Steps to reproduce: --------------------------------------- 1. Install Subscription Module 2. Create and Confirm SO with no recurring plan and a non-recurring product 3. Add a recurring product >…
Steps to reproduce: --------------------------------------- 1. Install Subscription Module 2. Create and Confirm SO with no recurring plan and a non-recurring product 3. Add a recurring product > Save SO > Observe the User Error 4. Now add the same recurring product through Catalog View Observation: --------------------------------------- No User Error raised stating 'You cannot save a sale order with recurring product and no subscription plan.' Issue: --------------------------------------- When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177 When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint. https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933 Solution: --------------------------------------- Two private helpers are introduced: * `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders). * `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync. `_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points. opw-6194865 Forward-Port-Of: odoo/enterprise#123216 Forward-Port-Of: odoo/enterprise#117879
Vendor bills imported from Chilean electronic invoices now use the correct foreign-currency amounts instead of peso amounts. This prevents incorrect bill totals when companies work with currencies such as UF, improving accounting accuracy.
Original PR description
**STEP TO REPRODUCE** 1. Create a invoice to a chilian company, using another currency (for example UF, don't forget setup up a currency rate). 2. Confirm. 3. Download the xml in the chatter, and import it as a vendor bill. 4. Notice the imported bill amount are wrong (Pesos amount are used, with the currency being UF). opw-6269662 Forward-Port-Of: odoo/enterprise#123179 Forward-Port-Of: odoo/enterprise#119664
Fixes an error that could stop Sendcloud batch deliveries when one transfer was split into multiple packages. Users can now validate these deliveries reliably, avoiding failed shipping workflows and disruption during order fulfillment.
Original PR description
Issue ----- When using Sendcloud batch deliveries, users get a traceback if the transfer is split into multiple packages. Steps to reproduce ----- - Setup Sendcloud - Enable batch delivery - Create a…
Issue ----- When using Sendcloud batch deliveries, users get a traceback if the transfer is split into multiple packages. Steps to reproduce ----- - Setup Sendcloud - Enable batch delivery - Create a delivery for 2 units of a product - Delivery method set to sendcloud - Put each unit in a separate package - Validate the delivery > Traceback Cause ----- Bug introduced by #90302 (so only present in 19.3+). When using the batch deliveries option, the packages are sent in a single list. This means that, in `_prepare_parcel`, when we iterate over the packages, `pkg` can be a list https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L462 This means that `pkg.name` will fail https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L481 Considering that a batch delivery uses the same reference number on all labels, we can pass `None` as a fallback to `_get_unique_order_number_reference` (it is an accepted value) https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L388-L393 ----- Ticket: opw-6267928 Forward-Port-Of: odoo/enterprise#120206
This fixes DHL shipping validation when deliveries are processed from a company other than the main one. Commercial invoice numbers are now generated correctly, preventing DHL from rejecting affected international deliveries.
Original PR description
Issue ----- When validating a delivery in a different company from the main one, the commercial invoice's number field is incorrect, which raises an error on DHL end.…
Issue ----- When validating a delivery in a different company from the main one, the commercial invoice's number field is incorrect, which raises an error on DHL end. `content/exportDeclaration/invoice/number: expected type: String, found: Boolean` Steps to reproduce ----- - Create a Belgian company - Setup DHL - DHL Product D - Express Worldwide - Dutiable Material enabled - Create an amrican customer - Deliver a product to the american customer > Validation Error Cause ----- The field is populated in https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/delivery_dhl_rest/models/dhl_request.py#L204 The problem is that `next_by_code` uses the company found in the env, whereas the sequence's company is the main one, so it is not found when doing https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/odoo/addons/base/models/ir_sequence.py#L287 ----- Ticket: opw-6171886 Forward-Port-Of: odoo/enterprise#123170 Forward-Port-Of: odoo/enterprise#118379
This fix restores reliable access to WhatsApp message content for users who are allowed to see those WhatsApp messages. It prevents upgrade and usage failures caused by overly restrictive linked-message checks, while keeping the existing WhatsApp message visibility rules in place.
Original PR description
The `body` field on `whatsapp.message` was defined with `related_sudo=False` with the intent of restricting access to messages from restricted records. However, this was never actually providing any…
The `body` field on `whatsapp.message` was defined with `related_sudo=False` with the intent of restricting access to messages from restricted records. However, this was never actually providing any security value because [`mail.message.fetch()`] was overriding it with `self.sudo()` till `v19.1`, meaning the body was always fetched as superuser regardless:
```py
web_search_read() -> search_fetch()
-> fields.py _compute_related()
-> record[self.related_field.name] # triggers fetch of mail.message.body
-> models.py _fetch_field()
-> mail_message.py fetch()
-> self = self.sudo() # sudo hack overrides related_sudo=False silently
```
In `v19.2`, the `fetch()` sudo hack was intentionally removed (see commit odoo/odoo@4727f12d274a0b2d7c455363d189565bd8fb2e7a) as access rights are now cached and can be checked without a performance penalty. This exposed the broken `related_sudo=False` which now causes an `AccessError` when trying to read the body of a `whatsapp.message` whose linked `mail.message` points to a document the current user cannot access (e.g. `purchase.order`).
Access control on `whatsapp.message` is already correctly enforced at the `ir.rule` level:
- Regular users can only see messages they created (`create_uid = user.id`)
- WA Admins can see all messages
We have upgrade requests failing on this issue: TBG-[2765]
[`mail.message.fetch()`]: https://github.com/odoo/odoo/blob/saas-19.1/addons/mail/models/mail_message.py#L812-L819
[2765]: https://upgrade.odoo.com/odoo/tbg/2765?debug=1
Forward-Port-Of: odoo/enterprise#119867Fixed a barcode workflow issue where scanning an existing package followed by a package type could create a new package without attaching it to the delivery items. Warehouse users now get the expected destination package assignment, reducing packing mistakes and invisible backend inconsistencies.
Original PR description
When scanning a package then a package type, from the point of view of the user nothing happend, and in the backend it will created a new package but it will not link it to the products nor will it…
When scanning a package then a package type, from the point of view of the user nothing happend, and in the backend it will created a new package but it will not link it to the products nor will it show any warning. Steps to reproduce: ------------------- * Install barcode and stock * Enable packages in settings * Open Inventory * Create a product, * Create a Package Type -> barcode PACKTYPE, * Create a Package linked to this package type -> PACK, * Add at least 2 unit of product to this package, * Create a delivery for 2 unit of the product, Open Barcode * Operation > Delivery orders > your delivery * Erase the destination package from the first line * Scan PACK ( don't click on the green line) * Scan PACKTYPE **Actual behavior** create a new package but does not link it to the new products **Expected behavior** create a new package and set it as destination package. Observation: ------------- When scanning the package (PACK), we will go through ```_processPackage``` -> ```async _processPackage``` where in the end the line is unselected: https://github.com/odoo/enterprise/blob/39d8a473fe03038ca0494a6a8165e3eb75bd8492/stock_barcode/static/src/models/barcode_picking_model.js#L2090 When we scan our package type (PACKTYPE), we will go to ``` _processPackage``` -> ```_processPackage```->```_processPackageType``` where we will obtains packagesIds checking that we have a source package: https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2123-L2132 and will send us to ```_putPackInPack```: https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2133-L2136 Where we will avoid the empty packageIds since we checked on the source package and not the destination package: https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2296-L2299 and will call ```action_put_in_pack``` from the packaging model: https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2301-L2306 In ```action_put_in_pack``` will create a new packaging and put it as a the new destination package, but since the ```previous_dest_package``` (saved in db) was itself, he will [erase the link](https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_package.py#L354-L363) he just made. Which means that in our case, we created a package without linking it to anything. Even if we avoid the function to erase the destination package, since the destination package shown in barcode is the one from move line : https://github.com/odoo/enterprise/blob/d0d0a3cf4a02bf24cf502b533e494fe7ca155eb3/stock_barcode/static/src/components/line.js#L115-L117 It will not show the new package in barcode opw-5449729 Forward-Port-Of: odoo/enterprise#120335 Forward-Port-Of: odoo/enterprise#104876
This fix ensures point-of-sale planning checks all relevant resources when a payment method is not tied to a specific resource. It also limits planning slot selection to the same company as the POS configuration, helping businesses avoid missing slots or using slots from the wrong company.
Original PR description
When no resource is linked to a resource payment method, we should take into account all resource which was not done before. This is now done. We also change the filter in python to only look for slots that are part of the same company as the config.
The timesheet grid now marks public holidays, weekends, and approved personal time off according to the employee's assigned working schedule instead of always using the company default. This helps employees and managers see accurate unavailable days, especially when teams have different schedules or contract-based calendar changes.
Original PR description
Steps to Reproduce --- - Create two different working schedules with different public holidays - Assign employees to specific working schedules - Set company default working schedule to a different…
Steps to Reproduce --- - Create two different working schedules with different public holidays - Assign employees to specific working schedules - Set company default working schedule to a different schedule - Login as employee with specific working schedule - Navigate to Timesheets app -> My Timesheets - Observe public holidays and personal time-off displayed in the timesheet grid Issue --- - The timesheet grid displays unavailable dates (public holidays, weekends) from the company's default working schedule instead of the employee's assigned working schedule. - Personal time-off requests are not reflected as unavailable dates in the timesheet grid. Current Behaviour --- - Public holidays shown are always from the company's default working schedule, ignoring employee-specific working schedule assignments. - Employee's approved time-off requests don't appear as unavailable in the timesheet. Expected Behaviour --- - Public holidays should display based on the employee's assigned working schedule, with company schedule as fallback only when no specific schedule is assigned. - Employee's personal time-off requests should appear as unavailable dates. - This should align with Time Off app behavior. Fix --- - Included employee-specific work interval calculation with personal time-off requests. - Added support for contract-based calendar changes and calendar validity periods. - Implemented proper fallback when valid intervals are not found. task-4997080 Forward-Port-Of: odoo/enterprise#123331 Forward-Port-Of: odoo/enterprise#95458
Lazada order syncing now uses the overall order status instead of separate item-level statuses. This prevents sync failures when a previously delivered item is later marked canceled, helping keep marketplace orders importing reliably.
Original PR description
Lazada stores order statuses at the item level. When an item is canceled, we mirrored this by decreasing the ordered quantity on the sale order line. But if the item was already delivered, decreasing the quantity below the delivered amount is forbidden and raises a `UserError`, which aborts the whole order sync:
```python
File ".../sale_stock/models/sale_order_line.py", line 420, in _update_line_quantity
raise UserError(_('The ordered quantity of a sale order line cannot be decreased below the amount already delivered. [...]'))
```
In practice, item-level statuses only differ from the order status in exceptional cases. Stop syncing statuses at the item level and assume the entire order shares a single status, which avoids the quantity decrease and the resulting traceback.
opw-6267730
Forward-Port-Of: odoo/enterprise#123365
Forward-Port-Of: odoo/enterprise#122851The Point of Sale product list now uses the fuller layout on medium-sized tablet screens instead of switching too early to the compact view. This makes product browsing easier for store staff on supported tablets without affecting smaller mobile screens.
Original PR description
Previously, the product list was rendered in "small display" mode for all screen sizes below the medium breakpoint (< 992px). However, some small tablets are able to fully display the product list at the medium breakpoint (≥ 768px and ≤ 991px). After this fix, "small display" mode is only applied when the screen width is below 768px. Task.6251934 Community: https://github.com/odoo/odoo/pull/266704 Forward-Port-Of: odoo/enterprise#122613 Forward-Port-Of: odoo/enterprise#119534
This fixes cases where generated website snippets could point to the wrong filter when modules were installed in a different order. The change ensures the website uses the correct database filter values, helping generated content display reliably.
Original PR description
Our default dynamic snippets filter ids are set based on the order that we install our modules. This can cause issues if the user installs their modules in a different order. To fix this, we need to update the data-filter-id value to the correct value of the DB. To be able to do this, we also change the regex replacement to use lxml instead since it's much simpler. Lxml part from 799f83575e162eb683cfaebb4eb602ccc1fbe466. Forward-Port-Of: odoo/enterprise#123340 Forward-Port-Of: odoo/enterprise#122671
AI-related screens now fit better on smaller devices, making agent profiles, composer cards, and skill forms easier to read and use on mobile. This reduces wasted space and presents key information more clearly for users working from phones or tablets.
Original PR description
This commit improves the user experience of the AI modules on smaller screens by fixing several views for mobile devices. The changes include: - Adapt the AI agent form view to follow the Contacts mobile layout by centering the avatar in a circular container and improving the layout of the name and description. - Move the agent avatar next to the record name in the AI Composer kanban view to optimize space usage. - Remove unnecessary empty space in the AI Skill form view so the form uses the available width on mobile. task-6366399
This change prevents a crash that could happen when users try to split a stock transfer that has already been completed. Since there is nothing left to split in that situation, the system now exits safely instead of showing an error.
Original PR description
Issue before this commit: ========================= When splitting a done picking that contains at least one stock move whose done quantity is less than the demanded quantity (product_uom_qty), an…
Issue before this commit: ========================= When splitting a done picking that contains at least one stock move whose done quantity is less than the demanded quantity (product_uom_qty), an expected singleton traceback occurs. Steps to Reproduce: ========================= - Install the stock module with demo data. - Create a delivery picking for any product with a demand of 5. - Set the done quantity to 2. - Validate the picking without creating a backorder. - Try to split the validated/done picking. - An expected singleton traceback is raised. Cause of the issue: ========================= Previously, attempting to split a done picking simply returned because there was nothing left to split. After this [PR](https://github.com/odoo/odoo/pull/224952), the split action calls **message_post()** to post a note on the original picking of the generated backorder. However, no backorder is created when splitting a done picking since there is no remaining quantity to split. As a result, message_post() is called on an empty recordset, leading to an expected singleton traceback. With This Commit: ========================= Splitting a done picking has no functional purpose, as there is nothing left to split. In this case, simply return without performing any action. This preserves the previous behaviour and prevents the traceback. Forward-Port-Of: odoo/odoo#274855 Forward-Port-Of: odoo/odoo#274382
This fix prevents the website editor from crashing when users open the Documents tab after selecting an icon in the media picker. It ensures the editor correctly distinguishes document items from icons, making the replacement flow more reliable.
Original PR description
### Steps to reproduce: - Open the website editor and insert a snippet. - Inside the snippet, add an image and a document via /media. - Select the image, click Replace, pick an icon. - Click the icon, then click Replace from the sidebar. - In the dialog, click the Documents tab. - Traceback occurs. ### Root cause: - Both icon and document box elements are `<span>` tags. `DocumentSelector` inherits `selectInitialMedia()` from `FileSelector` which only checks the tag name, so it incorrectly returns true for icons. This causes `fetchAttachments` to call `querySelector(a)` on the icon span, which returns null and crashes. ### Solution: - Override `selectInitialMedia()` in `DocumentSelector` to also check for the `o_file_box` class. Add optional chaining on `querySelector(a)` as a safety net. task-6310147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270548
When a task is moved to another project, its followers now inherit the notification preferences set at the destination project. This ensures people continue receiving the updates they expect, such as stage changes, instead of missing important task activity.
Original PR description
Steps to reproduce: - 1. Create projects A and B. 2. Add a user as a follower of project B and select specific notification subtypes (e.g., 'Stage Changed'). 3. Create a task in project A and add the same user as a follower(defaulting to 'Discussions'). 4. Move the task from project A to project B. Issue: - The follower's subscription preferences on the task do not reflect their project-level settings after the move. In the example above, the user remains subscribed only to 'Discussions' and misses 'Stage Changed' updates. Cause: - The default auto-subscription logic skips existing followers. When moving a task, this prevents the system from adding the new project's notification preferences to users who were already following the task. Fix: - Override `_message_auto_subscribe` in project.task to the `update` policy when the `project_id` is changed. task-5877507 Forward-Port-Of: odoo/odoo#248224
This change fixes a problem where e-invoices could be rejected by the Nilvera service when the company uses a foreign main currency. The system now always includes the required exchange rate to Turkish Lira in the invoice data, helping invoices go through successfully.
Original PR description
Description of the issue/feature this PR addresses: This PR resolves an integration failure with the Nilvera e-invoicing provider when a company’s primary currency is configured to a foreign currency…
Description of the issue/feature this PR addresses: This PR resolves an integration failure with the Nilvera e-invoicing provider when a company’s primary currency is configured to a foreign currency (e.g., USD) rather than the local currency (TRY). Nilvera strictly requires a valid exchange rate relative to Turkish Lira (TRY) to be included inside the XML nodes of every posted invoice utilizing a foreign currency. Functions affected: def _add_invoice_exchange_rate_nodes(self, document_node, vals): def _l10n_tr_get_currency_conversion_rate(self, invoice): Current behavior before PR: When generating an invoice where both the company's main currency and the invoice currency are foreign (e.g., USD), the system does not calculate or embed a TRY conversion/exchange rate into the invoice payload. Because this mandatory local currency reference mapping is missing, Nilvera rejects the invoice submission. Desired behavior after PR is merged: For every invoice processed via the Nilvera localization, the system will explicitly calculate and inject the exchange rate between the active invoice currency and TRY into the posted document nodes, regardless of what the underlying company's primary currency is set to. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271129 Forward-Port-Of: odoo/odoo#270531
This change prevents signed-in website visitors from being unexpectedly logged out after browsing pages when a guest chat session already exists. It improves reliability of the website experience by making sure guest tracking does not override an authenticated user’s session.
Original PR description
Before this commit, browsing any page of the website while having a guest cookie set would log out the user after a few seconds. Steps to reproduce: 1. While logged out start a live chat on "/contactus" (or get a guest cookie in any other way). 2. Log in as Marc Demo 3. Open "/contactus" (or any other website page) 4. Refresh after a few seconds -> logged out This happens since [1], which refactored the visitor page tracking. In said change, the override of `track` in `website_livechat` adds the guest to the request context (using `force_guest_env`) if the guest cookie is found. This is done to correctly connect the guest and visitor records, but will log out an authenticated user that has the guest cookie. This commit fixes the issue by only forcing the guest env if the user is not authenticated. [1] https://github.com/odoo/odoo/pull/247438 task-6369344 Forward-Port-Of: odoo/odoo#274704
This change fixes an issue where unreserving a manufacturing order could accidentally reset byproduct quantities to zero. As a result, producing the order again now correctly creates the expected byproducts, avoiding missing output and manual rework.
Original PR description
On a mo that has byproducts, if you unreserve, it will also set the quantity of byproducts to 0 Steps to reproduce: ------------------- * Create a Products main, component and byproduct * Create a…
On a mo that has byproducts, if you unreserve, it will also set the quantity of byproducts to 0 Steps to reproduce: ------------------- * Create a Products main, component and byproduct * Create a bom for main with component as component and byproduct as byproduct * Create and confirm a mo for main * Set qty_producing to quantity ot produce * click on "Unreserve" (do_unreserve) * click on "Check availability" (action_assign) * Produce All -> the byproducts will not be produced. Observation: ------------- When updating the qty_producing value it will also update the quantity of the byproducts moves: https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mrp/models/mrp_production.py#L892-L893 https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mrp/models/mrp_production.py#L1350 https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/stock/models/stock_move.py#L2382 The quantity on the byproducts move has been updated. When clicking on Unreserve it will call do_unreserve, https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/mrp/models/mrp_production.py#L2297-L2298 It will filters the moves that do not need to be unreserved and select the others: https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/stock/models/stock_move.py#L900 and it will unlink all the sml from the moves: https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/stock/models/stock_move.py#L919 Which will set the quantity on the byproduct moves to 0. When Producing all (button_mark_done) since the qty_producing has already been set, it will simply mark the byproduct move has picked. https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/mrp/models/mrp_production.py#L1323-L1324 In our case, this means that the no byproducts will be created since, the quantity was previously set to 0 opw-6296562 Forward-Port-Of: odoo/odoo#273739 Forward-Port-Of: odoo/odoo#272216