Daily updates from Odoo
Wednesday, July 16, 2025
38 changes · saas-18.4
Resolved issues and error corrections
This fix ensures a company's currency cannot be changed once accounting entries exist, even when a user has switched to another company. It protects financial records from accidental inconsistencies across companies.
Original PR description
To_reproduce: ============== 1- switch company. 2- update any other company currency that has journal items. 3- company currency changed. Problem: ========= - When switching companies, users could update the other company's currency even when journal items existed for that company. Solution: Solution: ========= - Added .sudo() to the account.move.line search to bypass access rights and properly detect existing journal items in that company. opw-4920206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219063 Forward-Port-Of: odoo/odoo#217929
This fix makes hidden bus worker errors and failed background promises appear in the bus logs. It helps support and development teams troubleshoot real-time communication issues more quickly, even when problems happen in background browser workers.
Original PR description
Bus behaviors are not easy to troubleshoot: - Worker devtools not easily available. - Errors are kept in the worker, never logged nor raised client side. - Worker communicates with many tabs. To ease troubleshooting the bus, logs were introduced. It's much better because they can be downloaded from any tab, survive reloads... However, unhandled errors/promises are not logged which is cumbersome. This commit adds unhandled errors/promises to the bus logging. 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#219085
This fixes an issue where turning off the general developer tool category could also stop device long-polling updates. Device actions and events now continue working as expected, reducing the risk of interrupted hardware communication during development or troubleshooting.
Original PR description
`devtools disable general` should not disable longpolling actions/events. We updated the `toggleable` wrapper to avoid this. Forward-Port-Of: odoo/odoo#219116
Point of Sale orders now correctly use the default price list and fiscal position when a preset does not define its own. This prevents orders from missing expected pricing or tax settings, reducing manual corrections and improving checkout consistency.
Original PR description
Before this commit, if the pricelist or fiscal position was not explicitly set on a preset, the order would not inherit the default values defined in the PoS config. This fix ensures that the system now correctly falls back to using the default pricelist and fiscal position from the PoS configuration when they are not specified on the preset. opw-4913400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217112
The website color picker now correctly shows when a selected background color is transparent instead of displaying it as solid red. This prevents confusion when configuring header backgrounds in the website builder and makes the picker reflect the actual design setting.
Original PR description
> click on header, "Header Position": "Over the Content", click on the color of the background, it is supposed to be transparent, but the picker shows solid red The changes in 41fec6b94900fa85febbfb0fd748a44747182cc6 causes the picker to show incorrect information when the selected color at the creation of the picker is transparent This commit changes the approach used to achieve the same goal (to get the color clicked on when clicking on the hue bar). Without faking a selected color when it is transparent Steps to reproduce: - Open website builder - Click on the header, and set "Header Position" to "Over the Content" - Click on "Background" - Bug: the color shown as selected by the picker is red, not transparent task-4367641
This fix prevents multiple Point of Sale sessions from being opened when the start request is delayed. It helps avoid duplicated cash opening records and related cash closing inconsistencies.
Original PR description
Before this commit, if request to open the PoS would take a bit of time there was possibility to have more than one session created. This issue would cause several issues, like incorrect opening and closing cash record as 2 sessions would be created with the same opening cash. To prevent this issue this commit adds a lock. opw-4890965 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217288
This fixes an issue in Point of Sale where special products could no longer be found through search or category filtering. Staff can now locate and sell these products as expected, reducing checkout friction and product visibility problems.
Original PR description
After commit https://github.com/odoo/odoo/commit/2668181c98de4a9c6f33787372adefc01cf1d0bc, it was no longer possible to locate special products via the search function. Additionally, if these products belonged to a specific category, they would not be visible when filtering by that category. opw-4925867 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217898
Turkish Nilvera e-invoices now place subscription billing period dates at the document level, matching the required UBL TR format. If subscription lines in the same invoice have different start or end dates, users are warned and sending/printing is blocked to prevent invalid e-invoices.
Original PR description
The UBL TR 1.2.1 format does not support \<InvoicePeriod\> element in invoice lines in the XML generated for e-invoice. This commit moves the \<InvoicePeriod\> element from invoice lines to document level. It also validates that the start and end dates of all subscription invoice lines in one invoice should be same, or else it shows warning and disables the `Send & Print` wizard button TaskId:4885865 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218820 Forward-Port-Of: odoo/odoo#215819
Refund orders in Point of Sale are now named correctly with the “REFUND” label. This makes it easier for staff and back-office users to identify refunds in order lists and reporting.
Original PR description
Currently, when refunding an order the name of the order does not show "REFUND". Steps to reproduce: ------------------- * Open pos session * Make an order * Refund the order * Go to the backend and see all orders > The refund orders does not show the "REFUND" label Why the fix: ------------ In previous version, when in `sync_from_ui` the state of the order in vals was 'draft'. In this version the state in vals is `paid`. This difference leads to the name being computed in `_complete_values_from_session`. This means that `_compute_order_name` is called before the order is fully created and thus `refunded_order_id` is not yet set and we're always using the next sequence to compute the order name. Now, when we already know the order is a refund we will not compute the name in `complete_values_from_session`. The name will get computed in `write`, which is called by `action_pos_order_paid`, as in previous version. opw-4521070 Forward-Port-Of: odoo/odoo#214542
This fixes inconsistent automated test behavior around the link popover in the HTML editor. The change helps keep quality checks stable and reduces false failures during development and release validation.
Original PR description
In 3145a4ffe2e64737297aab90f382fad9f1a29491, tests were adapted to use absolute urls if they failed because they tried to fetch metadata for relative url. Some tests open the link popover near the end, thus passed sometimes (when the test ended before the fetch error). These tests were also adapted in 06263227eb59ce0e0be2416d794ce50f907e1413. But the indeterminism that lead them to pass was not fixed (because of uncertainty about the correct appraoch) The tests failed sometimes because the metadata fetch is triggered in the `onMounted` of the link popover, which does not happen if the component is cancelled before it is rendered task-4367641
This update fixes an issue in Point of Sale where reducing an unsynced item's quantity to zero used an outdated internal action. Cashiers can now remove such items reliably, helping avoid interruptions during sales.
Original PR description
Before this commit, we were calling _unlinkOrderline on the order when decreasing the quantity of an unsynced line to 0 from the decreaseQuantityPopup. This method does not exists anymore so we replace this call with a call to removeOrderline. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218795
The website editor’s header formatting controls now have clearer spacing, and the text alignment dropdown is easier to use. This makes it simpler for users to choose the right alignment option when editing website headers.
Original PR description
Before this commit, the display of the text alignment dropdown was small, making it harder to select the desired option. There was also no space between the 3 formatting options for the header (font size, text color, alignment). This commit re-adds the spacing and makes the dropdown items the same size as other dropdown items from the edit sidebar. task-4367641
The website editor's image transformation controls now work reliably again, including resizing, rotating, active-state display, and closing the transform box. This improves the editing experience for website builders and prevents errors when adjusting images.
Original PR description
Description of the issue/feature this PR addresses: Fixed the working of the "Transform Image" button in website builder. Current behavior before PR: The button was non-functional due to an undefined "trasnformImage" user command. Desired behavior after PR is merged: The button works as as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix reduces the clickable area of padding controls in the HTML builder so they no longer get in the way when editing button text. Users can now more easily select and update text such as the “Contact Us” button while the padding controls remain usable and accessible.
Original PR description
Before this commit, the handlers for the padding option were too big, which made it really hard to click on the text of the "Contact Us" button (the focus would be on the handlers instead). This commit reduces the size of the clickable area around the handlers icons, enabling to edit the text of the "Contact Us" button, while keeping the handlers large enough to be accessible. task-4367641
This fix prevents Odoo from sending unnecessary invitation, update, or reminder emails for calendar events that have already ended. For events synced with Google or Microsoft calendars, it also ensures the external calendar handles reminders so users do not receive duplicate notifications.
Original PR description
Prevent sending unnecessary invitation or update emails for events that have already ended by introducing a method to check if an event is over. When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo should not send any additional reminders. Recently, we had to revert the two original PRs due to an emergency at odoo/odoo#215449. The issue got solved, so we're adding this fix back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr task-4684432, 4316693 Forward-Port-Of: odoo/odoo#219157 Forward-Port-Of: odoo/odoo#219060
Fixes an issue where the project creation dialog could remain stuck open after creating a new project. Users can now complete project creation and move into the new project's task view without being blocked by an unclosable popup.
Original PR description
- Open a Project; - Create a new project; Before this commit, the dialog that allows you to create a new project would sometimes stay open and could not be closed. This occurs because, since [1] and…
- Open a Project; - Create a new project; Before this commit, the dialog that allows you to create a new project would sometimes stay open and could not be closed. This occurs because, since [1] and especially [2], we waited for the view to reload before closing the dialog. However, while the view was reloading, it was destroyed and replaced by the Kanban view of the tasks of the new project. This meant that the reload promise was never resolved. Consequently, the code that actually closes the dialog [3] was never reached, as `await onClose?.(closeParams)` was never resolved. [1] https://github.com/odoo/odoo/pull/202512 [2] [d606be7](https://github.com/odoo/odoo/pull/202512/commits/d606be75c44fccf0b1ddf5216892f1d4b7162686) [3] [d606be7#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR318](https://github.com/odoo/odoo/pull/202512/commits/d606be75c44fccf0b1ddf5216892f1d4b7162686#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR318) opw-4880968 Forward-Port-Of: odoo/odoo#219065 Forward-Port-Of: odoo/odoo#218988
Sales orders containing kit products with repeated components can now be canceled and confirmed again without causing an error. This helps sales and warehouse teams avoid interruptions when revising or reprocessing kit orders.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/pull/207955
Steps to reproduce the bug:
- Create a kit product:
- BoM:
- Components:
- 1 unit of C1
- 1 unit of C1 (same product)
- Create a SO with one unit of kit
- Confirm the SO
- The delivery is created
- Cancel the SO → the delivery is canceled.
- Set the SO back to quotation and confirm again
Problem:
A traceback is triggered:
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: mrp.bom.line(24, 25)
When a kit's BoM contains the same product multiple times, multiple bom_line_ids match a given move. Assigning them causes an error. Additionally, cancelled moves were incorrectly considered.
Solution:
Filter out cancelled stock moves before accessing the bom_line_id to ensure only active moves are considered.
opw-4919875
Forward-Port-Of: odoo/odoo#218476
Forward-Port-Of: odoo/odoo#218187When a purchase order linked to a sales delivery is cancelled, the delivery can now use stock already on hand instead of staying blocked. This helps orders continue smoothly when purchased replenishment is no longer expected but inventory is available.
Original PR description
Steps to reproduce the bug:
- Unarchive the MTO route
- Create a product P1:
- Type: Storable
- Route: MTO
- Supplier: Vendor A
- Create a sales order for 1 unit of P1
- Confirm the SO
→ A purchase order is created for Vendor A with 1 unit of P1
- Cancel the PO
- Update the quantity on hand of P1 to 1
- Go to the delivery picking of the SO
- Check availability
Problem:
The quantity on hand is not taken into account, and the picking remains
in the "Waiting Availability" state.
When the purchase order is cancelled, the stock move should switch to
MTS instead of remaining in MTO.
opw-[4876611](https://www.odoo.com/web#id=4876611&view_type=form&model=project.task)
opw-[4874199](https://www.odoo.com/web#id=4874199&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#218365
Forward-Port-Of: odoo/odoo#214785Calendar views that support creating multiple records now always show the sidebar, even if a user previously hid it in another calendar. This prevents users from getting stuck without access to required sidebar actions in those views.
Original PR description
The sidebar can be toggled in calendar views where the multi create feature isn't enabled. The toggled status is then stored in the session_storage s.t. when coming back, it is restored. In calendar views with the multi create feature, the sidebar can't be toggled: it is always displayed. Before this commit, if the user first went to a "normal" calendar view, toggled off the sidepanel, and then went to a calendar view with multi_create, the sidepanel wasn't displayed (and there was no way for him to toggle it in that view). This commit fixes the issue: when the multi_create feature is enabled, the sidepanel must always be displayed, no matter the state saved in the session_storage. 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#219040
Pop-up elements such as date pickers now close automatically when users move between pages, including with the browser back or forward buttons. This prevents old popovers from lingering on screen and improves the overall navigation experience.
Original PR description
Before this commit, popovers like the datepicker remained open when navigating between pages, using the browser's previous/next page button for example. In this commit, popovers listen to page changes and are closed when such events are detected. Task 4812869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217148
This update adjusts some internal message text formatting so Odoo's translation tools work reliably on Ubuntu Jammy. It helps prevent automated build failures without changing business workflows or user-facing features.
Original PR description
On Jammy, babel does *not* cope well with f-strings as values inside `_()` calls: it uses `eval` to try and figure them out, which attempts to execute the f-string, which fails because the evaluation context is empty. This is likely fixed from Babel 2.11 onwards (python-babel/babel#915) but Jammy uses babel 2.8[^1]. https://runbot.odoo.com/odoo/runbot.build.error/97849 [^1]: This doesn't seem to trigger on Noble even though it uses 2.10, but locally it does trigger on 2.10.3 (installed via pip), so ubuntu might have backported the fix or something. Forward-Port-Of: odoo/odoo#218887 Forward-Port-Of: odoo/odoo#218803
Fixes an issue in Project reporting where clicking chart bars after grouping by tasks could fail because report-only filters were sent to the task view. The system now removes incompatible filter fields before opening the detailed task view, making report drill-downs more dependable for users.
Original PR description
Step to reproduce - Go to Project - Go to Reporting > Task Analysis - Group by Tasks (not Task) - Click on any of the blue bars Issue: since odoo/odoo@c36ad1896 we now allow user to drill down to base model from report view, this causes issue when a field which is present in report model but not in base/main model. For now we directly pass the domain created for report view to base model. FIx: we only open the view, when the such fields are not present in domain opw-4798353 related : https://github.com/odoo/enterprise/pull/88356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215167
Regular users can now filter email templates by category without hitting an access error. This keeps the template selection flow working smoothly when sending emails from documents such as sales or purchase orders.
Original PR description
Since commit 42be7cebc84ac4af36104b6d2eba9d3e5d115005, filtering mail templates on their category triggers a search on `ir.model.data` to avoid a memory error on a database having a lot of mail…
Since commit 42be7cebc84ac4af36104b6d2eba9d3e5d115005, filtering mail templates on their category triggers a search on `ir.model.data` to avoid a memory error on a database having a lot of mail templates. However, regular users don't have a read access to this model, so when a user tries to filter on the template category, they get an `AccessError`. With this commit, we add a `sudo()` on the search on `ir.model.data`, so that this error doesn't occur any more. To reproduce the issue on a runbot, follow these steps: - connect as *demo* on a 18.0 database - open a *Sale Order* or a *Purchase Order*, and click on *Send by email* - in the modal dialog, click on the vertical three dots to select a template - if *Search More...* is not available, save the template several times with different new names until *Search More...* appears on the list - click on *Search More...* - in the *Search...* field, click on one of the *Base Templates* or *Custom Templates* filters - boom! `Access Error, You are not allowed to access 'Model Data' (ir.model.data) records.` Forward-Port-Of: odoo/odoo#219034
Highlighted title text with animation now keeps animating correctly when the page is viewed on smaller screens and the text wraps onto multiple lines. This prevents broken visual effects on published website pages, improving consistency for visitors and editors.
Original PR description
Steps to reproduce: 1. Go to Website (Edit mode) and drop a title block. 2. Select the title and set a highlight effect, then a text animation on it, and save the page. 3. Load the page in a reduced viewport in a way that makes the highlighted text split into multiple lines. 4. The animation won't work. The issue is caused mainly by the highlights being automatically split (and also the animation wrapper inside) when there is no available space for the text content, which destroys the "animation" interaction targeted element without retargeting the new wrappers. The goal of this commit is to fix this behavior by forcing the animation to target the whole highlight when a part of its content is animated. opw-4865891 Forward-Port-Of: odoo/odoo#218445
This update corrects accounting demo data so reconciliation models are linked to the proper suspense account instead of the liquidity account. It helps demo environments better reflect the intended accounting workflow and avoids confusing reconciliation behavior after use.
Original PR description
Correcting some demo data where they added the reconcile model on the liquidity but since the reco model will be added at the creation of the reco model, that's not needed. Also the reco model should be put on the suspense and not on the liquidity task: 4908501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216902
Website footer updates now handle expected formatting issues without hiding serious database conflicts. This helps prevent failed update processes and allows automatic retry handling when concurrent edits happen.
Original PR description
Updating website footer views sometimes fails with "could not serialize access due to concurrent update" errors due to concurrent database writes, causing transaction aborts and breaking the update…
Updating website footer views sometimes fails with "could not serialize access due to concurrent update" errors due to concurrent database writes, causing transaction aborts and breaking the update process. Error: `InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block` The issue arises because the exception block at [1] catches and silently suppresses all exceptions, including critical `serialization errors`. These serialization errors cause the current database transaction to fail. However, since the exception is caught and not properly handled or propagated, execution continues within the context of the failed transaction. As a result, subsequent operations fail with an `InFailedSqlTransaction` error. This commit addresses the issue by specifically handling the `etree.XMLSyntaxError` raised by `etree.fromstring(view_id.arch_db)`. The error is safely caught and logged with an appropriate message. Additionally, it adds logging when the `configurator_footer_links` element is not found in the view and prevents further execution in that case. All other exceptions, including database-related errors, are no longer caught at this level; instead, they are allowed to propagate and are handled at the request level, where automatic retries are triggered. handled at the request level, where automatic retries are triggered. [1]:- https://github.com/odoo/odoo/blob/5cc57cc0ca8ee17060905b692727ed965e197f61/addons/website/models/website.py#L722-L725 sentry-5665538920 Forward-Port-Of: odoo/odoo#210103
This fix stops users from creating recruitment stage email templates without the required linked model. It prevents errors when moving applicants into stages that use those templates, making the hiring workflow more reliable.
Original PR description
An error occurs when a user quickly creates a template for a stage, bypassing the validation of the `Applies to` field. As a result, an error is triggered when the user selects a stage that uses that template. **Steps to reproduce:** * Install `hr_recruitment` * hr_recruitment>Configuration>Stages>stage named `New`>Quick Create a mail template with random name and save. * Applications>All Applications>New application>Set stage to `New` `KeyError:False` **Solution:** * Disable quick create as to prevent creating mail templates with empty model ids. **Sentry-6675399135** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214195
Submitting the UAE VAT201 tax return no longer triggers an error caused by using the wrong report calculation. This helps businesses complete VAT filings reliably without being blocked by a system traceback.
Original PR description
When submitting a tax return for the basic AE tax report (VAT201 Form), a traceback was being thrown. The issue arose because the report was considered to be the Corporate Tax report instead of the VAT201, and was trying to apply some incompatible computation. task-4935937
This fix corrects how accident or sickness-related days are calculated in Swiss payroll reporting. It helps ensure payroll declarations use accurate day counts, reducing the risk of incorrect employee payroll data being submitted.
Original PR description
Forward-Port-Of: odoo/enterprise#90191 Forward-Port-Of: odoo/enterprise#90153
The asset depreciation schedule now opens correctly when draft assets do not yet have generated journal entries. This prevents an error that could block users from reviewing planned depreciation information.
Original PR description
Issue: https://github.com/odoo/odoo/issues/219112 Steps to reproduce:- - Minimum 1 asset in draft - Computation board not computed yet - Opening the depreciation schedule with draft entries. Cause:- - When asset is in draft and computation board is not computed yet no Journal Entries are created for that asset. - `asset_date` is minimum value among dates of related moves. - In this case there are no moves yet so `asset_date` is 'NoneType' - `asset_date = min([asset_date, move_vals['date']])` - In above line when we try to compare 'datetime.date' and 'NoneType' it gives rpc error. Fix: `min([asset_date, move_vals['date']]) if asset_date else move_vals['date']` Followup on commit: https://github.com/odoo/enterprise/commit/eb57a9bc4066ece08059384742d70705a646bbdc Forward-Port-Of: odoo/enterprise#90308
Deleting a field match in a spreadsheet global filter is now properly saved. This prevents users from seeing removed filter settings reappear after saving, making spreadsheet filter configuration more reliable.
Original PR description
Steps to reproduce: 1. Open a spreadsheet with global filters. 2. Open the global filter editor. 3. Open a global filter. 4. Delete the field matching (and nothing else). 5. Save the global filter. => The field matching is not saved. This was due to the fact that the removal of the field matching makes an early return in the `updateFieldMatching` method, which had for last instruction to set the `draft` property to mark the filter as dirty. This commit fixes the issue by ensuring that the `draft` property is set even when the field matching is removed. Task: 4882261 Forward-Port-Of: odoo/enterprise#89621
Helpdesk reporting now avoids using report-only filters when opening the underlying ticket list from a chart. This prevents errors when users click bars in Ticket Analysis and makes drill-down reporting more reliable.
Original PR description
Step to reproduce - Go to helpdesk - Go to Reporting > Ticket Analysis - Group by `Ticket` - Click on any of the blue bars Issue: since odoo/enterprise@d64db03f we now allow user to drill down to base model from report view, this causes issue when a field which is present in report model but not in base/main model. For now we directly pass the domain created for report view to base model. FIx: we remove such fields from domain and then load the view opw-4798353 related: https://github.com/odoo/odoo/pull/215167 Forward-Port-Of: odoo/enterprise#88356
This update ensures the admin user has an email address during quality control worksheet test runs. It prevents a sender email configuration error, making automated checks more reliable without changing day-to-day product behavior.
Original PR description
Set the admin user's email explicitly to prevent "Please configure the sender's email address" error when running the tour with login='admin'. build_error-226779 Forward-Port-Of: odoo/enterprise#88283
Salary configuration and offer flows now save personal details such as address and marital status on the correct contract version record. This prevents employee offer data from being stored in the wrong place after the contract version model change, improving accuracy for HR and Belgian payroll processes.
Original PR description
With the change from the contract to the version model, more adaptation was required for the salary configuration and the offer management. Before that change, the personal info were always written on the employee model. But now, some of the personal information (like the address or the marital status) need to be written on the new version. This commit fixes the issue by adding support to directly write the version fields of the salary configurator on the new version. task-4933745
The IoT setup process now updates an existing IoT box record only when the incoming information has actually changed. This reduces needless database writes and helps keep setup activity cleaner without changing user-facing behavior.
Original PR description
Currently when /iot/setup method is called if the iot box record exists we always update the record with the received data, even if the data is the same as the record's data. This PR only updates it if the data changes Forward-Port-Of: odoo/enterprise#88210 Forward-Port-Of: odoo/enterprise#88043
Signing and counter-signing a job offer now assigns the correct current contract salary version to the newly created employee. This prevents archived versions from being selected by mistake, helping HR records remain accurate after recruitment offers are completed.
Original PR description
When signing an offer, an employee and a version are generated. Some methods of the controller are using the active_test context, but without resetting to its default value. This was causing some issue when creating or computing field of the versions. For example the current_version_id was computed to be an archive version, which is wrong. This commit fixes the issue by resetting the active_test context to its default value. The new version is also unarchived before archiving the old version to not trigger the version constraint about the active field. Steps to reproduce: - Create a job position and a candidate in recruitement. - Generate an offer for the candidate. - Sign and counter-sign. - The current version on the newly created employee is wrong. task-4926361
Deleting bank statement lines after applying a reconciliation model now keeps the model available by restoring it to the suspense line. This prevents users from losing reconciliation setup during corrections and keeps bank reconciliation workflows consistent.
Original PR description
Before this commit when applying a reco model, the reco model is on the lines of the move except the liquidity line which means that when we delete the lines the reco models is lost. Now when deleting a line, if the statement line had a reco model, we place it back on the suspense. Also correcting some demo data where they added the reconcile model on the liquidity but since the reco model will be added at the creation of the reco model, that's not needed. task: 4908501 Forward-Port-Of: odoo/enterprise#89147
Facebook removed support for the metric previously used to calculate stories activity, which caused reporting errors and could make other statistics show as zero. This update removes that unavailable Facebook stories statistic so the remaining social media metrics continue to work reliably.
Original PR description
Bug === `page_content_activity` has been deprecated, so the API return an error and the other statistics are set to zero. https://developers.facebook.com/docs/pages-api/changelog Now, the only equivalent is `post_activity_by_action_type`, but it needs to be called on all posts, and it does not support periods (so even if we call it for each post, we won't be able to compute the trend). So we simply removed the `stories` statistics for Facebook. Task-4914555 Forward-Port-Of: odoo/enterprise#89524 Forward-Port-Of: odoo/enterprise#89230