**Current behavior:**
When creating a new helpdesk team, if you have selected Random or Balanced as an Assignment Method and delete the default user in the avatar selection box then switch to the Manual assignment method option, you will simultaneously be unable to assign a user (as the selection box disappears) and required to provide at least one user before being saving.

**Expected behavior:**
The form should not require a value for a field when the UI does not permit one to be entered.

**Steps to reproduce:**
1. In the Helpdesk app, go to configuration -> Helpdesk Teams

2. Create a new team, select either Random or Balanced as the Assignment Method, delete the default value, then switch back to Manual assignment

3. Try to save the record

**Cause of the issue:**
member_ids is a required attribute of the helpdesk.team model despite the form view hiding the selection box when the Manual assignment option is selected (implying it is not required).

**Fix:**
Create an _onchange() method which populates the member_ids field with a default value when the user switches to Manual assignment with no member_ids assigned.

opw-3672587

Forward-Port-Of: odoo/enterprise#57608
Forward-Port-Of: odoo/enterprise#55767

**Current behavior:**
Modifying an email template associated with the Appraisals app will not result in that attachment being sent when a message is composed using that the template.

**Expected behavior:**
The attachment(s) of a certain template will be sent when an email is triggered that references that template.

**Steps to reproduce:**
1. Modify an HR Appraisals email template so that it has some file attachment

2. In the Appraisals app, create a new appraisal that will use the modified email template

3. Send the email, observe in the chatter sidebar or in the list of emails in settings that the attachment linked to the relevant template was not sent

**Cause of the issue:**
The attachment_ids field of the request.appraisal model was not passed as a kwarg to the action_invite() method, which is where the email gets composed and posted.

**Fix:**
Add the missing attachment_ids argument to this method.

opw-3644820

Forward-Port-Of: odoo/enterprise#57402
Forward-Port-Of: odoo/enterprise#55977

PURPOSE
=======

The survey addon assets contain some global rules for print mode, that
are present in the global backend stack.

In Odoo 15.2, we put these rules in `survey_templates_results.scss`.
Then, in later versions of Odoo we updated it wih more 'print mode'
global rules.

As these rules are specific to the survey addon, we don't want them to
affect the (whole) Odoo backend.

HOW TO FIX
==========

It seems rules defined in `survey_templates_results.scss` are not
used in survey backend views, but specific to frontend views.

`survey_templates_results.scss` is also part of the
`survey.survey_assets` bundle. This bundle is loaded only for the
following frontend views:
- Survey: main page (take survey)
- Survey: custom 403 page
- Survey: void content
- Survey: login required
- Survey: expired
- Survey: Access Code page
- Survey: print page
- Survey: result statistics page

Among them, views that are not intended to be printed are not
negatively impacted by the css rules for print mode.

A solution would therefore be to remove
`survey_templates_results.scss` from the backend stack.

see https://github.com/odoo/odoo/commit/03641610c2b4a6b832ea87795fd21e1d7af10b59
see https://github.com/odoo/odoo/pull/135683
see https://github.com/odoo/odoo/pull/146812

task-3666858

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

Forward-Port-Of: odoo/odoo#148296

Previously, when exporting CIUS-RO XML and the supplier (company) or customer doesn't have a country code prefix on either their VAT or company ID, an error will be thrown preventing the user from generating the XML. But after allowing the XML generating process, the XML is then rejected by the validator because of `BR-CO-09` rule:

```xml
<assert id="BR-CO-09" flag="fatal" test="( contains( ' 1A AD AE AF AG AI AL AM AO AQ AR AS AT AU AW AX AZ BA BB BD BE BF BG BH BI BJ BL BM BN BO BQ BR BS BT BV BW BY BZ CA CC CD CF CG CH CI CK CL CM CN CO CR CU CV CW CX CY CZ DE DJ DK DM DO DZ EC EE EG EH EL ER ES ET FI FJ FK FM FO FR GA GB GD GE GF GG GH GI GL GM GN GP GQ GR GS GT GU GW GY HK HM HN HR HT HU ID IE IL IM IN IO IQ IR IS IT JE JM JO JP KE KG KH KI KM KN KP KR KW KY KZ LA LB LC LI LK LR LS LT LU LV LY MA MC MD ME MF MG MH MK ML MM MN MO MP MQ MR MS MT MU MV MW MX MY MZ NA NC NE NF NG NI NL NO NP NR NU NZ OM PA PE PF PG PH PK PL PM PN PR PS PT PW PY QA RE RO RS RU RW SA SB SC SD SE SG SH SI SJ SK SL SM SN SO SR SS ST SV SX SY SZ TC TD TF TG TH TJ TK TL TM TN TO TR TT TV TW TZ UA UG UM US UY UZ VA VC VE VG VI VN VU WF WS XI YE YT ZA ZM ZW ',substring(cbc:CompanyID,1,2) ) )">[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’.</assert>
```

In Romania however, there are multiple types of "Tax IDs", and it is perfectly valid in Romania to have a Tax ID without RO (country code prefix) in front of them. They are not a subject to paying VAT, and it should still be possible to generate CIUS-RO XML with their tax identifications.

This commit aims to fix this behavior by applying some special treatment to Romanian partners when generating the XML: by modiying the TaxScheme ID. The error only raises when the detected ID is 'VAT'.

This commit also fixes and clean some of the irrelevant constraints and tests previously written in `l10n_ro_edi`.

task-id: 3649426

Since Odoo v16, we also use grid in the form layout (inner group).
In a group we use the CSS `grid-template-columns` with the value of:
* `fit-content(150px)`: for the first column (TLDR: col max 150px)
* `1fr`: for the second column (TLDR: take the "remaining" max space)
```css
.o_form_view .o_inner_group {
  grid-template-columns: fit-content(150px) 1fr;
}
```
These rules at the first glance seem correct.
But due to "big word"/language, some unbreakable text is overflowing, to avoid this, we have added the `text-break` BS class.

So now all text can be "squash"/wrap if there is no space available.

The problem is when we have a text be too long and unbreakable in the second column, the label (first column) is squashed to see only one or two characters.

In our case, the bug happens when we upload a file with a big filename to an "Attachement" (`many2many_binary`) field.

On the `many2many_binary` field there is a custom CSS rules:
```css
.o_attachment .caption {
  white-space: nowrap;
}
```
that force the text to not wrap on the next line, and so the grid takes the width of the file name as its min value for the width of the second column, and "squash"/wrap the first column.

This commit fixes the issue by allowing the second column to be smaller than the `max-content` width using the css `minmax(0, 1fr)`.

Steps to reproduce:
* Open "Marketing automation" app
* Create a New campaign ("New" button)
* Click on "ADD NEW ACTIVITY"
* Select the "Mail Template" field
* Create and edit a "Mail Template"
* Click on the "Options" tab
* Upload an attachment with a long name => BUG, all labels (first column) are "squashed"

Note:
* the `text-break` class is equivalent to:
```css
.text-break {
  word-wrap: break-word !important;
  word-break: break-word !important;
}
```
* when we use `Xfr` (X a positive numeric value `1fr` in our case) outside a `minmax()` notation, the GRID specs[1] specifies that it should be converted to `minmax(auto, Xfr)`.
* also the `auto`[2] in the case of `minmax(auto, Xfr)`the value represents the largest minimum size (in our case, the file name).

[1]: https://www.w3.org/TR/css-grid-2/#valdef-grid-template-columns-flex
[2]: https://www.w3.org/TR/css-grid-2/#valdef-grid-template-columns-auto

task-3644267

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

Forward-Port-Of: odoo/odoo#155420

How to reproduce:
- Install hr with demo data
- Create a user without access to hr and turn it into an employee
- Create a user for Abigail
- Assign Abigail as manager of the new user
- Click on "onboarding plan" in the chatter of the new user
- Then in the dialog, click on "Schedule" button

You get the error "Assigned user test has no access to the document and is not able to handle this activity." because the new user has no access to the record employee on which those activities are scheduled.

As activities for which the user has no access to the underlying record are now displayed in the systray (with no access to the record), we remove the check that prevent assigning an activity to a user on a record he has no access to.

Technical note: before odoo/odoo#149965, activities scheduled manually were created with the flag "automated" set to True and when this flag is set the check that ensures that the user has access to the record is skipped. With odoo/odoo#149965, as the "automated" flag is set to False when scheduling activities manually, an error is trigerred if the user has no access to the underlying record. Here we always skip that test and mark the method as deprecated because the user can see the activity no matter the access he has on the underlying record.

Task-3598836

Before this commit, in a kanban view grouped by a date(time) field, with progressbars and an aggregate field, after clicking on a bar to filter records, the aggregate value was always 0.

This was due to a mismatch when trying to find the value of the aggregate in the web_read_group result, as when grouped by a date or datetime field, the key is `fieldname:granularity`, and we were looking for the fieldname only.

This commit fixes the issue. It also fixes the mocked version of read_progress_bar in the MockServer, s.t. we can correctly reproduce the scenario in tests, as in the previous version, keys in the returned object weren't computed the same way as in the real read_progress_bar (e.g., "14,Mitchel", instead of "Mitchel"). A similar fix has been done in [1]. This allows us to introduce a test when grouped by many2one, which doesn't work as of 17.0.

[1] fd759f18d056844c486a68d0c394df5a03e789f0

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#155524