In the calendar application, when clicking on an event, a window opens. In this window, we can select “yes,” “no,” or “maybe.” When one of the buttons is selected and the mouse hovers over the button to its right, the border of the selected button disappears. This commit fixes this display issue to ensure that all four borders remain visible when hovering over the button adjacent to the selected one.

Current behavior before PR:

<img width="437" alt="420611023-a03e84be-1512-4b5a-8e3a-186058989bc2" src="https://github.com/user-attachments/assets/86c0ac93-1c1c-4127-8363-2edad1e1007a" />

<img width="439" alt="420628749-d2bf71dc-ba9a-48d6-b997-0e7f2b35b960" src="https://github.com/user-attachments/assets/01603215-957c-4e23-838e-47e03b0fa1cd" />

Desired behavior after PR is merged:

<img width="437" alt="420611053-fdba2415-bf02-4829-81a9-9210dde9dedf" src="https://github.com/user-attachments/assets/be83c1ff-436b-4a9e-80fc-6e6de584e8fd" />

<img width="435" alt="420628766-5386e3a0-42e4-47ef-a277-d5590802d780" src="https://github.com/user-attachments/assets/366c0430-9460-4622-b5b7-063f2a3003ee" />


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

Description of the issue/feature this PR addresses:

The test TestFormCreate.test_create_res_partner fails because the field 'res.partner.property_account_payable_id' cannot be found in the form view if the module account_accountant is installed in the database.

This happens because the module includes a view which inherits from "account.view_partner_property_form" and restricts a group element only to members of the
security group "account.group_account_user." Previously, the restriction was for the group "group_account_manager" but the test wasn't updated to reflect this change.

Current behavior before PR:

Before this commit, running the test in 18.0 throws an AssertionError because the field 'property_account_payable_id' can't be found in the form view.

`AssertionError: 'property_account_payable_id' was not found in the view`

Desired behavior after PR is merged:

After this commit, the right group is added to the user during the test, and the field can now be found in the res.partner.form view.


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

Typically, the field commercial_partner_id on res.partner is not displayed on the Form view. However, adding it via Studio or other means will lead to an error if the following conditions are met.

Issue
We click New to start creating a new record (still in NewId phase) We trigger an onchange that will lead to invoice_edi_format being computed When clicking New the commercial_partner_id is computed initially. However, this value isn't present on the Form view yet which leaves the field empty until we actually save (and create) the record. Prior to this, if another onchange is called we'll pass commercial_partner_id as False in the onchange, eventually erroring out when we try to call a method on the value's record.

Solution:
After multiple fixes and refactor, it looks like dependencies on the compute are no longer relevant. Indeed, `_get_suggested_invoice_edi_format` only depends on the commercial partner's country code now. Also only compute the edi format if the commercial partner is set.

opw-4630096

Currently a ParseError is arising when the user installs the `hr_referral` module after deleting all Stages in Recruitment/Configuration.

Steps to reproduce:
---
- Install `hr_recruitment` application (without demo data).
- Delete all `Stages` in Recruitment > Configuration
- Now install `hr_referral` module

Traceback:
---
```
Exception: Cannot update missing record 'hr_recruitment.stage_job3'

ParseError
while parsing /home/odoo/src/enterprise/saas-18.1/hr_referral/data/data.xml:93, somewhere inside <record model="hr.recruitment.stage" id="hr_recruitment.stage_job3">
            <field name="use_in_referral">True</field>
        </record>
```

The error occurs because the user deleted all `Stages` in Recruitment, and then tried to install the other module.

This commit solves the above issue by using `forcecreate` False to bypass record creation if it violates checks.

https://github.com/odoo/odoo/blob/f5378fadf910d193cbb44a4d1c10a5a15d8b9a51/odoo/tools/convert.py#L364

sentry-5731062091

Currently, an error occurs when using studio to add an approval step with a domain containing a function call, such as `context_today()` or `relativedelta()`.

**Steps to produce:**
- Install the `account` and `web_studio` modules.
- Navigate `Invoicing > Customers > Invoices` and open an existing invoice form.
- Activate **Studio mode** and add an approval step on any button.
- In the Code Editor, set a domain like `['&', ('invoice_date', '>=', context_today().strftime('%Y-%m-%d')), ('invoice_date', '<=', (context_today() + relativedelta(months = 1)).strftime('%Y-%m-%d'))]`
- Close Studio mode and return to the invoice form.
- Observe the error.

`ValueError - malformed node or string on line 1: <ast.Call object at 0x7e34e619fd10>`

The error occurs because the `literal_eval` function evaluates literals (e.g., strings, numbers, lists, dicts, ). Function calls like `context_today()` and `relativedelta()` are not valid literals, leading to a `ValueError`.

This commit resolves the issue by wrapping the `literal_eval()` call at [1] in a `try-except` block to catch and bypass errors when the domain contains invalid expressions.

[1] - https://github.com/odoo/enterprise/blob/7fc55313cb25c7c228735ff8323af4177fa9a531/web_studio/models/studio_approval.py#L815

Sentry-6288127324