Odoo Changelog — 2026-03-24

Tuesday, March 24, 2026

24 changes · saas-18.3

Bug Fixes(24)

Resolved issues and error corrections

[FIX] l10n_latam_base: changes identification type on country change

Coresaas-18.3l10n_latam_baseMEDIUM

This update corrects an issue where a partner's identification type was incorrectly set based on its country. Previously, the system didn't consistently update the ID type when a partner's country was changed. This fix ensures that a partner's ID type always matches the country they are associated with, preventing data inconsistencies.

Original PR description

**PROBLEM**
PR: https://github.com/odoo/odoo/pull/179078
Removed _onchange_country_id() which was used to set the identification type according to the country of the partner.
This PR reintroduce it, so id type and country remains consistent.

**STEP TO REPRODUCE**
1. install l10n_ar and l10n_co.
2. create a new partner.
3. set its country to Argentina, and select an argentinian id type.
4. set the country to Colombia and save. You end up with a partner from Colombia, with a id type that is used for Argentinian partners which shouldn't be possible.

opw-5801824

#latam#accounting#partner

[FIX] pos_sale: do not change pos.order status

PR #255396

Coresaas-18.3pos_saleMEDIUM

This update ensures the sale dashboard accurately displays all orders, including those fulfilled through the POS system. Previously, orders marked as 'done' in the POS were not visible in the dashboard. This fix updates the dashboard to recognize and display all order statuses, providing a more complete view of sales data.

Original PR description

Step to reproduce: - install spreadsheet_dashboard_sale and pos_sale - create a order in pos , invoice it too - open sale dashboard Observation: - the order fulfilled in pos, does not reflect in…

Step to reproduce:
- install spreadsheet_dashboard_sale and pos_sale
- create a order in pos , invoice it too
- open sale dashboard

Observation:
- the order fulfilled in pos, does not reflect in dashboard

Cause:
- sale has 4 status i.e ["draft", "sent", "sale", "cancel"]
- when pos_sale is installed, new status oders are added i.e ['paid', 'invoiced', 'done']
- sale dashboard pivot relies on sale defined status only, which so not consider orders that have status in  ['paid', 'invoiced', 'done']

Fix:
- fix the domain of pivots such that, it will now accept other orders too

**Before:**

<img width="1058" height="277" alt="image" src="https://github.com/user-attachments/assets/e58c88fa-5ad3-4194-9f9c-ddf41f2f73de" />

<img width="1116" height="190" alt="image" src="https://github.com/user-attachments/assets/259e0347-5d5b-4d5c-9aeb-74102aa4becd" />
<br/>


**After**
<br/>

<img width="1137" height="232" alt="image" src="https://github.com/user-attachments/assets/406b71a5-1dd8-4164-9d4e-4f0bca34c9e8" />

<img width="1125" height="235" alt="image" src="https://github.com/user-attachments/assets/fded3203-7d72-45ea-b5aa-142ebcd52136" />


opw-5487654

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#248142

#sales#reporting#POS

[FIX] point_of_sale: avoid validation error on non-cash pos invoices

PR #255322

Coresaas-18.3point_of_saleMEDIUM

This update resolves a validation error that occurred when creating invoices from POS orders with cash rounding enabled. Previously, non-cash payment methods triggered an error due to rounding logic being applied. Now, the system correctly avoids applying rounding rules for non-cash payments, ensuring invoices are created without errors.

Original PR description

## Issue before this commit: Creating an invoice from a POS order with **Cash Rounding enabled only for cash payment methods** raised an unexpected validation error: > *"The operation cannot be…

## Issue before this commit:

Creating an invoice from a POS order with **Cash Rounding enabled only for cash payment methods** raised an unexpected validation error:

> *"The operation cannot be completed: Missing required account on accountable line."*

This happened when the order was paid using a **non-cash payment method**, but rounding logic was still applied.

## Steps to Reproduce:

1. Install the `point_of_sale` module.
2. Go to POS Configuration → Settings:

* Enable **Cash Rounding**
* Set a **Rounding Method**
* Enable **Only on cash methods**
3. Create a product:

* Sale Price: 260
* Tax: 6%
4. Open a POS session.
5. Add the product to an order.
6. Apply a discount (e.g., 1.123).
7. Pay using a **non-cash payment method** (journal not marked as cash).
8. Enable **Invoice** and validate the order
*(or create the invoice later from the Orders menu)*

## Cause of the Issue:

While `_prepare_invoice_vals` correctly avoids setting `invoice_cash_rounding_id` for non-cash payments, `_create_invoice` still executes rounding logic whenever cash rounding is enabled on the POS configuration.

This leads to a mismatch where:

* No rounding configuration is set on the invoice
* Rounding logic still attempts to create/update rounding lines
* Required accounts (profit/loss) cannot be determined
* A validation error is raised due to missing account on the generated line

## With This Commit:

The rounding logic in `_create_invoice` is now guarded by checking the presence of `invoice_cash_rounding_id`.

This ensures rounding is only applied when properly configured and avoids unexpected validation errors for non-cash payment invoices.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10ticlUW5i5pbu_oDDPqR-jg0hVcNWf3Z/view?usp=sharing)

opw-6005320
opw-5951991
opw-6036870

Forward-Port-Of: odoo/odoo#254844

#pos#invoice#cash rounding

[FIX] l10n_fr_reports: continue with the cron if there is an error

PR #111710

Enterprisesaas-18.3l10n_fr_reports

This update prevents the entire reports cron job from stopping if an individual report export fails. Previously, a single error would halt the entire process. Now, the cron will continue to attempt exporting other reports, improving reliability and ensuring all reports are eventually generated.

Original PR description

If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents

task-5469038

Forward-Port-Of: odoo/enterprise#111602
Forward-Port-Of: odoo/enterprise#105191

#reports#cron#reliability

[FIX] l10n_account_edi_ubl_cii{,_tests}: handles recupel on negative lines

PR #255418

Coresaas-18.3account_edi_ubl_ciiMEDIUM

This update corrects a bug that prevented invoices with recupel taxes applied to negative lines from passing XML validation. The fix ensures that negative fixed taxes are correctly identified as allowances, resolving a validation issue related to PEPPOL invoice generation. This ensures accurate invoice processing and compliance.

Original PR description

**PROBLEM**
If you set a recupel tax (fixed tax affecting base) and use it on a negative line, the generate xml will not pass validation.

**STEP TO REPRODUCE**
1. Setup Peppol.
2. Create a recupel tax (fixed tax of 1€, affecting the base).
3. Create an invoice with a negative line, with a VAT and the recupel tax.
4. Send the invoice using peppol, and validate the xml.
5. Notice the xml doesn't pass validation.

**CAUSES**
1. The negative fixed tax should be an allowance, but is marked as a charge in the xml.
2. Only fixed taxes that are charges influences the line_extension_amount, but it should also be the case with negative fixed taxes.
3. Negative fixed taxes should have a ChargeAllowanceReasonCode that is in the AllowanceReasonCode list.

opw-5955289

Forward-Port-Of: odoo/odoo#255259
Forward-Port-Of: odoo/odoo#252716

#ubl#peppol#recupel#tax

[FIX] account_iso20022: fixes PstlAdr for iso20022_ch

PR #111674

Enterprisesaas-18.3account_iso20022MEDIUM

This update resolves an issue where the XML generated for Swiss payments (iso20022_ch) was using an outdated payment schema. The fix ensures the XML conforms to the required standards, improving payment processing accuracy and compliance with Swiss banking regulations. It also includes enhancements for validator schema and QR-IBAN handling.

Original PR description

**PROBLEM**
According to documentation (https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2025-en.pdf) PstlAdr must be structured.
This isn't the case when generating a xml for the payment method iso20022_ch.

**STEP TO REPRODUCE**
1. install l10n_ch and account_iso20022.
2. Create a swiss contact with a full address. And activate payment on the bank account of this contact.
3. Select the Company CH, and set a bank account in the bank journal configuration.
4. Create a vendor payment to the swiss contact.
5. Create a batch payment with it, and validate to get the xml.
6. Open the xml, and notice the PstlAdr isn't structured.

Ticket [link](https://www.odoo.com/odoo/project.task/5880247)
opw-5880247

Forward-Port-Of: odoo/enterprise#111158
Forward-Port-Of: odoo/enterprise#107025

#iso20022#swiss#payment#xml

[FIX] website_project : hide unset task data

PR #255152

Coresaas-18.3website_project

This update resolves an issue where removed fields from the website contact form were still appearing in the associated project tasks. The change ensures that unset data is no longer displayed, providing a cleaner and more consistent task view for users. This was caused by a recent update to how partner data was added to task descriptions.

Original PR description

# How to reproduce
- Add a contact form to your website
- Make it so the contact form creates a task on submit
- Remove some field from the contact form, but no the email (ex: Phone)
- Fill in the contact form; the email must be from one of the existing partners
- Submit the form and go look at the task in the project application

# The problem
The fields removed from the form are still present in the task's description (ex: partner_phone: False)

# Why
This commit (https://github.com/odoo/odoo/commit/7d0660e034f3be1b92869c266dc2cfb0bc6b6941) changed the way the partner's data was added to the description. When adding that data, it does not check if it exists before hand and instead adds a default value if not found.

opw-5920816

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#252848

#website#project#task#form

[FIX] documents_account_peppol: add documents widget to settings

PR #111738

Enterprisesaas-18.3documents_account_peppol

This update fixes an issue where configuring PEPPOL document syncing incorrectly directed users to a document form instead of the intended Kanban view. The change ensures users are presented with the correct Kanban view when setting up PEPPOL document synchronization, streamlining the configuration process. This improves usability and efficiency.

Original PR description

Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view.

Task-6040802

Forward-Port-Of: odoo/enterprise#111712
Forward-Port-Of: odoo/enterprise#111341

#peppol#documents#configuration

[FIX] currency_rate_live: BNB Currency Provider uses reversed rates

PR #111686

Enterprisesaas-18.3currency_rate_live

This update fixes an issue where currency rates for Bulgaria were incorrectly calculated after the country switched to the Euro. The system was using reversed rates from the XML data, leading to inaccurate unit conversions. This change ensures correct currency calculations for Bulgarian transactions.

Original PR description

Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database.
Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both.
task-6050519

Forward-Port-Of: odoo/enterprise#111275

#currency#exchange rate#Bulgaria#EUR

[FIX] sale_subscription: prevent access error on product views for non-sales users

PR #111669

Enterprisesaas-18.3sale_subscription

This update resolves an issue where users without sales permissions were encountering an error when viewing product information. The fix allows all users to access product subscription pricing data by bypassing access restrictions within the product view calculation. This ensures a smoother experience for all users.

Original PR description

Steps to reproduce:
- Install sale_subscription.
- Create a user with access to products but no access to Sales (e.g., base.group_user).
- Log in as that user and open the Products Kanban or Form view. Observation: An Access Error is raised preventing the user from viewing the products.

Cause:
The UI evaluates fields and view modifiers (like invisible attributes) referencing restricted data. Since product_subscription_pricing_ids is restricted to Sales groups, non-sales users trigger an Access Error when the view or the compute method attempts to read it.

Solution:
n the _compute_display_subscription_pricing method, use .sudo() when accessing product_subscription_pricing_ids.
This ensures that the display string can be computed for all users (including those without Sales access) by bypassing the access restrictions on the underlying pricing records.

opw-5934036

Forward-Port-Of: odoo/enterprise#108265

#product#subscription#access

[FIX] l10n_ar_edi: ERROR WSFEX 1812 (discounts)

PR #111465

Enterprisesaas-18.3account

This update resolves a problem where invoices with discounts and decimal values (over 2 decimals) were failing to send to ARCA. The fix uses a truncated unit price for discount calculations, ensuring accurate decimal handling and successful invoice transmission. This prevents errors related to discrepancies in decimal precision.

Original PR description

After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails.

We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts.

The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals.

Now we use the truncated unit price to compute the discount instead of the full amount with decimal  of the `line.price_unit` value.

Forward-Port-Of: odoo/enterprise#110706

#ARCA#EDI#Discounts#Invoice

[FIX] l10n_es_edi_tbai: prevent race condition on invoice cancellation

PR #255433

Coresaas-18.3l10n_es_edi_tbaiMEDIUM

This update resolves a bug where invoice cancellations triggered by TicketBAI would block Odoo, leading to data inconsistencies. The fix checks for a security hash before sending invoices to TicketBAI, preventing Odoo from attempting to reset protected invoices. This ensures invoices can be correctly managed across both systems.

Original PR description

Before this commit, if the user configured the sales journal to be locked by a hash, then a cancellation in ticketbai would 1/ send the cancel request to ticketBAI. This would be processed…

Before this commit, if the user configured the sales journal to be locked by a hash, then a cancellation in ticketbai would 1/ send the cancel request to ticketBAI. This would be processed successfully 2/ try to reset the invoice to draft inside of Odoo, then cancel it. This would fail with an error since account moves protected by a hash cannot be reset to draft.

The result is a blocked database where the invoice cannot be altered in Odoo while its status doesn't match the status in ticketBAI.

In this commit, we propose to check for the secure hash before sending the invoice over to ticketBAI. The invoice is not altered yet at that stage to account for potential ticketBAI errors in the normal flow.

While this option is not great from a usability perspective (preventing secure hashes with ticketBAI is probably best), we believe the current solution offers the best compromise in the context of a bugfix.

The issue does not seem to be reproducible outside of production as the core of the problem is a mismatch in state between ticketBAIand Odoo.

opw-5912848

Forward-Port-Of: odoo/odoo#250886

#es_edi#tbai#invoice#ticketbai

[FIX] l10n_us_hr_payroll: fix l10n_us_old_w4 string

PR #111641

Enterprisesaas-18.3l10n_us_hr_payroll

This update fixes a misinterpretation of the W4 filing date field in the US payroll module. The change clarifies that the field represents the date the W4 is submitted to the employer, not the date it's initially completed by the employee. This ensures accurate payroll processing and compliance.

Original PR description

This field is about when the W4 is filed with the employer, not when it's filled in.

opw-5096780

Forward-Port-Of: odoo/enterprise#111213

#payroll#US#W4

[FIX] purchase : fix POL Vendor Code/Name in desc

PR #255453

Coresaas-18.3purchase

This update fixes an issue where vendor codes and names weren't consistently updating in purchase order descriptions. The underlying system logic was flawed, leading to incorrect descriptions after switching between a sales order and a purchase order. The fix ensures accurate vendor information is always reflected in the PO description.

Original PR description

How to reproduce : - Create a product - Create an attribute with a value set to "free text" - Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name…

How to reproduce :
- Create a product
- Create an attribute with a value set to "free text"
- Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name
- Put Dropship as the route for the product to create a PO on a SO confirmation
- Create a SO with that product
- Confirm the SO and go to the PO
- Change the vendor in the SO

The problem :
The Vendor Code and/or Vendor Name does not change correctly in the product description

Why :
The way the description generation for a change in a purchase order line works as follows : Create a collection of default descriptions based on the product and the different vendors. If the collection contains the current description, it means the description was not changed by the user and it can be modified. This is done to prevent resetting a custom description made by an user.

This logic is pretty broken because the code that generate the description when going from a PO to a SO and the code that generate the description when changing the PO partner are different. This makes it so the current description is almost never found in the list of default descriptions.

It looks tempting to try to "resynchronize" those part of the code so the description generation is the same in both cases. This would be done by overriding the _get_product_purchase_description method in the purchase_stock module and using the product_description_variants field. Sadly, this does not work because it conflicts with the purchase_product_matrix module and its own override of that method.

The fix that I implemented checks that the Vendor Code and Name are the right one every time the description is computed following a change.

opw-5888233

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#254969
Forward-Port-Of: odoo/odoo#247330

#purchase order#vendor#description

[FIX] documents_hr_payroll: small message fix

PR #111700

Enterprisesaas-18.3documents_hr_payroll

This update corrects a small, non-critical message displayed within the documents generated for employee payroll. The fix ensures consistent and accurate reporting of payroll information. This change improves the overall quality and clarity of the documents.

Original PR description

Task#5980045

Forward-Port-Of: odoo/enterprise#109063

#payroll#documents#reporting

[FIX] sale_subscription: propagate salesperson to contacts

PR #111499

Enterprisesaas-18.3sale

This update ensures that changes to a subscription's salesperson are automatically reflected on all associated contacts. Previously, updates only applied to the main company partner, leading to inconsistencies. This change improves data accuracy and reduces the need for manual updates, streamlining the sales process.

Original PR description

Before this commit, changing the salesperson on a subscription only updated the company partner, leaving child contacts with outdated salesperson info.

After this commit, updating the subscription's salesperson also updates all child contacts of the company, ensuring consistency across the portal and reducing manual work. An unit test was added to ensure this behavior.

task-5917271

Forward-Port-Of: odoo/enterprise#108339

#sales#contacts#subscriptions

[FIX] mail,*: error when adding reaction on message

PR #255369

Coresaas-18.3maildiscuss

This update resolves an issue where users couldn't add reactions to messages using the 'mail.group' model. The fix hides the reaction button for these message types, ensuring proper functionality across all discussion channels. This improves the overall stability and usability of the Discuss feature.

Original PR description

*= im_livechat, portal, test_discuss_full **Steps to reproduce:** • Install the mail_group module • Open Discuss • Go to the History tab • Add a reaction on a message that has model `mail.group` •…

*= im_livechat, portal, test_discuss_full

**Steps to reproduce:**

• Install the mail_group module
• Open Discuss
• Go to the History tab
• Add a reaction on a message that has model `mail.group`  
• Throws an error

The error occurs because the `mail.group` model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model
does not inherit from mail.thread.
https://github.com/odoo/odoo/blob/d12c1e07727f9b04cd2be2e7dac1ec3af49cb637/addons/mail/models/mail_message.py#L579

Desired behavior after PR is merged:

This PR fixes the issue by hiding the "add reaction" button on messages with
models that don’t inherit from mail.thread, such as mail.group.

enterprise: https://github.com/odoo/enterprise/pull/111271
Task-5098050

[Reference](https://github.com/user-attachments/assets/aa2c4251-fd1f-4734-a62c-9fc80dd5f587)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#218615

#discuss#reaction#mail

[FIX] whatsapp,*: error when adding reaction on message

PR #111673

Enterprisesaas-18.3discussmail_group

This update resolves a bug preventing users from adding reactions to messages within the Discuss feature when using the mail_group module. The fix ensures that the 'add reaction' button is only displayed for messages with the correct underlying data structure, improving usability and preventing errors.

Original PR description

* = test_spreadsheet_edition

Steps to reproduce:

- Install the mail_group module
- Open Discuss
- Go to the History tab
- Add a reaction on a message that has model mail.group
- Throws an error

The error occurs because the mail.group model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model does not inherit from mail.thread.

This commit fixes the issue by hiding the "add reaction" button on messages with models that don’t inherit from mail.thread, such as `mail.group`.

community: https://github.com/odoo/odoo/pull/218615
Task-5098050

Forward-Port-Of: odoo/enterprise#111271

#discuss#mail_group#reaction

[FIX] test_discuss_full: invalidate im_status cache for operator test

PR #255471

Coresaas-18.3test_discuss_full

This update corrects a bug where presence status information wasn't updating correctly after changes to related records like holiday schedules. The fix ensures that presence status is refreshed accurately, preventing outdated information from being displayed to users. This improves the reliability of real-time presence tracking.

Original PR description

After sending a presence notification, `_send_status_updated_notification` leaves `im_status` cached on the user/guest record.
If a related model that affects `im_status` (such as `hr.leave`) is modified afterwards in the same transaction, the ORM has no declared dependency on it and will not invalidate the cache.
Subsequent reads then return the stale value.

breaking PR: https://github.com/odoo/odoo/pull/249314

runbot-242076

Forward-Port-Of: odoo/odoo#255361

#presence#status#updates

[FIX] google_calendar,mail: test utils imp

PR #254702

Coresaas-18.3google_calendarmail

This update fixes a test failure related to email notifications within the Google Calendar and Mail modules. The previous test incorrectly checked for empty timeout emails, leading to false positives. Now, tests verify that no emails are sent for specific messages, regardless of recipient information, ensuring more reliable test results.

Original PR description

No need to always check the timeout email_to always contains formatted emails.

task-5152917

Forward-Port-Of: odoo/odoo#254306
Forward-Port-Of: odoo/odoo#230766

#testing#notifications#reliability

[FIX] appointment: send booking notification regardless of sync status

PR #111174

Enterprisesaas-18.3appointment

This update ensures that all attendees of appointments – internal users and organizers – receive booking confirmations, regardless of whether their calendars are synced. Previously, notifications were limited to those directly connected via email, leading to a less comprehensive communication experience. This change improves user awareness and meeting coordination.

Original PR description

In [1] we prevented cancelation emails from being sent when the booking was synced via google or outlook calendar.

However this means even followers who would not be notified by the mail provider (not assisting to the meeting) would not be notified. As well as the organizer who is doing to booking/cancelling from the perspective of the mail provider, as the meeting is created from their account.

Instead we should keep sending the "appointment booked" template in all cases as it is only followed by internal users to whom it is always relevant.

As for cancelation templates, it should stil be sent to internal users. Partners of the meeting however need not be notified and may be unsubscribed if syncing is enabled, as cancellation typically only happens once.

task-5152917

[1]: https://github.com/odoo/enterprise/pull/60913

Forward-Port-Of: odoo/enterprise#110916
Forward-Port-Of: odoo/enterprise#96638

#notifications#booking#calendar

[FIX] account_reports: fallback to company's tax periodicity for previous_return_period date_scope

PR #111796

Enterprisesaas-18.3account_reports

This update fixes a crash that occurred when opening tax reports without a defined return type. The system now automatically uses the company's tax periodicity, ensuring reports open reliably. This improves the overall stability and usability of our tax reporting functionality.

Original PR description

When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way.

To reproduce:
- Make a Belgian company, install the CoA and localization
- Manually uninstall l10n_be_reports
- Try opening the tax report

Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities.

opw-6022150

#reporting#tax#stability

[FIX] web_studio: retain invisible attribute with excluded groups

PR #111751

Enterprisesaas-18.3web_studioMEDIUM

This update resolves an issue in Odoo's Web Studio where invisible fields would lose their visibility settings when toggling the 'Show Invisible Elements' option. The fix ensures that field visibility is correctly preserved based on user access and the 'Show Invisible Elements' setting, improving the user experience within the studio.

Original PR description

Steps to reproduce ================== - Install contacts,web_studio - Login as admin - Go to contacts - Open any record - Open studio - Click on any field - Add the "Role / Portal" group - Toggle the…

Steps to reproduce
==================

- Install contacts,web_studio
- Login as admin
- Go to contacts
- Open any record
- Open studio
- Click on any field
- Add the "Role / Portal" group
- Toggle the "Show invisible Elements" checkbox
- Click on the same field

=> The field is marked as invisible

- Add an invisible condition

=> The invisible condition is lost (but still applied on the view)

Cause of the issue
==================

In studio, when fetching the view, the invisible attribute is set to True when the user does not have access to the field (when he is not part of the groups).

The goal is to make the field invisible in studio unless the "Show invisible Elements" is toggled.

But this causes the actual value of the invisible attribute to be lost.

Note that this also applies to the column_invisible attribute.

Solution
========

If an invisible/column_invisible attribute is present on the nodes with missing access, we copy the actual value to the `actual_invisible` attribute.

We then use that value in the editor, when present.

opw-6026971

Forward-Port-Of: odoo/enterprise#111610
Forward-Port-Of: odoo/enterprise#111299

#web_studio#visibility#user experience

[FIX] documents_account_peppol: disable folder create in settings

PR #111834

Enterprisesaas-18.3documents_account_peppol

This update resolves an issue where users could inadvertently create 'Requested Documents' instead of folders when syncing Peppol documents through the accounting settings. To avoid a confusing 'My Drive' folder creation, the ability to create or edit documents in the settings has been disabled, aligning with a previous fix.

Original PR description

Before this commit a user could create or edit a folder in the accounting settings to sync peppol documents to. The issue was that this created a 'Requested Document' instead of a folder.

This commit removes the possibility to create or edit documents through the settings.

An alternative would have been to add the
contex to create a Folder instead of a Requested Document, however another problem then arises: the folder is created in My Drive, which does not make any functional sense. Therefore we are disabling creation and edit. This is the same logic applied in 8ada2a4f.

Task-6063736

Forward-Port-Of: odoo/enterprise#111761

#Peppol#Documents#Accounting