Daily updates from Odoo
Tuesday, September 9, 2025
33 changes · saas-18.3
New functionality added to Odoo
This change adds a shared way for Odoo modules to provide KPI information, making future reporting easier to extend. Accounting now contributes counts of draft accounting documents by type, helping surface operational status in a consistent format.
Original PR description
This commit introduces a new abstract model `kpi.provider` that allows different modules to contribute their Key Performance Indicators (KPIs) in a modular and extensible way. The `kpi.provider` model defines a base structure for KPI reporting and includes a `get_kpis_summary` method that should be overridden in inheriting models. This method is responsible for returning a list of KPI data specific to the module. KPI data are identified by a unique name and a type allowing for the caller to know how to present the corresponding value. The `account` module inherits from `kpi.provider` to include the amount of draft `account.move` for each `move_type`. Task-id: 5062431 Forward-Port-Of: odoo/odoo#225153
The KPI summary now includes the number of documents waiting in the Inbox and clearer status information for account return types. This helps users quickly see pending document work and tax return deadlines without opening each area separately.
Original PR description
With this commit, `kpi.provider.get_kpi_summary` will show how many documents are present in the Inbox folder, as well as the status of the `account.return.types` (`late`, `longterm`, `to_do`, `to_submit` and `done`) depending on which account.return are not completed and on their due date. Task-id: 5062431 Forward-Port-Of: odoo/enterprise#93720
Enhancements to existing features
Invoice notification emails now use a cleaner, easier-to-read layout and only show invoice details when the information is available. The email also limits the number of displayed invoices and improves the action button, making messages shorter and more useful for recipients.
Original PR description
Enhances the einvoice email template for better readability and handling of missing data. - Switch table layout to a more linear view mode - Display invoice number, vendor name, date, and total only if values exist and remove values if no values are found - Use dynamic greeting to mention company name or remove placeholder if doesn't exist - Reduce maximum invoices shown to 5 to improve email length - Changed view invoices redirection button 4985307
Vendor bill uploads now warn users when the GSTIN on the bill does not match the selected company, helping prevent bills from being recorded under the wrong entity. GSTR-2B matching also handles duplicate invoice reference numbers in draft purchase documents more smoothly, reducing blocked automated processing.
Original PR description
Use Case 1 – Bill Upload/Scan - Issue: When scanning or uploading vendor bills, system allows upload even if the bill’s GSTIN does not match the company GSTIN. This can happen when multiple companies share the same name but have different GSTINs under the same PAN. - Solution: Add a warning if the bill’s GSTIN doesn’t match the company GSTIN: *"It seems Bill’s GSTIN doesn’t match this company. Please verify before proceeding.”* Use Case 2 – Duplicate IRN in GSTR-2B Matching - Issue: Cron job gets stuck when duplicate IRN exists in both draft purchase documents and fetched GSTR-2B data. - Solution: Include draft purchase documents having IRN in the matching process for the current period, so duplicate warnings are skipped and processing continues smoothly. Task ID: 4862214
Users can now rename online bank synchronization links from the form view. This helps distinguish multiple connections to the same bank, reducing confusion when managing bank feeds.
Original PR description
With some provider, you can have several links to the same bank. This can be confusing for the user. Allowing to edit the sync name from the form view can help the user sort out its links. Not a FIX, but suggestion is from opw-5004182 Forward-Port-Of: odoo/enterprise#93538
Resolved issues and error corrections
This fix prevents errors when a custom application uses a very large image as its icon. Users can continue opening and using menus normally even if saved menu data is too large for the browser's storage limit.
Original PR description
Before this commit, if a user uses a large image as an icon for a custom application, an error could be triggered due to the size limit in localStorage.
Event, session, and sponsor searches now work correctly when a website is viewed in languages other than English. This prevents translated labels from breaking search filters, helping visitors find event content regardless of their selected language.
Original PR description
**Issue:** - After https://github.com/odoo/odoo/commit/777cb220259e1c1529b960761a6f59ec6115038e we are not able to search for event/track/sponser when we have other language selected except `en_US`.…
**Issue:** - After https://github.com/odoo/odoo/commit/777cb220259e1c1529b960761a6f59ec6115038e we are not able to search for event/track/sponser when we have other language selected except `en_US`. - This is because of how `search_type` attribute is set in related templates. - currently it gets translated as according to website's language, for e.g when website's language is `Spanish (AR) / Español (AR)` 'events' get translated to 'eventos' and 'track' get translated to 'sesión' - hence the parameter for search get altered, failing the search. https://github.com/odoo/odoo/blob/ac5ea3cbd075db650c8e538d59e24657a0f04bb9/addons/website/static/src/snippets/s_searchbar/000.js#L118-L121 **Step to reproduce:** - Add another language except en_US, say ,spanish - install website_event - open events from website and switch language to spanish - search for event **Observation:** - No search result **Fix:** - set the search_type attribute correctly, i.e using `t-valuef` opw-4972519 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221877
Accounting setup now ignores localization templates from modules that are not installable. This prevents error messages when a custom or inherited localization module is present but not yet ready to be installed, making chart setup more reliable.
Original PR description
* Problem: if having a custom module that add extra tax to current localization module, ex: l10n_x inherit l10n_vn module, but the l10n_x module is not installable because it hasn't upgraded yet, the _get_chart_template_mapping include it as well, there for will log error in https://github.com/odoo/odoo/blob/18.0/addons/account/models/chart_template.py#L1219 * Solution: only get available template code for module that installable 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#225821
The payment setup now avoids enabling default payment methods that are incompatible with a provider's manual capture setting. This prevents confusing activation warnings for Stripe and helps businesses configure payments more smoothly.
Original PR description
Steps to reproduce: 1) Check the manual capture checkbox on Stripe. 2) Try to enable it. 3) See the warning that some payment methods can not be activated. Reason: Commit 25feb5b11c2df401580b65e0108145863fcf8987 disallows activating payment methods that do not support manual capture if their provider supports it. Solution: Filter out incompatible pms. opw-4860912 Forward-Port-Of: odoo/odoo#223038
This fix prevents TicketBAI submission errors when invoice or POS sequence names exceed the allowed length. Long sequence values are shortened automatically, making submissions more reliable and avoiding confusing validation messages for users.
Original PR description
Before this commit, records with sequences over 20 characters will present a cryptic error when uploaded to TicketBAI. Steps to reproduce ----- 1. Create a point of sale with a name >20 characters 2. Validate an order on the POS 3. Go to Point of Sale > Orders > Your order, click "Send to TicketBAI" 4. Invalid Operation ``` 002: Fichero no cumple el esquema XSD. Detalle del error: cvc-maxLength-valid: Value 'ThisisaveryveryveryveryverylongPOSnameTEST' with length = '42' is not facet-valid with respect to maxLength '20' for type 'TextMax20Type'. ``` Issue ----- The schema for SerieFactura specifies a TextMax20Type, but the generated sequence can be over 20 characters. Solution ----- Truncate the sequence to 20 characters. opw-4750372 Forward-Port-Of: odoo/odoo#225776 Forward-Port-Of: odoo/odoo#225436
This fix prevents users from editing journal entry numbers directly in the list view once entries are no longer drafts. It helps preserve accounting records and avoids accidental changes to posted entry identifiers.
Original PR description
**Issue** It was possible to edit the journal entry number in the list view even when the entry state was not 'draft'. **Steps to Reproduce** 1. Go to Accounting > Accounting > Journal Entries. 2. Select any journal entry. 3. Double-click on the Journal Number field and attempt to edit it. **Root Cause** The 'name' field in the list view did not have a readonly attribute, allowing inline editing regardless of the journal entry's state. Opw-5009421 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224475
This update corrects how the company context is switched in India localization test flows, preventing errors caused by a read-only company setting. It helps keep automated checks reliable for Indian accounting and sales localization without changing business functionality.
Original PR description
In this PR: - Replaced direct assignment `self.env.company = self.default_company` with proper odoo environment switching pattern to avoid AttributeError when company attribute becomes read-only after initialization.
This update fixes an internal automated test related to Odoo's email server handling. It helps keep development and release checks reliable, reducing the risk of false failures during validation.
Original PR description
Fine-tunning of e31ec012
Odoo now handles browser storage updates correctly when the same app is opened in more than one tab. This prevents cache failures and console errors, helping pages load more reliably for users working across multiple tabs.
Original PR description
Open Odoo in two tabs, in a fresh browser (or delete the IndexedDB). - Open the Contacts app in the first tab; - Open the Contactc app in the second tab; Before this commit, the second tab will not use the cache, and an error will be displayed in the console : `IndexedDB error: The requested version is less than the existing version`. This issue occurs, because the IndexedDB wrapper stores the database version, which is incremented when a new table is needed in order to execute the `onupgradeneeded` function and create the table. Now, the version is not stored anymore. When a new table is needed, the database is opened with the current version + 1. This will execute the `onupgradeneeded` function and create the table.
The website editor now shows the floating blocks snippet more accurately while users are designing pages. Background positioning is applied consistently across the snippet blocks, reducing surprises between the preview and the final page.
Original PR description
This commit fixes an issue with the `s_floating_blocks` snippet where some CSS rules were inactive due to the selector. Previously, the snippet applied a `background-position: top` property to the first block. However, this rule was ineffective because the first block does not include a `s_parallax_bg`. This commit resolves the issue by allowing all blocks to receive the `background-position` property, ensuring the behavior is fully WYSIWYG for the user. task-5068688
The checkout flow now loads delivery-related translations on the website, so customers using another language see the correct translated order button when choosing Cash on Delivery. This improves the multilingual shopping experience and avoids confusing untranslated text at payment.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Enable the Cash on Delivery payment method; 2. have a delivery method which allows cash on delivery; 3. active a second language on the website; 4. go to /shop/payment in the other language; 5. select Cash on Delivery payment. Issue ----- The "Place order" button isn't translated. Cause ----- The `delivery` module isn't listed as "front-end module" for translation purposes, making the translated term unavailable there. Solution -------- Add `delivery` as a front-end module via a `_get_translation_frontend_modules_name` override. opw-4971473
Purchase bills in foreign currencies now calculate line balances correctly when taxes are included in the price. This prevents incorrect accounting amounts that could appear as if the wrong exchange rate was used.
Original PR description
**Steps to reproduce** - Setup a foreign currency [CUR] with rate - Create a purchase order - Add [CUR] as currency - Add an order line with price included tax - Confirm and receive - Create Bill - Check generated lines values **Issue** Balance of the move lines will be off, as if it was computed using the wrong conversion rate **Investigation** It occurs because when preparing the move values, the system add the balance calculated from the product price. This does not work for price included taxes, as the balance of the invoice line need to have the tax amount deducted opw-4954649 Forward-Port-Of: odoo/odoo#224705 Forward-Port-Of: odoo/odoo#221952
Fixed an accounting issue where manually entered reverse charge tax amounts could show as positive on both balancing lines. This helps ensure tax reports and journal entries reflect the correct debit and credit direction.
Original PR description
When a tax is defined using +100, -100 as repartition lines, the tax amount retrieved from manual_tax_amounts where positive for both lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where users in website translation mode could see debug error pop-ups when translating selection field labels. The change improves reliability for website editors and translators without changing normal website behavior.
Original PR description
**PROBLEM** In debug mode, props type errors pop up when clicking on a selection field to translate it. **STEP TO REPRODUCE** 1. Create a form with a selection field in a page. 2. Ensure you're in debug mode assets. 3. Go in translate mode, and click on a string of the selection field to translate it. 4. Props type error should pop up. **CAUSE** `node` is actually of type `Object` (its the target of a jquery event), the props validations expect it to be of type `String`. opw-4896491 Forward-Port-Of: odoo/odoo#221876
Duplicating a warehouse now correctly creates a matching Point of Sale operation type for the copied warehouse. This prevents missing setup records after warehouse duplication and keeps POS inventory operations aligned with the new warehouse.
Original PR description
## Short functional explanation of the error When duplicating a warehouse, if it has an PoS operation type, this operation type will not be duplicated. On the other hand, all other operation types…
## Short functional explanation of the error When duplicating a warehouse, if it has an PoS operation type, this operation type will not be duplicated. On the other hand, all other operation types will be duplicated. ## Reproduction Steps 1. Make sure PoS and inventory are well installed. 2. Go to inventory. 3. Click on configuration, then warehouse. 4. Select a warehouse, click on action, then duplicate. 5. Click on configuration, then on Operation Types. ### Expected behavior We should be able to see 2 instances of PoS operation type: one for the original company, and one for the copy. ### Unexpected behavior There's only one instance of PoS operation type, which is related to the original company. ## Origin of the issue PoS operation type is a model inherited from stock.warehouse, and no copy method was defined. Therefore, upon duplication, the copy method of the original stock.warehouse was called, leading to issues with the field created in the inherited version. __ opw-4991271 Forward-Port-Of: odoo/odoo#223052 Forward-Port-Of: odoo/odoo#222694
The website editor preview for floating block snippets now applies background positioning consistently across all blocks. This helps users see a more accurate WYSIWYG preview while designing pages, reducing surprises after publishing.
Original PR description
This PR fixes an issue with the `s_floating_blocks` snippet where some CSS rules were inactive due to the selector. Previously, the snippet applied a `background-position: top` property to the first block. However, this rule was ineffective because the first block does not include a `s_parallax_bg`. This PR resolves the issue by allowing all blocks to receive the `background-position` property, ensuring the behavior is fully WYSIWYG for the user. task-5068688 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a new company car request through the Belgian salary configurator no longer marks the employee's current car as available. This prevents existing assigned vehicles from being incorrectly freed up before any actual replacement is planned.
Original PR description
When a new car is ordered through the belgian salary configurator, a car is created in the stage 'New Request'. At this state, nothing is planned to change the car so we don't want to set the existing employee car as available for someone else. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The New button in Bank Reconciliation now continues to work when a quick-create dialog is already open. Users can save a valid entry and immediately start the next one, while invalid entries show the appropriate validation message.
Original PR description
Issue: - In the Bank Reconciliation view, clicking the “New” button for the first time opens the quick create dialog correctly. - But if the dialog was already open, clicking “New” again did nothing. - This makes the button effectless and literal dead button. Fix: - If the current record is valid, it gets saved and a fresh dialog opens for the next transaction. - If not valid, it will notify the validation error. Impact: - Users can now click “New” repeatedly to add bank transaction records without having to close or reset the dialog manually. - This behavior is now consistent across all Kanban quick create views. TaskID-4974759
Vendor bills in Chile now use the standard invoice report unless they are the specific electronic purchase invoice type. This prevents customer and company details from appearing swapped on printed vendor bills, reducing confusion and document errors.
Original PR description
steps to reproduce: ------------------- 1. Install `l10n_cl`. 2. Create a new company and set Chile as the country. 3. Go to Accounting > Configuration > Journals. 4. Create a journal with type…
steps to reproduce: ------------------- 1. Install `l10n_cl`. 2. Create a new company and set Chile as the country. 3. Go to Accounting > Configuration > Journals. 4. Create a journal with type Purchase and enable Use Documents. 5. Go to Accounting > Vendors > Bills and create a bill. 6. Print Invoices / Invoices without payments. issue: ------ The customer and company data are swapped (interchanged), and It is wrong from vendor bills point of view. solution: --------- The l10n_cl reports layout should only be applied to: - out_invoice or out_refund - or when l10n_latam_document_type_id = (46) Electronic Purchase Invoice **Before:** <img width="762" height="425" alt="image" src="https://github.com/user-attachments/assets/e042485b-5d82-455f-9f34-03a0a9cdf5cc" /> **After:** <img width="770" height="624" alt="image" src="https://github.com/user-attachments/assets/c5d09e58-bcf0-48ab-a0ae-0e37c0473a67" /> opw-4937097 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224454
Partially paid credit notes can now be sent without triggering an error in electronic invoicing. This prevents interruptions for users issuing credit notes, particularly in Colombian localization workflows.
Original PR description
When User sends the partially paid credit note, A traceback will appear. Steps to reproduce the error: - Install ``l10n_co_dian`` module with demo data and switch to CO Company - Create a Credit note > Confirm > Register a partial payment > Send > Send Traceback: ``ValueError: The following child node is not defined in the template: CreditNote/cac:PrepaidPayment`` https://github.com/odoo/odoo/blob/7136383f47f3f86bc803efaa3837f4879b211b11/addons/account_edi_ubl_cii/tools/ubl_21_credit_note.py#L26 Here, ``cac:PrepaidPayment`` node is missing in the CreditNote. So, It will raise the above traceback when sending the credit note. sentry-6814211355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223527
Portal users who can access a shared Knowledge article no longer see controls that they are not allowed to use, such as changing other members' rights or publishing the article publicly. This prevents confusing permission errors and ensures users who leave an article are redirected cleanly if they lose access.
Original PR description
Steps to reproduce =============== As an admin ---------------- 1. Go to knowledge 2. Open any article. 3. Add a portal user as a member with write access. As a portal user -------------------- 1. Open the shared article. 2. On the top right corner, click on members button --> List of members along with their rights will be shown. The portal user can open the dropdown to alter the rights of other members. Though doing so will raise an AccessError (in the logs). After this commit, the portal user will *no* longer see the 1. Toggle to share article to the web. 2. Dropdown to modify members' rights. Task-4863456
The WhatsApp integration now uses the latest supported Meta Graph API version. This helps avoid service disruption from older API versions being phased out and reduces the need for repeated future updates.
Original PR description
As outlines in the version [changelog] v17 of the API which we are currently using will be converted to the next oldest supported version of the API as per [policy] We can migrate directly to the latest version and avoid any issue in the next few years instead of having to worry about potentially breaking changes every few months. [changelog]: https://developers.facebook.com/docs/graph-api/changelog/versions/ [policy]: https://developers.facebook.com/docs/graph-api/guides/versioning task-4971841 Forward-Port-Of: odoo/enterprise#94110 Forward-Port-Of: odoo/enterprise#93170
German tax report XML exports now keep period decimal separators, matching the latest Elster requirements. This prevents submitted VAT return amounts from being ignored because of comma-formatted values.
Original PR description
**Steps to reproduce:** 1. Install `l10n_de_reports` module. 2. Configure a company with a valid SteuerNummer. 3. Post some vendor bills with `19% I` VAT. 4. Go to *Accounting → Reporting → Tax…
**Steps to reproduce:** 1. Install `l10n_de_reports` module. 2. Configure a company with a valid SteuerNummer. 3. Post some vendor bills with `19% I` VAT. 4. Go to *Accounting → Reporting → Tax Report*. 5. Export the report to XML from gear icon. **Observed behavior:** - The generated XML contains amounts with a comma `,` as the decimal separator. - Elster ignores values with commas, so amounts are missing from the submitted VAT return. **Root cause:** - The QWeb XML export replaced the decimal point `.` with a comma `,`. - Elster launched a new tax return application (*einfachELSTERplus*), which enforces `.` as the decimal separator. **Solution:** - Stop replacing `.` with `,` when exporting values to XML. - Keep amounts as floats with period separators, while still rounding or inverting values as required for specific Kz fields. **ref:** https://www.elster.de/eportal/helpGlobal?themaGlobal=osseust_import opw-4935738 Forward-Port-Of: odoo/enterprise#94130 Forward-Port-Of: odoo/enterprise#93623
This fixes German DATEV reporting for POS sessions that include both sales and refunds with different tax rates. The correct main account is now selected so exports are completed consistently for accounting workflows.
Original PR description
In _get_datev_account, the l10n_de_datev_main_account_id is determined by identifying a singular debit or credit account used in the journal entry. If there’s no unique account, it falls back to…
In _get_datev_account, the l10n_de_datev_main_account_id is determined by identifying a singular debit or credit account used in the journal entry. If there’s no unique account, it falls back to searching for a unique non-tax line among debit or credit lines. In POS, however, there is the possibility of generating journal entries that break this flow: - In a single POS session, add product A with tax 19% and product B with tax 7%. - In the same session, refund product A. - Close the session to generate the entries. In the resulting entry, since both sale and refund are present, it is not possible to discriminate using debit and credit amounts alone, and as a result, the field l10n_de_datev_main_account_id is not populated. Since account 1411 is always the one to be used for l10n_de_datev_main_account_id in this specific case, this commit adds a final fallback filter to select the correct line and ensure the field is populated. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4915272) opw-4915272 Forward-Port-Of: odoo/enterprise#92664
Subscription payments made through the customer portal no longer trigger the same EDI-signed invoice to be generated twice when automatic invoicing is enabled. This avoids duplicate invoice documents and reduces confusion for customers and accounting teams.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Use a localization that uses EDI-signed invoices; 2. enable `sale.automatic_invoice` via `ir.config_parameter`; 3. pay for a subscription via the portal. Issue ----- Invoice is generated twice. Cause ----- Commit 7c5fd63729c1 added automatic EDI invoice signing for subscriptions paid via portal. This assumed that the `sale.automatic_invoice` parameter remained unset. If this parameter is set, the invoice is already generated when post-processing a transaction in `sale`. Solution -------- Don't send invoices whose `is_move_sent` field is set to `True`. Also, don't set `from_cron` to `True` on automatic payments, as this is only intended for moves that have `sending_data` filled by `account.move.send.batch.wizard`. opw-4648189 Forward-Port-Of: odoo/enterprise#93881
Odoo now handles missing SEPA pre-notification settings during module installation or reinstallation. This prevents an error when SEPA Direct Debit batch payments exist and keeps the setup process from being blocked.
Original PR description
**Issue** When creating a batch payment with SEPA Direct Debit as payment method, if the user uninstalls the SEPA module and then installs it again, Odoo raises a `TypeError: 'int' object is not…
**Issue**
When creating a batch payment with SEPA Direct Debit as payment method, if the user uninstalls the SEPA module and then installs it again, Odoo raises a `TypeError: 'int' object is not iterable`.
**Steps to Reproduce**
1. Create a batch payment with SEPA Direct Debit.
2. Uninstall the `account_sepa_direct_debit` module.
3. Reinstall the module.
**Root Cause**
During module (re)installation, the compute method `_compute_sdd_required_collection_date` is triggered before any SEPA mandates or their pre-notification periods exist. This makes `mandates.mapped('pre_notification_period')` return an empty list. The code then calls:
max(minimum_offset, *mandates.mapped('pre_notification_period'))
When the list is empty, this reduces to `max(minimum_offset)`, which is invalid since `max()` with a single integer argument expects an iterable and raises a `TypeError`.
**Fix**
Handle the empty case so that there is a valid fallback both during installation and when mandates have no configured pre-notification period.
Opw-5042153
Forward-Port-Of: odoo/enterprise#93598Website forms configured through Studio to send emails now refresh correctly when the target model is changed. This prevents submission errors in the logs and helps ensure customer or visitor messages are processed as expected.
Original PR description
Currently, an error occurs when submitting the 'Send Email' form. Steps to Reproduce: - Install the `website` and `web_studio` modules. - Go to `website` > `Click on Edit` > `Drag and drop form`. -…
Currently, an error occurs when submitting the 'Send Email' form. Steps to Reproduce: - Install the `website` and `web_studio` modules. - Go to `website` > `Click on Edit` > `Drag and drop form`. - click the form and in actions select the `more models`, and select `outgoing mails(mail.mail)` model and `save`. - `Submit` the form, and the error appears in the `logs`. **Error:** `KeyError: 'website_form_signature'` **Cause:** This error occurs when submitting the "Send Email" form from the website. By default, the form action is `"Send an E-mail"`, and when the user `changes` the form’s model to outgoing mails (mail.mail), which also has the action "Send an E-mail," the system checks the existing model [1] and retrieves it. Since `shouldRerender` is set to false, [2] is not executed, and as a result, the `email_to(hidden field)` is not present in the form. And the website_form_signature is added from [3], but due to the condition at [4], the code at [3] is not executed. When it is accessed at [5], KeyError is raised. **Fix:** This commit ensures that when the user changes the model, `rerenderXml` is executed so that the `hidden field` is also added. [1]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L155-L156 [2]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L174-L178 [3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252 [4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236 [5]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88 sentry-6746753251 Forward-Port-Of: odoo/enterprise#93287
Loading sample data in Appraisals no longer crashes for users who only have Appraisals administrator access. This prevents setup interruptions caused by related recruitment sample records requiring extra permissions.
Original PR description
The system will crash when user try to load sample data in appraisal. **Steps to produce:-** - Install `Appraisals` and `Recruitment` module. - Make a new user with access right of administrator to…
The system will crash when user try to load sample data in appraisal.
**Steps to produce:-**
- Install `Appraisals` and `Recruitment` module.
- Make a new user with access right of administrator to `only Appraisals`.
- Login with new user.
- `Appraisals > Load sample data`.
**Error:-**
```py
AccessError: You are not allowed to create 'Job Position' (hr.job) records.
This operation is allowed for the following groups:
- Recruitment/Officer: Manage all applicants
ParseError: while parsing /home/odoo/src/odoo/saas-18.4/addons/hr/data/scenarios/hr_scenario.xml:21, somewhere inside <record id="job_consultant" model="hr.job" forcecreate="1">
<field name="name">Consultant</field>
<field name="no_of_recruitment">5</field>
<field name="contract_type_id" ref="hr.contract_type_interim"/>
<field name="description">We are currently looking for someone like that to join our Consultant team.</field>
</record>
ValueError: ParseError('while parsing /home/odoo/src/odoo/saas-18.4/addons/hr/data/scenarios/hr_scenario.xml:21, somewhere inside\n<record id="job_consultant" model="hr.job" forcecreate="1">\n <field name="name">Consultant</field>\n <field name="no_of_recruitment">5</field>\n <field name="contract_type_id" ref="hr.contract_type_interim"/>\n <field name="description">We are currently looking for someone like that to join our Consultant team.</field>\n </record>') while evaluating
'action = model._load_demo_data()'
```
**Root Cause:-**
- When a user is granted access rights only for the Appraisal module and attempts to load sample data for it, an error occurs. This happens because the sample data at [1] includes the `creation of records` related to the `Recruitment module`. Since the user does not have the required access rights for Recruitment, the system raises a permission error.
**Solution:-**
- In this commit, we resolve the issue by using `sudo()` while loading the data.
[1]: https://github.com/odoo/odoo/blob/fabfeb55c56fbc7136bd1c3a72e9d6ee99f39714/addons/hr/data/scenarios/hr_scenario.xml#L21-L26
**sentry-6795776877**