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

Changing the template of marketing card will not mark the existing card "to update", leading to wrong template used.

Steps:
- Open marketing card
- Open Employee Card
- Ensure a template is selected (Center)
- Click on Send
- Click on "Update 128 cards"
- Download a card (/cards/1/card.jpg)
    - Template is well "Center"
- Change Sub-Header value
- Click on Send
    - You can update 128 cards
    - Update them
    - Download a card (/cards/1/card.jpg)
        - Sub-Header is updated
        - Template is still "Center"
- Change the template to "Drawing"
- Click on Send

Actual result:
- You can't update cards, require_sync field is false
- Download a card (/cards/1/card.jpg)
    - Template is still "Center"
- Sending email will not update them
- https://github.com/odoo/odoo/blob/4970215142d11efedc5ddc1d82ef7d671e7f0eeb/addons/marketing_card/models/card_campaign.py##L180-L181

Expected result:
- You can update cards, require_sync field is true
- Card template should be considered as a render field

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

**Current behavior:**
For a `PurchaseOrder` record, writing on the `partner_id` and a field of an `order_line` which is computed by
`_compute_price_unit_and_date_planned_and_name` will cause the new value of the order line write to be overwritten.

E.g., writing on `partner_id` and
`purchase.order.line.price_unit`

**Expected behavior:**
The freshly written value in cache for the order line field should be protected from re-writes.

**Steps to reproduce:**
1. Create a product with a supplierinfo (vendor)

2. Create a new purchase order with the vendor as the partner and an order line for the product -> Save

3. Export the purchase order to xlsx, add the fields: `partner_id`, `order_line/external ID`, `order_line.price_unit`

4. Open the exported xlsx file and change the price unit value

5. Import the file -> see that the price unit on the order line did not update

**Cause of the issue:**
The new price unit gets updated in cache, but prior to the entire `write` sequence finishing, we will process pending recomputations where, seeing that `PurchaseOrder.partner_id` was updated, `_compute_price_unit_and_date_planned_and_name` will be called.

Even though `price_unit` is protected, if any of the other fields which are computed by this method are not, then it won't matter.

**Fix:**
A simple solution for *this specific* instance of over-using a compute method is to just not over-write `partner_id` if it's equivalent to the present value on the record.

If `partner_id` is overwritten for real it seems fine to let everything be recomputed.

opw-4574816

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

### Steps to reproduce:
- Install "l10n_mx_edi" and switch to a Mexican company
- In Accounting > Configuration > Taxes activate the tax "1.25 WH"
- Create an invoice with one line with a price of $50 and the tax "1.25 WH"
- Go to the customer of the invoice
- Sale & Purchase > Fiscal information and activate "No Tax Breakdown"
- Confirm the invoice and Send it to CFDI
- Traceback

### Cause:
This [commit](https://github.com/odoo/enterprise/pull/75381/commits/3f2e9437439fd6f987a13816473da2bd5a26953d) added a part in the code to prevent rounding error when specific discounts are applied which makes the base have a 5 as third digit.

When having a withholding tax and selecting "No Tax Breakdown" on the partner, the base amount will be decreased by the amount of the tax. If this amount has a 5 as third digit, a difference is detected here: `delta_discount = currency.round(sum(x['importe'] for x in line_values_list)) - cfdi_values['subtotal']` because:
- `x['importe']` is 49.375 which rounds up to 49.38
- `cfdi_values['subtotal']` is 49.37 because the tax was rounded up from 0.625 to 0.63 The code will then try to find lines with discounts but there are none so it raises an error at the `max()` function which is given nothing.

### Solution:
Adding `default=None` to `max()` so it doesn't crash.

But the rounding issue still needs to be fixed.
The fix is to select a line with more than 2 digits and to remove the difference with its rounded value. This ensures that the resulting value stay in the same 2-digit range, preventing error CFDI40167, and that the sum of "importe" is rounded down.

opw-4528766

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