This PR updates the share dialog message shown when a slide is shared via email. Since emails are queued and sent later in batches, the previous message could be misleading and prompt users to send multiple emails unnecessarily. Task-4797324 Forward-Port-Of: odoo/odoo#211390

This PR updates the share dialog message shown when a slide is shared via email. Since emails are queued and sent later in batches, the previous message could be misleading and prompt users to send multiple emails unnecessarily.

Task-4797324

Forward-Port-Of: odoo/odoo#211390

\*: website_mail This PR addresses several issues in the blog module, including: Commit [1]: retain follow-us input button when logged in - Steps to reproduce: 1. Go to any blog post. 2. Enable the sidebar. 3. Select any category (e.g., Travel). Issue: A subscribe button appears in the 'Follow Us' section. - Solution: Currently, the input field is only shown to public users. This happens because the input element is restricted by the `base.groups_public` group in the XML code. Si

\*: website_mail

This PR addresses several issues in the blog module, including:

Commit [1]: retain follow-us input button when logged in

- Steps to reproduce:
1. Go to any blog post.
2. Enable the sidebar.
3. Select any category (e.g., Travel).
Issue: A subscribe button appears in the 'Follow Us' section.

- Solution: Currently, the input field is only shown to public users. This happens because the input element is restricted by the `base.groups_public` group in the XML code. Since this is an XML change in v17.0 (stable version), we need to implement the fix in JS instead. After that, we will adapt the code from the master branch.


Commit [2]: remove unnecessary months from blog category

- Steps to reproduce:
1. Have a blog post in a category (e.g., Astronomy) published in Feb-2025.
2. In another category (e.g., Travel), have blog posts in both Jan-2025 and Feb-2025.
3. When selecting the Astronomy category, the sidebar `Archives` filter shows all months, even if no blog post exists in Jan 2025.

- Solution: It will now show only months that contain blog posts for the selected category. Filter out from the backend according to their publishing date.


Commit [3]: correct tag redirection to backend in blog posts

- Steps to reproduce:
1. Go to any blog post.
2. Turn on the sidebar.
3. Create a new blog post.
4. Save it. 
Issue : clicking `add some` on tags redirects to the homepage instead of the backend of that blog post.

- Solution: a wrong URL was inserted in the anchor tag. For stable, we changed it from JS, but it will be applied to XML in master.

task-4546888

Forward-Port-Of: odoo/odoo#210999
Forward-Port-Of: odoo/odoo#197172

**Current behavior before PR:** Steps to reproduce: - Create a table. - Select some cells, apply background color on them. - Try to remove format using removeFormat button. Trying to remove format from the colored cells leads to traceback `Infinite Loop in removeAllColor()`. The issue happens because after merging commit [1], when applying background-color on cells, text-color will also get applied along with background-color. When trying to remove color using removeFormat button, `ap

**Current behavior before PR:**

Steps to reproduce:

- Create a table.
- Select some cells, apply background color on them.
- Try to remove format using removeFormat button.

Trying to remove format from the colored cells leads to traceback `Infinite Loop in removeAllColor()`. The issue happens because after merging commit [1], when applying background-color on cells, text-color will also get applied along with background-color. When trying to remove color using removeFormat button, `applyTableColor` method fails to remove text-color from cells despite having color on them, leading to infinite loop error.

**Desired behavior after PR:**

Now, background-color is removed from cells without any traceback.

[1]: https://github.com/odoo/odoo/commit/616413c3272429ec48a6ac238c899b31d0751546

task-4805468



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

Forward-Port-Of: odoo/odoo#213844
Forward-Port-Of: odoo/odoo#210803

The grain secondary settlement ("Liquidación Secundaria de Granos" - LSG) is an electronic document that supports grain purchase and sale and consignment transactions between intermediaries, cooperatives, consignees, exporters, brokers and future market operators. This document is emitted by the intermediary of the operation so, in Odoo, if the user is the seller or purchaser of the operation, it will need to register that document in a sale or purchase journal accordingly. This PR aims to incl

The grain secondary settlement ("Liquidación Secundaria de Granos" - LSG) is an electronic document that supports grain purchase and sale and consignment transactions between intermediaries, cooperatives, consignees, exporters, brokers and future market operators. This document is emitted by the intermediary of the operation so, in Odoo, if the user is the seller or purchaser of the operation, it will need to register that document in a sale or purchase journal accordingly.
This PR aims to include this document in the list of the available ones to allow the user to select it when registering either a sale or a purchase. 
![image](https://github.com/user-attachments/assets/cd257bb9-8337-46c0-a699-7ed973338ac7)

**Behaviour before this PR:**
When the user creates an invoice in a sale or purchase journal, the document type "331 - SECONDARY GRAIN LIQUIDATION" is not available to select, although it is activated.

**Behaviour after this PR:**
When the user creates an invoice in a sale or purchase journal, the document type "331 -SECONDARY GRAIN LIQUIDATION" is appears in the list of documents (the document type should be activated before)

**Steps to reproduce:**

1. Install l10n_ar
2. Go to "Document Types" menu and activate "331 - SECONDARY GRAIN LIQUIDATION" 
3. Create or use a sale or purchase journal that has "Is AFIP POS?" as False.
4. Create an invoice in that journal and check that the document type with code 331 is not available to select.
 
![image](https://github.com/user-attachments/assets/710ac57c-8f2c-4398-88c7-ef8c3c8581f3)


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

Forward-Port-Of: odoo/odoo#214067
Forward-Port-Of: odoo/odoo#211737

Description of the issue/feature this PR addresses: Posting an account move will unconditionally overwrite any value in the `checked` field to the value of the `journal_id.autocheck_on_post` field. I.e. whatever the user has selected in the `checked` will be overwritten. This PR will change the functionality to work as the original comment for the feature states. Current behavior before PR: The `checked` field on an account move is always updated to the value of the `journal_id.autocheck_

Description of the issue/feature this PR addresses:
Posting an account move will unconditionally overwrite any value in the `checked` field to the value of the `journal_id.autocheck_on_post` field. I.e. whatever the user has selected in the `checked` will be overwritten. This PR will change the functionality to work as the original comment for the feature states.


Current behavior before PR:
The `checked` field on an account move is always updated to the value of the `journal_id.autocheck_on_post` field, when posting an account move.


Desired behavior after PR is merged:
The checked field on an account move is updated to the value of the  journal_id.autocheck_on_post, when posting a move, only when the journal_id.autocheck_on_post is `True`.


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

Forward-Port-Of: odoo/odoo#213370

When computing the payment state fetching the payment data from the database is only necessary for posted invoices. Previously it was fetched all the time which causes unnecessary requests to the database and can cause performance issues when a lot of non invoice entries are being processed concurrently. With inventory valuation for instance. opw-4724142 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---

When computing the payment state fetching the payment data from the database is only necessary for posted invoices.
Previously it was fetched all the time which causes unnecessary requests to the database and can cause performance issues when a lot of non invoice entries are being processed concurrently.
With inventory valuation for instance.

opw-4724142

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#209759
Forward-Port-Of: odoo/odoo#208850

At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Enterprise PR: https://github.com/odoo/enterprise/pull/87223 task-4242065 F

At the moment, the tax aggregators always give a base line with no tax the `None` grouping key.

Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one.

This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line.

Enterprise PR: https://github.com/odoo/enterprise/pull/87223

task-4242065

Forward-Port-Of: odoo/odoo#213405

This reverts the fix of commit 2597d6f4c33fe2ae8a60e11059c2630ac8aff58c and flatten the background color of the body element instead. Scenario: - set a color to the body different than white - add snippets to have a height higher than the viewport - go down in the page Result: the background color is only set up to the viewport height. Cause: Before 18.0, the body takes 100% of the page height because we are scrolling over the #wrapwrap element. In 18.0 with 189a7c96e6e26825d

This reverts the fix of commit 2597d6f4c33fe2ae8a60e11059c2630ac8aff58c
and flatten the background color of the body element instead.

Scenario:
- set a color to the body different than white
- add snippets to have a height higher than the viewport
- go down in the page

Result: the background color is only set up to the viewport height.

Cause:

Before 18.0, the body takes 100% of the page height because we are scrolling
over the #wrapwrap element.

In 18.0 with 189a7c96e6e26825dc05c0c6466576fe63aa091e, we are scrolling
over the body element, that combined with the body having a height of
100%  makes the body element being positionned from 0 to viewport height,
and it's not present below that.

Also to set background of the whole page, the browser uses the body
background if there is no background on the html element, so even if the
body didn't cover the whole page, we were getting the body color on the
whole page.

So the change in 2597d6f4c33fe2ae8a60e11059c2630ac8aff58c that set the
html element to white, causes the background color to only be applied to
up to the viewport height, with the background being blank below that.

Fix: set the body background color to the flattened rgb color.

opw-4863179
opw-4863724

Forward-Port-Of: odoo/odoo#214457
Forward-Port-Of: odoo/odoo#213858

When refunding a PoS order with mulitple lines containing a product with a category that use FIFO/AVCO valuation method, there was a traceback Steps to reproduce: ------------------- * Create a category CAT that use FIFO/AVCO valuation method * Create a product P1 with category CAT * Create a product P2 with category CAT * Create a PoS order with P1 and P2 * Validate the order using the shiplater and invoice option * Refund the order using the shiplater and invoice option > Observatio

When refunding a PoS order with mulitple lines containing a product with a category that use FIFO/AVCO valuation method, there was a traceback

Steps to reproduce:
-------------------
* Create a category CAT that use FIFO/AVCO valuation method
* Create a product P1 with category CAT
* Create a product P2 with category CAT
* Create a PoS order with P1 and P2
* Validate the order using the shiplater and invoice option
* Refund the order using the shiplater and invoice option
> Observation: You get a traceback

opw-4848667

Forward-Port-Of: odoo/odoo#213209

Description of the issue/feature this PR addresses: Currently, the l10n_ro_edi_stock_enable flag may be set for all stock pickings, including internal transfers. This leads to unnecessary EDI processing for pickings that are not relevant for EDI (e.g., internal movements within the company). Current behavior before PR: The system does not explicitly exclude pickings of type 'internal' from EDI logic. As a result, internal transfers may trigger EDI processing even though they are not int

Description of the issue/feature this PR addresses:

Currently, the l10n_ro_edi_stock_enable flag may be set for all stock pickings, including internal transfers. This leads to unnecessary EDI processing for pickings that are not relevant for EDI (e.g., internal movements within the company).

Current behavior before PR:

The system does not explicitly exclude pickings of type 'internal' from EDI logic. As a result, internal transfers may trigger EDI processing even though they are not intended for such flows.
Additionally, at line 508, the existing match-case logic processes only 'outgoing' and 'incoming' types:

 
```
match data['picking_type_id'].code:
    case 'outgoing':
        partner = data['picking_type_id'].warehouse_id.partner_id if location == 'start' else data['partner_id']
    case 'incoming':
        partner = data['picking_type_id'].warehouse_id.partner_id if location == 'end' else data['partner_id']
    case _other:
        errors.append(_("Invalid picking type %(type_code)s", type_code=_other))
        continue
```

Since 'internal' is not handled explicitly, it is treated as an invalid type, resulting in misleading error messages and unnecessary processing.

Desired behavior after PR is merged:

The PR introduces a condition to exclude pickings with picking_type_code = 'internal' from EDI processing. This prevents the l10n_ro_edi_stock_enable flag from being set for irrelevant pickings and avoids the generation of errors for valid internal movements.

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

Forward-Port-Of: odoo/odoo#213457

Write some bytes in a `field.Binary(attachment=False)` field. The ORM doesn't encode the bytes in b64, and the value is stored as a binary blob in postgres. Attempt to download the content via /web/content (actually any route that uses `http.Stream` is affected). It sometimes download something, sometimes fail with an "Incorrect padding" error. The `http.Stream` class wrongly assumes that reading a binary/image field is always going to return the value base64-encoded, thus it always attemp

Write some bytes in a `field.Binary(attachment=False)` field. The ORM doesn't encode the bytes in b64, and the value is stored as a binary blob in postgres.

Attempt to download the content via /web/content (actually any route that uses `http.Stream` is affected). It sometimes download something, sometimes fail with an "Incorrect padding" error.

The `http.Stream` class wrongly assumes that reading a binary/image field is always going to return the value base64-encoded, thus it always attemps to decode it. The `b64decode` function silently discard non-b64 characters and only complain if the final thing lacks the b64 `=` padding (to make the length a multiple of 4).

So when it downloaded something, it downloaded crap.

The thing actually is:

* Binary fields, accept raw bytes, store raw bytes in db.
* Image fields, reject raw bytes, want base64, store base64 in db.

When reading Image fields it is easy: always decode the base64.

For Binary fields it is complicated, because some crazy people encode their binary fields in base64, and expect automatic base64 decoding when read. Crazy! So *attempt* to decode the b64 and if the decoding fail just assume it was raw bytes from the beginning.

Forward-Port-Of: odoo/odoo#214412
Forward-Port-Of: odoo/odoo#213997

Before this commit, clicking on "Comment" button in portal chatter to reply to a message leads to the following crash: ``` TypeError: Cannot read properties of null (reading 'effectiveSelf') ``` This happens because it opens the composer to reply to the message. Replying to a message should normally use the composer of thread and rely on `props.messageToReplyTo` from the `useMessageToReplyTo` hook, but portal chatter instead makes a composer linked to the message. The problem is that

Before this commit, clicking on "Comment" button in portal chatter to reply to a message leads to the following crash:

```
TypeError: Cannot read properties of null (reading 'effectiveSelf')
```

This happens because it opens the composer to reply to the message. Replying to a message should normally use the composer of thread and rely on `props.messageToReplyTo` from the `useMessageToReplyTo` hook, but portal chatter instead makes a composer linked to the message.

The problem is that a message linked to a composer is actually meant to say the composer is for editing the message, and when editing the message the composer shows no avatar as this is shown by the `Message` component.

Portal chatter reply to comment should display avatar of self user, but the problem is that the component `Composer` isn't directly linked to `thread`, therefore the LOC `thread.effectiveSelf` crashes in template.

This commit fixes the issue by using the `message` linked to composer when no immediate thread is found in order to display the `effectiveSelf` avatar. A composer is necessarily linked to either a thread or composer, thus this ensures the `effectiveSelf` is defined.

Forward-Port-Of: odoo/odoo#213454
Forward-Port-Of: odoo/odoo#213268

Issue ----- When returning different products than the ones sold on the SO, the returned products have their sequence set to 10 so they all appear between the first and second sold products. Steps to reproduce ----- - Install both Sale & Stock apps - Create & confirm a sale for 2 different products - Confirm the delivery - Create & validate a return for a third product - Open the SO -> The returned product sol is second in sequence Cause ----- The return SOL are created with n

Issue
-----
When returning different products than the ones sold on the SO, the returned products have their sequence set to 10 so they all appear between the first and second sold products.

Steps to reproduce
-----
- Install both Sale & Stock apps
- Create & confirm a sale for 2 different products
- Confirm the delivery
- Create & validate a return for a third product
- Open the SO

-> The returned product sol is second in sequence

Cause
-----
The return SOL are created with no specified sequence value, so they all have the default (10).
See [review](https://github.com/odoo/odoo/pull/209091#pullrequestreview-2828126823) for details.

-----
Ticket:
opw-4564504

Forward-Port-Of: odoo/odoo#209091

When calculating line discounts, extra decimal places are being used when computing the total in intermediate steps. This discrepancy is interpreted as a small discount, that shouldn't be there. We should instead use the current currency's precision. Example: ``` qty: 1.65 unit_price: 29.9 total: 1.65 * 29.9 = 49.335, rounded to 49.34 discount = 0.005 * 100 / 49.335 = 0.010 ``` Steps: - Create an invoice with a product - Set quantity to 1.65, price to 29.9 - Confirm & get the invo

When calculating line discounts, extra decimal places are being used when computing the total in intermediate steps. This discrepancy is interpreted as a small discount, that shouldn't be there. We should instead use the current currency's precision.

Example:
```
qty: 1.65
unit_price: 29.9
total: 1.65 * 29.9 = 49.335, rounded to 49.34
discount = 0.005 * 100 / 49.335 = 0.010
```

Steps:
- Create an invoice with a product
- Set quantity to 1.65, price to 29.9
- Confirm & get the invoice PDF
- Upload the PDF in accounting app
- Check the "discount" value

Slight improvement to odoo/odoo#206107

opw-4776391

Forward-Port-Of: odoo/odoo#213594
Forward-Port-Of: odoo/odoo#211032

runbot-112917 runbot-112998 `unpin_dt` was using `now()` inside the function and `last_interest_dt` was using `now()` (-1 sec) from its default value. When there was more than one sec between the two calls due to slow CPU or slow query, the channel would be considered pinned even though it was supposted to not be. This commit ensures the same `now()` is used in both cases. The opportunity is taken to clean the method a bit: - ensure the provided ids are existing partners - inter

runbot-112917
runbot-112998

`unpin_dt` was using `now()` inside the function and `last_interest_dt` was using `now()` (-1 sec) from its default value.

When there was more than one sec between the two calls due to slow CPU or slow query, the channel would be considered pinned even though it was supposted to not be.

This commit ensures the same `now()` is used in both cases.

The opportunity is taken to clean the method a bit:

- ensure the provided ids are existing partners
- internally, use recordset of partners rather than ids
- use `self_member_id` rather than extra manual search

Forward-Port-Of: odoo/odoo#214559

This commit fixes an issue from [1] when the SOL description did not include a newline after the translated product name, which caused it to show unexpectedly. opw-4760300 --- 1. https://github.com/odoo/odoo/pull/209141 Related: - https://github.com/odoo/odoo/pull/214571 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214569

This commit fixes an issue from [1] when the SOL description did not include a newline after the translated product name, which caused it to show unexpectedly.

opw-4760300

---

1. https://github.com/odoo/odoo/pull/209141

Related:
- https://github.com/odoo/odoo/pull/214571

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

Forward-Port-Of: odoo/odoo#214569

Forward-Port-Of: odoo/odoo#206918

Forward-Port-Of: odoo/odoo#206918

The tax breakdown is required by Argentinian law to be displayed in the bottom left corner of the invoice report. This was added in [^1] and works well for the HTML view but min-width related classes don't work well with pdf rendering, so the table stretched across the entire width of the pdf. The fix is to follow the rest of the file and use a fixed col width on the table for the pdf view. task-4779975 [^1]: https://github.com/odoo/odoo/pull/201257 Forward-Port-Of: odoo/odoo#214509 Fo

The tax breakdown is required by Argentinian law to be displayed in the bottom left corner of the invoice report. This was added in [^1] and works well for the HTML view but min-width related classes don't work well with pdf rendering, so the table stretched across the entire width of the pdf.

The fix is to follow the rest of the file and use a fixed col width on the table for the pdf view.

task-4779975

[^1]: https://github.com/odoo/odoo/pull/201257

Forward-Port-Of: odoo/odoo#214509
Forward-Port-Of: odoo/odoo#214463

Forward-Port-Of: odoo/enterprise#83860

Forward-Port-Of: odoo/enterprise#83860

Steps: - Create an employee with marital status is married - Keep the spouse name empty - Try to export ird reports with a confirmed payslip Current behavior: - Error raised Expected behavior: - Should be able to export the report even spouse name is empty Forward-Port-Of: odoo/enterprise#87845 Forward-Port-Of: odoo/enterprise#86270

Steps:
- Create an employee with marital status is married
- Keep the spouse name empty
- Try to export ird reports with a confirmed payslip

Current behavior:
- Error raised

Expected behavior:
- Should be able to export the report even spouse name is empty

Forward-Port-Of: odoo/enterprise#87845
Forward-Port-Of: odoo/enterprise#86270

To reproduce: ============= - install documents_project - create project - go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload) - open the share link in a new browser window and connect as portal user - upload a document -> access error Problem: ======== while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project Solution: ======== r

To reproduce:
=============
- install documents_project
- create project
- go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload)
- open the share link in a new browser window and connect as portal user
- upload a document -> access error

Problem:
========
while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project

Solution:
========
read as `sudo`

opw-4782062

Forward-Port-Of: odoo/enterprise#87782
Forward-Port-Of: odoo/enterprise#87301

At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Community PR: https://github.com/odoo/odoo/pull/213405 task-4242065 Forward

At the moment, the tax aggregators always give a base line with no tax the `None` grouping key.

Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one.

This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line.

Community PR: https://github.com/odoo/odoo/pull/213405

task-4242065

Forward-Port-Of: odoo/enterprise#87223

Adds a test to the fix done in the commit [814b1b2](https://github.com/odoo/enterprise/commit/814b1b21f60189715c82c96397c36da706736490) opw-4836094 Forward-Port-Of: odoo/enterprise#87166

Adds a test to the fix done in the commit [814b1b2](https://github.com/odoo/enterprise/commit/814b1b21f60189715c82c96397c36da706736490)

opw-4836094

Forward-Port-Of: odoo/enterprise#87166

…id during import In the override of execute_import of account_bank_statement_import_csv.py a new account.bank.statement was always created even if the import contained statement_id. Steps to reproduce: - Export an account.bank.statement.line in bank rec with the statement_id included. - Import it back. The statement_id of the imported lines is a new one. opw-4753864 Forward-Port-Of: odoo/enterprise#87165

…id during import

In the override of execute_import of account_bank_statement_import_csv.py a new account.bank.statement was always created even if the import contained statement_id.

Steps to reproduce:

- Export an account.bank.statement.line in bank rec with the statement_id included.
- Import it back. The statement_id of the imported lines is a new one.

opw-4753864

Forward-Port-Of: odoo/enterprise#87165

In this PR, we change the paid net rule code to NET to align with other localizations. Forward-Port-Of: odoo/enterprise#87727

In this PR, we change the paid net rule code to NET to align with other localizations.

Forward-Port-Of: odoo/enterprise#87727

Before this PR: - IRN number was also copied when a record was duplicated or while creating a debit/credit note for purchase document. - This caused the same IRN to appear on multiple records. After this PR: - Now, when a record is duplicated or a debit/credit note is created, the IRN number will be empty to prevent duplication. Task Id: 4854568 Forward-Port-Of: odoo/enterprise#87468

Before this PR:
- IRN number was also copied when a record was duplicated or while creating a 
  debit/credit note for purchase document.
- This caused the same IRN to appear on multiple records.

After this PR:
- Now, when a record is duplicated or a debit/credit note is created, the IRN
  number will be empty to prevent duplication.

Task Id: 4854568

Forward-Port-Of: odoo/enterprise#87468

opw-4772870 opw-4664501 Forward-Port-Of: odoo/enterprise#87774 Forward-Port-Of: odoo/enterprise#86891

opw-4772870
opw-4664501

Forward-Port-Of: odoo/enterprise#87774
Forward-Port-Of: odoo/enterprise#86891

**Steps to reproduce:** 1. Install hr_payroll. 2. Create a salary rule (with a structure where country_id is null) and set `View on Payroll Reporting?` is checked for a custom field (x_l10n_xx_%). 3. Add the custom field to the payroll report's pivot view using Studio. **Issue:** - The pivot view fails to open, resulting in a traceback. ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillStart: "Cannot read properties of undefined (reading

**Steps to reproduce:**
1. Install hr_payroll.
2. Create a salary rule (with a structure where country_id is null) and
   set `View on Payroll Reporting?` is checked for a custom field (x_l10n_xx_%).
3. Add the custom field to the payroll report's pivot view using Studio.

**Issue:**
- The pivot view fails to open, resulting in a traceback.

```
UncaughtPromiseError > OwlError
Uncaught Promise > The following error occurred in onWillStart: "Cannot read properties of undefined (reading 'string')"
```

**Cause:**
- Custom field that not start with `l10n_<country_code>` or `x_l10n_<country_code>`
  are removed, causing undefined fields in the pivot view. https://github.com/odoo/enterprise/blob/ccb5ed4779db4bdf6944f43eb2e4a7aa978b9272/hr_payroll/static/src/js/hr_payroll_report_pivot_model.js#L13-L15

**Solution:**
- Allow to add custom fields created from salary rules  without a country code
 to be used as custom measures in the pivot view.

opw-4688376

Forward-Port-Of: odoo/enterprise#84881

Currently an error occurs when the user tries to remove the currency on any monetary field through web studio. Steps to replicate: - Open any list view with web_studio. - Drag and drop a monetary field and remove the currency field and save. Error: `TypeError: Argument must be bytes or unicode, got 'NoneType'` This error occurs because the `attrs` dictionary contains `{'name': None}`, and `etree.Element()` doesn't accept attributes with None values, causing it to raise a `TypeError`.

Currently an error occurs when the user tries to remove the currency on any monetary field through web studio.

Steps to replicate:
- Open any list view with web_studio.
- Drag and drop a monetary field and remove the currency field and save.

Error:
`TypeError: Argument must be bytes or unicode, got 'NoneType'`

This error occurs because the `attrs` dictionary contains `{'name': None}`, and `etree.Element()` doesn't accept attributes with None values, causing it to raise a `TypeError`.

This commit fixes the issue by making the field required so that user cant remove the value from currency field and hence preventing error at line [1].

[1]-https://github.com/odoo/enterprise/blob/a41cca06bc1e25614390f9207c937566557350a0/web_studio/controllers/main.py#L928

sentry-4244801243

Forward-Port-Of: odoo/enterprise#85565