Wednesday, July 2, 2025
38 changes · saas-18.4
Resolved issues and error corrections
Invoice reports now show the standard invoice date and the Saudi confirmation date separately, reducing confusion when invoices are backdated. Issue dates are consistently shown using Saudi Arabia timezone, regardless of the customer’s location.
Original PR description
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will display both the standard invoice date and l10n_sa_confirmation_date separately for clarity. The issue date will always be passed in SA timezone to the report to ensure consistency, regardless of the partner's country. task-4508551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216684 Forward-Port-Of: odoo/odoo#214937
Argentina B invoices for final consumers now include the required tax breakdown even when VAT is 0.00. This helps businesses produce compliant customer invoices and avoids missing tax legend information on printed PDFs.
Original PR description
### **Description of the issue/feature this PR addresses:** When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or…
### **Description of the issue/feature this PR addresses:** When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or other taxes sum is 0.0 (we are not showing any information if sums 0.0) After checking with ARCA Online PDF sxampels, and some feedback of Argentinen users, we found out that the Legend should be always present. event if the totals of theTax Breakdown are shown with 0.0 ### **Steps to reproduce** Go to an Argentina Company Create a new invoice for "Final Consumer" with document type "Invoice B" Create a product line with tax 0 (could use either VAT Exempt, VAT 0, VAT Not Taxed) Print the PDF ### **Current behavior before PR:** The PDF is NOT showing the Tax Breakdown table  ### **Desired behavior after PR is merged:** The PDF is showing the Tax Breakdown with the line VAT Content 0.0  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Manual Forward-Port-Of: https://github.com/odoo/odoo/pull/207367 Forward-Port-Of: odoo/odoo#214866
The employee time off calendar report once again opens with the intended default filters. This helps managers and HR users see the expected leave information without manually reapplying filters.
Original PR description
- `hr_holidays` promenade removed the default filters added in [task-4672501](https://www.odoo.com/odoo/project.task/4672501) - this PR adds them back in. task: 4815435 Forward-Port-Of: odoo/odoo#211212
This fix prevents an error from appearing in Point of Sale when a self-order is paid while the related POS configuration is open. It avoids processing empty synchronization data, making ticket printing and session updates more reliable for staff.
Original PR description
The issue is not reproducible in saas-18.2 however since the method _read_pos_record is introduced in saas 18.2 the issue could arise in this version. Step to reproduce in saas-18.3: - Make an order in self order mode - Pay it, while the linked pos config is open - A traceback will be shown in the pos config Issue: When printing the ticket on the pos config, notify_synchronisation function is called with no records in the session model. _post_read_pos_data will be called with empty data array. Fix: Prevent calling _post_read_pos_data with empty records. 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#216229
This fixes an issue where installing Timesheets caused the Employees kanban view to show two delete buttons. Employees now see a cleaner, less confusing interface with only one delete option.
Original PR description
Description of the issue/feature this PR addresses: In this PR, we removed the duplicated delete button from the hr employee kanban view when the timesheet app is installed. Root Cause: We missed to inherit the hr employee kanban view within the hr timehseet. Current behavior before PR:  Desired behavior after PR is merged:  Related task: 4843996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212917
Automated web tours now handle page reloads correctly when they start or resume. This prevents false errors during guided testing flows and makes tour execution more reliable for teams validating business processes.
Original PR description
When a tour starts (or resumes), the first step of the macro may not be executed even though the page is already reloaded (e.g. client_actions.js => reload). In this case, the value of allowUnload was false and triggered an error. This was fixed by setting allowUnload to true, and then recalculating the value of allowUnload at each step. 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
This fixes Malaysia e-invoicing so credit notes can still be reported to MyInvois even when the original invoice was not previously sent there, such as invoices created before MyInvois adoption. It also aligns the reported issue date with MyInvois requirements by using today's UTC date.
Original PR description
So far, we have enforced that credit notes must be linked to an invoice that has been sent to MyInvois. In real life, this is too strict. Users could be issuing credit notes for invoices created before MyInvois was used, in which case these must still be reported to MyInvois even though the original invoice isn't on the platform. This also fixes a small issue with the issue date, which was set to the invoice date up until now but on their platform they explicitly ask for today in UTC timezone. task-4889022 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216988 Forward-Port-Of: odoo/odoo#215347
This fixes an issue where allocation records opened from a time off type could all show the same remaining balance for one employee. Users will now see accurate allocation information instead of misleading duplicate balances.
Original PR description
### Steps to reproduce: - Create a Time off type - Create allocations for some employees with the created type - Navigate to an allocation for a specific employee - Click on the time off type in the allocation form - Click on the smart button 'Allocations' - Notice each record showing the same time off type (X remaining out of Y) ### Cause: This is happening because when going through the allocation of a specific employee we add him in the context 'employee_id' so we compute the display name of the leave type and set it for each record as the same value as we compute leaves depending on the contextual employee. ### Fix: We are preventing the computation of the display name by forcing the employee_id in the context to force when we are using the smart button for allocations in the time off type form view opw-4841096 Forward-Port-Of: odoo/odoo#216699 Forward-Port-Of: odoo/odoo#215454
Fixed an issue where delivery orders could calculate the wrong quantity for components in nested kit bills of materials when rounding was involved. This helps ensure inventory movements match the quantities shown in the BoM overview and prevents overstated component usage.
Original PR description
## How to reproduce - Create 3 products: "FNS" / "CMP 1" / "CMP 2", the three of them with an UoM of 2 digits precision - Create Kit BoM for 1 Unit of "FNS" using 10 Units of "CMP 1" - Create Kit BoM…
## How to reproduce
- Create 3 products: "FNS" / "CMP 1" / "CMP 2", the three of them with an UoM of 2 digits precision
- Create Kit BoM for 1 Unit of "FNS" using 10 Units of "CMP 1"
- Create Kit BoM for 5000 Units of "CMP 1" using 50 of "CMP 2"
- Check "FNS" BoM Overview:
- "CMP 2" quantity shows the correct 0.10 Units (1 * 10 / 5000 * 50) (ok)
- Create Delivery order for 1 Unit of FNS
- "CMP 2" quantity is 0.50 Units (KO)
OPW-4804958
---
### BoM Overview
### BoM exploded
---
### Test result without fix:
```
2025-06-25 00:00:00,000 28629 ERROR oes_test_17 odoo.addons.mrp.tests.test_bom: FAIL: TestBoM.test_02_explode_rounding
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/tests/test_bom.py", line 63, in test_02_explode_rounding
self.assertEqual(lines[0][1]['qty'], 0.10)
AssertionError: 0.5 != 0.1
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#216709
Forward-Port-Of: odoo/odoo#215821This update corrects how POS printers are linked to point-of-sale configurations. It helps ensure printer settings are associated with the right POS setup, reducing configuration issues for stores.
Original PR description
Before this commit, the Many2many field used an incorrect model name 'pos.printer' instead of the correct 'pos.config' This commit fixes the relation to ensure proper association between printers and POS configurations --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216563
This fix ensures that when the HR Contracts module is uninstalled, HR menu items are returned to their correct original locations. It prevents confusing or misplaced navigation for users after module removal, with minimal impact on day-to-day use.
Original PR description
This PR adds an uninstall_hook to restore the correct parent menus under the hr module that were overridden by this module. Task: 4818020 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213957
When no hourly time off types are configured, the time off request form now automatically selects an available time off type. This prevents confusion or blocked requests when employees create time off from the calendar in day or week views.
Original PR description
Steps To Reproduce: - Archive all Hourly timeoffs - Now raise a new timeoff from calendar from days/week Fix: - When there are no "Hourly Time Off" types configured in the company, pre-select an available time off type task-4702467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209451
The system now blocks E-way bill generation when the related document is not in an allowed state, such as cancelled. This helps businesses avoid creating invalid compliance documents and ensures E-way bills are generated only for finalized, valid records.
Original PR description
In this commit: --- - Introduced a validation to raise a `UserError` when attempting to generate an E-way bill if the document is not in a valid state (e.g.- `cancelled`). - This ensures E-way bills are only generated when the document is in the correct state (e.g.- `posted`) --- Forward-Port-Of: odoo/odoo#216167 Forward-Port-Of: odoo/odoo#206867
This fixes the boxed invoice PDF layout so the totals table has a consistent border after spacing was added. The change restores a cleaner, more professional report appearance for printed documents.
Original PR description
**Description:** Due to a recent [commit](https://github.com/odoo/odoo/commit/12ef230df58122fbdac0b4c1b4781c535b8516ba), a margin-top was added to the total table for the report type-pdf.…
**Description:** Due to a recent [commit](https://github.com/odoo/odoo/commit/12ef230df58122fbdac0b4c1b4781c535b8516ba), a margin-top was added to the total table for the report type-pdf. Previously,in the box layout, this table did not have a top border because it appeared visually connected to the preceding table — they seemed seamlessly joined. However, after the margin was added,the table now appears visually disconnected, making the absence of a top border look inconsistent and awkward. Steps to reproduce: - install account module - select box external layout - create invoice - print report as pdf Before commit:  After commit:  opw - [4873157](https://www.odoo.com/odoo/project/70/tasks/4873157) upg - [2839564](https://upgrade.odoo.com/odoo/upgrade.request/2839564) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214803
Pinned message notifications in Live Chat now display the livechat username when one is available, instead of showing both the regular name and livechat name. This removes duplicate-looking names and makes chat history clearer for operators and visitors.
Original PR description
**Current behavior before PR:** When a user pinned a message in livechat, both the regular username and the livechat username were shown, resulting in a duplicate display. This happened because the notification message used `username` directly, while `livechat_username` was separately injected in the template, leading to redundancy ([here](https://github.com/odoo/odoo/blob/f4c42ee65c8ec0511e1d5fd6063680328da365e8/addons/mail/static/src/core/common/notification_message.xml#L10C33-L10C34)). **Desired behavior after PR is merged:** Pinned notification message now show the livechat username if available. **Task**-4715349 before / after   --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204829
This update fixes nightly checks around CRM and event counters and makes event-to-CRM lead handling faster in common scenarios. It helps keep automated monitoring stable while reducing unnecessary background work during event registration processing.
Original PR description
Forward-Port-Of: odoo/odoo#216798
Embedded live chat calls now support picture-in-picture controls correctly. This helps visitors and agents keep video conversations visible while continuing to use the website or chat interface.
Original PR description
Forward-Port-Of: odoo/odoo#214956
This fix adjusts a font size used in the HTML editor’s automated tests to avoid inconsistent rounding on the test platform. It helps keep quality checks stable without changing how users edit or view content.
Original PR description
It looks like, on runbot specifically, the previously chosen size unfortunately resulted in a size near the 0.5px mark. Because of that, sometimes it would be rounded down and sometimes up. Hopefully changing to another font size won't have the same issue. If it does then we'll need to manually choose either to always round down or up. Forward-Port-Of: odoo/odoo#216611
The time-off form now avoids showing an overlap warning when an employee edits dates that still remain within the original approved period. This reduces confusing alerts for HR users and employees while keeping real conflict checks in place.
Original PR description
### Steps to reproduce: - Create a time-off with dates from X to Y. - Attempt to modify the start or end date to a value that still falls within the original X–Y range. ### Fix: - Updated the condition to correctly retrieve the current record's ID using .ids ,since .ids can also include the origin ID. Task-4819538 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211795
Guest visitors on public Discuss pages can now open the invite people action from the sidebar without encountering an error. The change prevents the page from trying to focus a search field that is not available for guests, improving reliability for public conversations.
Original PR description
Before this commit, when opening the invite people action from the sidebar in discuss public page as a guest you would get a traceback. This happens because the component has a useEffect that focuses the search input, but that element is not present as a non partner. This commit fixes the issue by adding a guard in the useEffect. task-4904119 Forward-Port-Of: odoo/odoo#216327
Dropdown labels in the HTML builder now shorten visually when they are too long, instead of taking up excessive space. This keeps nearby controls usable and improves the editing experience for pages with lengthy option names.
Original PR description
This PR allows dropdown labels to truncate within the `html_builder` environment. Prior to this PR, an `auto` value was assigned to the `flex-basis` property meaning it would take as much space as its content, meaning that if the label is very long, siblings wouldn't have enough space to grow. With this PR, we remove this `flex-basis` value an rely on the other `flex` values already defined, as well as the `min-width`. task-4910410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Expenses screen no longer shows two New buttons in the Kanban view on small screens. This reduces confusion for users creating expense records and keeps the upload control placement consistent across list and Kanban views.
Original PR description
This commit avoids a duplicated "New" button definition and being displayed in the Expenses Kanban view on small screen. It also moves the hidden input used for upload next to the button calling it in both List and Kanban views (for coherence). Steps to reproduce (in small screen): - Open Expenses app => double "New" button : one displayed, one in the dropdown --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216799
The mail message composer now keeps a proper height even before users type anything. This avoids a visual jump in Chromium-based browsers, making message writing feel smoother and more polished.
Original PR description
Before this commit, composer height was too small when it had no content. This lead to composer changing height when typing some characters which looks off. This bug is specific to Chromium browsers and seems to be new since Chrome 138.0. The code expected that textarea had unchanged scrollheight when textarea has height 0 and fits its content in at most 1 line, but this seems to have changed with Chrome 138.0. This commit fixes the issue by cheating when composer is empty: the fake textarea artificially adds a character so that the computation for height when empty works as if it has 1 character, thus the computed height is the same when there are few characters in composer. Forward-Port-Of: odoo/odoo#216743
This fix prevents an error from appearing on the preparation display when an order is marked done shortly after it arrives in debug mode. It adds a safety check so the screen no longer tries to use order data that has already been removed, improving reliability for point-of-sale kitchen workflows.
Original PR description
Steps to reproduce: - Open a preparation display in debug mode - Make an order that will appear on the preparation display - Click on the done button before 5 seconds - Traceback will appear 5 seconds after the order was received Issue: When receiving an order useDelayedValueChange is called in the setup of the Orderline component. This method will try to access the props after a timeout. When the preparation orders are deleted in debug mode, the states are deleted from the front end. Since the props of orderline are the preparation state linked to it a traceback arises. Fix: A check is added to check if the state record exists. Forward-Port-Of: odoo/enterprise#88136
Swedish SIE4 transaction imports now ignore extra object-list details that are not needed for accounting entries. This prevents those details from being mistaken for transaction balances, reducing import errors and improving data accuracy.
Original PR description
The aim of this commit is ignoring the whole object list when we import transactions. The object list is represented by the elements between `{}` [[1]]. As we don't need these elements, we do ignore them to avoid a potential issue where we identify an element from this object list as the transaction's balance.
opw-4868415
[1]: https://sie.se/wp-content/uploads/2020/05/SIE_filformat_ver_4B_ENGLISH.pdf
Forward-Port-Of: odoo/enterprise#88892
Forward-Port-Of: odoo/enterprise#88784Belgian payroll termination holiday reports now use the payslip dates rather than contract dates to determine the exercise and holiday period. This helps ensure employees receive reports with the correct holiday-related information when a contract ends.
Original PR description
The exercise and the holiday period should be based on the payslip instead of the contract. We use the values of the report report_termination_holidays_n and report_termination_holidays_n1 which contains the correct values. Forward-Port-Of: odoo/enterprise#88737
Employees in Mexico with only variable pay, such as commissions or bonuses, can now have payslips generated without an error. The fix ensures the employer social security contribution calculation handles wages outside expected ranges correctly, improving payroll reliability for affected employees.
Original PR description
BUG An error is raised when trying to generate a payslip for an employee with only variable income (e.g., commissions/bonuses, no fixed base salary) FIX The rule's find_index function needs to return 0 instead of None in case the daily_wage does not fall within any of the measure ranges Task: 4723413 Forward-Port-Of: odoo/enterprise#89041 Forward-Port-Of: odoo/enterprise#85756
This fixes the conditions used to apply payroll subsidies in the Mexican payroll module. It helps ensure employee payslips calculate the subsidy only when appropriate, reducing payroll errors and correction work.
Original PR description
task-4690544 Forward-Port-Of: odoo/enterprise#84780
Users who work with Helpdesk and Inventory but do not have Sales access can now create repair-related tickets without seeing an access error. The change avoids checking a restricted sales field when the user is not allowed to view it, keeping the workflow available for the right teams.
Original PR description
### Before this PR If an user has only inventory, helpdesk group and it does not have "sales" permission , the error "you have not access on this field sale_order_id" appear. It appears because on helpdesk_sale that field is restricted to two specific groups. In the same module that fields is popped out during copy , but in the prepare of helpdesk_repair is accessed without checking permission ### After this PR The field is not accessed if it has no permission Forward-Port-Of: odoo/enterprise#86514
Fixed an issue in the VoIP mobile keypad where the cursor could jump and place the first typed number at the end of the input. This makes entering phone numbers on mobile more reliable and avoids dialing mistakes caused by misplaced digits.
Original PR description
This commit fixes a bug that caused the cursor in the keypad input to be displaced when typing on mobile. So, the first entered number was always to the end. This happens because the `on-touchend` event was calling another event (click) which may involve some changes in the UI that caused this. Steps to produce the bug: 1. Open VoIP wizard from mobile. 2. try to add numbers to the keypad. 3. You will see that the first number is always at the end. Forward-Port-Of: odoo/enterprise#89151
CSV bank statement imports now avoid failing when automatic matching encounters an issue, because matching is handled in the background after import. The reconciliation process also prevents multiple statement lines from being matched to the same already-used entry, reducing import errors and incorrect matches.
Original PR description
When doing an import of a csv in the bank rec widget, it could happens that the try_auto_reconcile throw an error which will lead in the rollback of the import. By triggering the schedule action auto_reconcile_bank_statement_line we will do the try_auto_reconcile in the back ground which will speed up the import process When importing, we pass a batch of statement lines to the try_auto_reconcile function, which identifies possible reconciliation candidates for each line. The issue arises because we iterate through each statement line and assign its potential candidate without checking for conflicts: if two statement lines map to the same candidate, we don’t verify whether that candidate has already been reconciled with a different line. opw-4888045,4890008 Forward-Port-Of: odoo/enterprise#88529
This fixes a small internal mistake in the Avalara tax integration where the system tried to call a non-existent follow-up step. The change prevents unnecessary or incorrect processing paths, with no expected visible impact for standard users.
Original PR description
This is a typo from the most recent refactor [1]. The commit hook is specific to US avatax, there is no corresponding super().commit_external_taxes so this can be removed all together. This didn't break any tests because (at least with the standard code), super()._uncommit_external_taxes is an empty method that does nothing. [1] https://github.com/odoo/enterprise/pull/82623
The Partner Ledger partner filter now includes companies even when they are linked to a parent company. This helps users find and filter the correct business partners more reliably in accounting reports.
Original PR description
Steps to reproduce - create a company - add a contact to this company - go to its contact form and transform this contact from Individual to Company - go to the Partner Ledger - open Partner filtering dropdown list Current behavior - show company and individual with no parent Expected behavior - show individual with no parents and all the companies - Company with parent company seems to be the expected behavior since 2016. If there is one, the Parent company appear in the contact form as defined [there](https://github.com/odoo/odoo/blob/9b03d99fd0174bd67c8ea30e5fd2c26fb2ad2467/odoo/addons/base/views/res_partner_views.xml#L168) opw-4729020 Forward-Port-Of: odoo/enterprise#87017
The Spanish Mod 349 BOE export now includes required rectifications when an invoice is fully cancelled by a credit note in a later period. It also prevents draft-reset invoices and credit notes from being wrongly included, improving compliance and report accuracy.
Original PR description
How to reproduce the issue: With l10n_es on an ES company: - Create an invoice from two months ago with a value of 1000. - Fully credit note this invoice on the current month. - On the mod 349 report, download the BOE report. The BOE report does not contains the rectification despite being mandatory as per: https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 (look at the examples in CUMPLIMENTACIÓN DEL REGISTRO DE RECTIFICACIONES). This commit also fixes an issue where invoice reverted to draft where included in the boe report: - Create an invoice of 100 in January, credit note 50 in May. - Reset to draft both the invoice and the credit note. - Create another invoice of 888 in February, credit note 444 in May. - Generate the BOE report. The invoice reverted to draft is included in the boe report. opw-4653025 Forward-Port-Of: odoo/enterprise#88625 Forward-Port-Of: odoo/enterprise#86127
Users can now connect an online bank account even when Odoo Fin reports a currency that differs from existing journal or bank account entries. Instead of blocking setup with an error, Odoo skips updating the currency and lets synchronization continue.
Original PR description
This commit avoids blocking users when connecting a journal to an online account that has a predefined currency. Previously, if the journal or its default bank account had entries in a different currency than the one sent by Odoo Fin, the process would fail with an error, preventing completion. Now, the system silently ignores the currency mismatch error and skips setting the currency, allowing the synchronization to proceed. opw-4751616 Forward-Port-Of: odoo/enterprise#89042 Forward-Port-Of: odoo/enterprise#88654
Rental orders using material resources now correctly recognize already planned shifts. This prevents the order from showing “To Plan” when the required material planning has already been completed.
Original PR description
_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to…
_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to `Material`. - Create a SO for the newly created product and confirm it. - Observe the state button the shift is already planned but it incorrectly displays `To Plan`. Issue: - Confirming the SO the shift is already planned but the state button still displays `To Plan`. this issue occurs when the resource type is `Material` However it works correctly when the resource type is `User`. Cause: - When we are calculating the planned hours the domain `'resource_type', '!=', 'material'` is passed causes resources type of Material so it will be excluded from the calculation. Fix: - In this commit removed the condition that excluded resources of type Material so that they are included when calculating the planned hours. This ensures the state button shows the correct status. task-3978597 Forward-Port-Of: odoo/enterprise#75861
Helpdesk tickets will no longer be closed when automated email scanners check links in customer emails. Only an actual customer opening the close link in the expected way will close the ticket, reducing accidental closures and support confusion.
Original PR description
Currently some customers with email scanners will have their ticket closed soon after it's opened. Steps to reproduce ----- 1. Enable "Closure by Customers" on the helpdesk team 2. Create a new ticket 3. Send a HEAD request to the "Close ticket" link in the received email, using `curl -I <url>` 4. The ticket gets closed Cause ----- Some email scanners send HEAD requests to links contained in emails, which is incorrectly interpreted as a user action. Fix ----- Implement a check so that only GET requests to the route will close the ticket. opw-4837167 Forward-Port-Of: odoo/enterprise#89026 Forward-Port-Of: odoo/enterprise#88547
This fix ensures that when a user enables form access for a selected model in Website Studio, the setting is properly saved. It prevents forms from losing access configuration after saving and returning to edit mode, reducing setup errors for website forms.
Original PR description
In [1] miscellaneous fixes about website forms in ´website_studio´ were put in place, but the actual flag about giving access to the given model was not actually set. This commit adds the missing statement. Steps to reproduce: - Install `website_studio` - Drop a Form - Select "More models" as Action - Pick a model - Save - Edit and select form => Access form was not enabled. [1]: https://github.com/odoo/enterprise/commit/89fc1023c146a83809f8cfa202177fe44a1aa25a task-4367641