Steps to reproduce ================== - Install sale_project,industry_fsm,web_studio - Open quotation S00023 - Click on the Tasks stat button - Open studio - Go to views - Enable the gantt view => Unable to complete the operation: duplicate key value violates unique constraint "act_window_view_unique_mode_per_action" Cause of the issue ================== The [action record] already contains the gantt view, but it is replaced inside the python [action]. In [previous] version

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

- Install sale_project,industry_fsm,web_studio
- Open quotation S00023
- Click on the Tasks stat button
- Open studio
- Go to views
- Enable the gantt view

=> Unable to complete the operation: duplicate key value violates unique constraint "act_window_view_unique_mode_per_action"

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

The [action record] already contains the gantt view, but it is replaced inside the python [action].

In [previous] version, the user was entering this condition and thus had no problem editing the views

Solution
========

Instead of replacing the entire action['views'], we can remap the view ids to the ones we want.

One side effect of this though is that the `gantt,activity,map` views will be available by default.

---

[action record]: https://github.com/odoo/enterprise/blob/1df090289f3c45c200d133734989a6d9a8073145/project_enterprise/views/project_task_views.xml#L227
[action]: https://github.com/odoo/odoo/blob/1a9302dc3a9b0d9323612c10e0f3a91300bb89fd/addons/sale_project/models/sale_order.py#L154
[previous]: https://github.com/odoo/odoo/blob/8dbcd3d955e7270fc26a6141e8fce751029e5a4b/addons/sale_project/models/sale_order.py#L133-L141

opw-3800071

Forward-Port-Of: odoo/odoo#163170

The test_sudo_commands fails when testing portal user without demo data. With this commit, a portal user is created in a setupClass. build-error: 55927 Forward-Port-Of: odoo/odoo#163332 Forward-Port-Of: odoo/odoo#163116

The test_sudo_commands fails when testing portal user without demo data. With this commit, a portal user is created in a setupClass.

build-error: 55927

Forward-Port-Of: odoo/odoo#163332
Forward-Port-Of: odoo/odoo#163116

**Steps to reproduce:** - Install Contacts, Accounting and l10n_sa_edi - Switch to a Saudi Arabian company (e.g. SA Company) - Create a contact who is not in Saudi Arabia: * Address: [Complete address in United Arab Emirates] * VAT: [any] - Create an invoice: * Customer: [The created contact] * Product: [any] - Confirm the invoice - Process by ZATCA **Issue:** The following warning is returned: "The other Buyer ID (BT-46) must present in the tax invoice and associated debi

**Steps to reproduce:**
- Install Contacts, Accounting and l10n_sa_edi
- Switch to a Saudi Arabian company (e.g. SA Company)
- Create a contact who is not in Saudi Arabia:
  * Address: [Complete address in United Arab Emirates]
  * VAT: [any]
- Create an invoice:
  * Customer: [The created contact]
  * Product: [any]
- Confirm the invoice
- Process by ZATCA

**Issue:**
The following warning is returned:
"The other Buyer ID (BT-46) must present in the tax invoice and associated debit notes and credit notes (KSA-2, position 1 and 2 = 01), where the buyer VAT registration number or buyer group VAT registration number (BT-48) is not provided."

**Cause:**
"PartyIdentification" element is not set in the electronic invoice for customer because he doesn't have "l10n_sa_additional_identification_number" field set.
This field is only available for contacts living in Saudi Arabia.
For contacts who don't live in Saudi Arabia, "PartyIdentification" should be populate with their VAT number.

opw-3845645



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

Forward-Port-Of: odoo/odoo#162809

Steps to reproduce: - Install Accounting - Go to "Settings / Users & Companies / Companies" - Create a branch company (e.g. Branch Company) for a company (e.g. YourCompany) - Switch to Branch Company - Create a fiscal position Issue: It is not possible to select the taxes from the parent company in the tax mapping. opw-3850514 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162872

Steps to reproduce:
- Install Accounting
- Go to "Settings / Users & Companies / Companies"
- Create a branch company (e.g. Branch Company) for a company (e.g. YourCompany)
- Switch to Branch Company
- Create a fiscal position

Issue:
It is not possible to select the taxes from the parent company in the tax mapping.

opw-3850514



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

Forward-Port-Of: odoo/odoo#162872

This traceback occurs when the user clicks on the employee avatar in the employee form view. <h4>To reproduce this issue:-</h4> 1) Install `Employees` 2) open any employee record 3) click on the `avatar` of `manager` or `coach` 4) A traceback occurs Error:- ``` ValueError: Invalid field 'employee_ids' on model 'hr.employee ``` When the user clicks on the `employee avatar` in the `Employee` module a traceback occurs after `[1]`. Because the `employee_ids` field is not present

This traceback occurs when the user clicks on the employee avatar in the employee form view.

<h4>To reproduce this issue:-</h4>

1) Install `Employees`
2) open any employee record
3) click on the `avatar` of `manager` or `coach`
4) A traceback occurs

Error:- 
```
ValueError: Invalid field 'employee_ids' on model 'hr.employee
```

When the user clicks on the `employee avatar` in the `Employee` module a traceback occurs after `[1]`.
Because the `employee_ids` field is not present in `hr.employee`.

which leads to the above traceback when the `read ` method `[2]` triggers
with the model as `hr.employee` and fields including `employee_ids`

[1]
https://github.com/odoo/odoo/pull/157907/commits/fdc0693968b5e50b625406a38e26817d6d9d63ea 
[2]
https://github.com/odoo/odoo/blob/503e9cbf16762cfd753c4427e13228c135db21d5/addons/resource_mail/static/src/components/avatar_card_resource/avatar_card_resource_popover.js#L32-L33

This commit will resolve this issue based on the model in `props`
 to concat `employee_id` or `employee_ids` in the fields.

Related Enterprise PR:- https://github.com/odoo/enterprise/pull/61444

sentry-3954475523

Forward-Port-Of: odoo/odoo#163305

In stock, you would print multiple times the same lot label. In this scenario, the rendering method get multiple times the same res_id as parameter. However, the code is loosing track of those duplicated ids before all streams are indexed by res_id. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163362 Forward-Port-Of: odoo/odoo#157710

In stock, you would print multiple times the same lot label. In this scenario, the rendering method get multiple times the same res_id as parameter. However, the code is loosing track of those duplicated ids before all streams are indexed by res_id.

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

Forward-Port-Of: odoo/odoo#163362
Forward-Port-Of: odoo/odoo#157710

The COA should be visible, so existing db won't crash. Indeed, it is used in the Selection field of the config settings. As the field does not exist, the users get an error. We instead don't let a user apply the Syscohada template to a company that does not already have the COA. opw-3893013 opw-3891587 opw-3891028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163350

The COA should be visible, so existing db won't crash. 
Indeed, it is used in the Selection field of the config settings. 
As the field does not exist, the users get an error. 
We instead don't let a user apply the Syscohada template to a company that does not already have the COA.

opw-3893013
opw-3891587
opw-3891028




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

Forward-Port-Of: odoo/odoo#163350

Currently, when the `invoice_date` of an invoice is updated (triggering the recomputation of `date`) and if a system flush occurs before any line's date is accessed, the invoice lines' dates do not get updated. The following test illustrates this issue: ```py move = self.init_invoice( move_type='in_invoice', partner=self.partner_a, amounts=[1000.0], ) move.invoice_date = fields.Date.from_string('2024-01-01') self.env.flush_all() for line in move.line_ids: self.ass

Currently, when the `invoice_date` of an invoice is updated (triggering the recomputation of `date`) and if a system flush occurs before any line's date is accessed, the invoice lines' dates do not get updated. The following test illustrates this issue:

```py
move = self.init_invoice(
    move_type='in_invoice',
    partner=self.partner_a,
    amounts=[1000.0],
)

move.invoice_date = fields.Date.from_string('2024-01-01')
self.env.flush_all()

for line in move.line_ids:
    self.assertEqual(line.date, move.date) # will fail
```

### Cause

The `date` of a move is a computed field dependent on the move's `invoice_date`. The `date` of a move line is a related field, pointing to its parent move's `date` (note: related fields are computed fields). During a flush, the system recomputes all fields that need to be. Here, the system first processes 'account.move.date' and calls its computation (`_compute_date`). However, the `_affect_tax_report()` call within `_compute_date` triggers a recalculation of `account.move.line.date`, but as this happens within `_compute_date`, the invoice lines' `date` is recalculated using the old invoice `date`.

### Fix

Force a recalculation of the invoice lines' dates whenever the invoice's date is changed.


opw-3759472
opw-3875405
opw-3872006
opw-3884013

Forward-Port-Of: odoo/odoo#163491
Forward-Port-Of: odoo/odoo#162956

Before, using a column group on the OSS report broke the layout, as each country line displayed more cells than it should, and they hence mismatched the column headers. This was due to bad management of the column groups: when there was more than one column group, the tax_sums variable contained more than one value, and we were then looping on each column for each tax sum to generate the columns of the country line, which was wrong, since options['columns'] already contained the columns of ea

Before, using a column group on the OSS report broke the layout, as each country line displayed more cells than it should, and they hence mismatched the column headers.

This was due to bad management of the column groups: when there was more than one column group, the tax_sums variable contained more than one value, and we were then looping on each column for each tax sum to generate the columns of the country line, which was wrong, since options['columns'] already contained the columns of each column group.

Forward-Port-Of: odoo/enterprise#61530

Some codes in UNSPSC list were reported as missing, updated missing codes and added them to our list. Task Id: 3871714 Forward-Port-Of: odoo/enterprise#61252

Some codes in UNSPSC list were reported as missing, updated missing codes and added them to our list.

Task Id: 3871714

Forward-Port-Of: odoo/enterprise#61252

To Reproduce: ============= - create a service Product with **invoicing policy** based on milestones and **create on Order** a task in fsm - create Sale order with this product and confirm it - a task is created, mark the task as done (with the button 'Mark as Done') -> the delivered quantity of the sale order line is updated to 1 Problem: ======== - marking the task as done should not update the delivered quantity of the sale order line of product based on milestones Solution: ==

To Reproduce:
=============
- create a service Product with **invoicing policy** based on milestones and **create on Order** a task in fsm

- create Sale order with this product and confirm it
- a task is created, mark the task as done (with the button 'Mark as Done') -> the delivered quantity of the sale order line is updated to 1

Problem:
========
- marking the task as done should not update the delivered quantity of the sale order line of product based on milestones

Solution:
=========
add condition to check if the product invoicing policy is based on milestones before updating the delivered quantity of the sale order line as it will be done when the milestones are reached

opw-3850167

Forward-Port-Of: odoo/enterprise#61304

When generating VAT XML by posting a tax closing entry, the `<ns2:Comment>` tag in the ML is empty despite specifying a comment during the closing process. ### Steps to reproduce 1. Install `l10n_be_reports_post_wizard`. 2. Switch to a Belgian company. 3. Open the tax report. 4. Create a tax closing. 5. Post the tax closing, ensuring a comment is defined in the appearing wizard. 6. Review the generated XML file. Expected behavior: The `<ns2:Comment>` tag in the XML should display t

When generating VAT XML by posting a tax closing entry, the `<ns2:Comment>` tag in the ML is empty despite specifying a comment during the closing process.

### Steps to reproduce

1. Install `l10n_be_reports_post_wizard`.
2. Switch to a Belgian company.
3. Open the tax report.
4. Create a tax closing.
5. Post the tax closing, ensuring a comment is defined in the appearing wizard.
6. Review the generated XML file.

Expected behavior: The `<ns2:Comment>` tag in the XML should display the comment entered during the tax closing.

Actual behavior: The `<ns2:Comment>` tag is found to be empty.

opw-3859928

Forward-Port-Of: odoo/enterprise#60917

After the changes in the related community PR, Commit [2] is no longer needed as that use case in [2] will also resolved in the community PR mentioned below Community PR:- https://github.com/odoo/odoo/pull/163305 [2] https://github.com/odoo/enterprise/pull/58964/commits/7845ff85cad0714a95866f9bfcc9d717960ecf3c sentry-3954475523 Forward-Port-Of: odoo/enterprise#61444

After the changes in the related community PR,
Commit [2] is no longer needed as that use case in [2] will also resolved
in the community PR mentioned below

Community PR:- https://github.com/odoo/odoo/pull/163305

[2]
https://github.com/odoo/enterprise/pull/58964/commits/7845ff85cad0714a95866f9bfcc9d717960ecf3c

sentry-3954475523

Forward-Port-Of: odoo/enterprise#61444

Case 1: The user can cancel the document directly from the SAT. In that case, in odoo, the user needs to "Request Cancel" first even if the SAT state becomes 'cancelled'. To improve that, this case is now managed by adding a new cancel document automatically on the invoice. Case 2: The user can request a cancellation from the SAT. Currently, the invoice is marked as "cancel" even if the SAT rejects the cancellation. In order to manage that, let's introduce a new document: 'invoice_can

Case 1:
The user can cancel the document directly from the SAT.
In that case, in odoo, the user needs to "Request Cancel" first
even if the SAT state becomes 'cancelled'.
To improve that, this case is now managed by adding a new cancel
document automatically on the invoice.

Case 2:
The user can request a cancellation from the SAT.
Currently, the invoice is marked as "cancel" even if the SAT rejects the cancellation.
In order to manage that, let's introduce a new document: 'invoice_cancel_requested'.

Forward-Port-Of: odoo/enterprise#60905