The point of sale product list now shows warning indicators only when a product actually has a relevant warning. This prevents staff from seeing misleading red information tags on product cards, reducing confusion during sales.

The condition that dictates whether or not the product warning is shown in the product list in pos is inverted. This means that we currently show the product warning when it's not the case.

Steps to reproduce:
1. On a db without self order installed, open a pos;
2. Observe that the "info" tags on the corners of the product cards are red;

Task: 4214248




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

Paid order lists in Point of Sale now sort correctly when the system uses a non-English locale, such as Arabic. This prevents staff from seeing paid orders in the wrong order and makes order lookup more reliable across international deployments.

In systems with a non-English locale (e.g., "ar-001"), the `date_order` field could not be parsed correctly, leading to improper sorting of paid orders.

opw-4181429

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

Mobile chat controls have been adjusted so the close conversation and start call buttons are larger and easier to distinguish. This reduces the chance that users accidentally start a call when they only intend to close a conversation, avoiding disruption for participants.

Button to close conversation and start a call are too small and close to each other. This means attempt to close the conversation can lead to accidentally starting a call, which scare all members of the conversation.

This commit increases the size of these buttons and show borders so that it is less likely to click on start a call when the intent is to close the conversation.

Before / After
<img width="365" alt="Screenshot 2024-09-29 at 22 22 17" src="https://github.com/user-attachments/assets/7781eb6f-20e4-4ef2-ac0a-be50b39869ee">
<img width="366" alt="Screenshot 2024-09-29 at 22 21 56" src="https://github.com/user-attachments/assets/eede8d9c-891a-4cda-8dca-853b155ed6c3">

This fixes an issue where frozen spreadsheet files could still contain Odoo-specific pivot information. Removing that data makes frozen spreadsheets cleaner and more reliable when shared or reused outside their live Odoo context.

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

The Point of Sale payment screen no longer adds an extra zero-value payment line when only one payment method is available and a payment line already exists. This avoids confusing duplicate payment entries and helps cashiers complete checkout more cleanly.

Before this commit, when only one payment method was available, an additional payment line with a value of zero would be automatically added, even if a payment line already existed.

opw-4186191

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

The Planning app now correctly shows an empty row for a resource when users view a period with no scheduled work, such as the next week. This helps planners see available resources instead of mistakenly thinking they are missing from the schedule.

Steps to Reproduce:

- Open the planning app.
- Create a planning for a resource.
- Make sure resource doesn't have any past or future plannings.
- Change the time frame to next week.

Issue:

- We don't see an empty line.

Reason:

In the PR https://github.com/odoo/enterprise/pull/55618. All the gantt time ranges have domain strictly comparative operators(> and <).  But in group_expand_resource_ids we use non strict comparative operators(>= and <=).

Fix:

- Added strictly comparative operators into operators being checked.

task-4188936

This fixes a display issue where menu items in the Studio navigation bar could become difficult or impossible to see when dark mode was enabled. The update restores clear visibility and improves hover styling, making Studio easier to use for users who work in dark mode.

The PR https://github.com/odoo/enterprise/pull/66908 has introduced some problems in the way the studio navbar is styled in dark mode: mainly its menu items are not visible.
Here we adapt some variables to have them visible again and have a suitable style on on hover.

Steps: --------- - Install the Point of Sale module with demo data. - Set up online payment provider (e.g. Razorpay) for the Indian company. - Enable online payment method in Point of sale app configuration - Add the payment method in Point of sale shop configuration. - Make a successful online payment in the Point of sale app. Issue: --------- - Error occurs after successful payment, preventing the payment from being processed and confirmed in POS module and the payment entry from

Steps:
---------
- Install the Point of Sale module with demo data.
- Set up online payment provider (e.g. Razorpay) for the Indian company.
- Enable online payment method in Point of sale app configuration
- Add the payment method in Point of sale shop configuration.
- Make a successful online payment in the Point of sale app.

Issue:
---------
- Error occurs after successful payment, preventing the payment from being
  processed and confirmed in POS module and the payment entry from being posted.

Cause:
---------
- Payment transactions status were failing due to company mismatch between the
  partner(admin)'s company and the pos order's company.

FIX:
---------
- If customer is not selected in pos order, we consider the order and payment
  from public user not from the admin user.

Improvement:
---------
- env is not accessible with self in controller for self.env.ref('base.public_user')
  fixed with request.env.ref('base.public_user')
- Unused code removed from `_get_partner_sudo` method

task-3989409

Forward-Port-Of: odoo/odoo#173268

Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.4.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182059

Update the OWL lib.

Release notes:
https://github.com/odoo/owl/releases/tag/v2.4.0

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

Forward-Port-Of: odoo/odoo#182059

Before: All event from last year to the next 2 years were fetched. This might cause timeout depending on the amount of events. After this commit: Reuse the system parameter to allow limiting to a set value Note: This does not need to be done on google as the fetch limit is already present, see: https://github.com/odoo/odoo/pull/66250/files#diff-f1bbd37c3355f798d3f2d89ccc00c778aa4faa4c6709b6d66cc9650ad0d553b6 opw-4077113 Forward-Port-Of: odoo/odoo#181613

Before:
All event from last year to the next 2 years were fetched. This might cause timeout depending on the amount of events.

After this commit:
Reuse the system parameter to allow limiting to a set value

Note: This does not need to be done on google as the fetch limit is already present, see:
https://github.com/odoo/odoo/pull/66250/files#diff-f1bbd37c3355f798d3f2d89ccc00c778aa4faa4c6709b6d66cc9650ad0d553b6

opw-4077113

Forward-Port-Of: odoo/odoo#181613

### Steps to reproduce: - Create a project - Create a task in this project and add a subtask for this task - Navigate to the kanban view for projects - Notice that the count of tasks shows 2 but you will just see only one task when clicking on this project ### Current behavior before PR: This is happening because when calculating the count of tasks we are just considering the tasks that has that project_id without checking anything else. https://github.com/odoo/odoo/blob/17.0/addo

### Steps to reproduce:
	- Create a project
	- Create a task in this project and add a subtask for this task
	- Navigate to the kanban view for projects
	- Notice that the count of tasks shows 2 but you will just see only one task when clicking on this project

### Current behavior before PR:
This is happening because when calculating the count of tasks we are just considering the tasks that has that project_id without checking anything else.

https://github.com/odoo/odoo/blob/17.0/addons/project/models/project_project.py#L56:L62

But when showing the tasks we are just showing the main tasks not the sub-tasks.

### Desired behavior after PR is merged:
We are now checking if this task should be displayed or not and if it won't be displayed we don't count it.

This is a backport of [commit](https://github.com/odoo/odoo/pull/160476/commits/1fc1f6f54ebadcda1ef090e1f73a05be85373c03)

opw-4201309

Forward-Port-Of: odoo/odoo#181410

Since https://github.com/odoo/odoo/pull/121963, there are tooltips on search panel items when the user hovers them. However, it is not very convenient since the user needs to hover precisely the span which contains the item name for the tooltip to pop up. This commit simply moves up the data-tooltip attribute in the elements hierarchy so that it will show for the whole button instead of only the title. This also fixes a bug with the tooltip position in the charts of account search panel as a sid

Since https://github.com/odoo/odoo/pull/121963, there are tooltips on search panel items when the user hovers them. However, it is not very convenient since the user needs to hover precisely the span which contains the item name for the tooltip to pop up. This commit simply moves up the data-tooltip attribute in the elements hierarchy so that it will show for the whole button instead of only the title. This also fixes a bug with the tooltip position in the charts of account search panel as a side effect.

task-3917084

Forward-Port-Of: odoo/odoo#181721
Forward-Port-Of: odoo/odoo#180776

This commit removes unnecessary whitespace in the localization files. No functional changes have been introduced, only whitespace adjustments. #169577 Forward-Port-Of: odoo/odoo#181767 Forward-Port-Of: odoo/odoo#179975

This commit removes unnecessary whitespace in the localization files.

No functional changes have been introduced, only whitespace adjustments.

#169577

Forward-Port-Of: odoo/odoo#181767
Forward-Port-Of: odoo/odoo#179975

Steps: - Install `web_studio` - Open studio - Go to Reports - Create or edit an existing report - Add some text and try to change its size - Preview will display the right size but printed pdf ignores it `wkhtmltopdf` uses an old version of Webkit which doesn't support CSS3. Since 17.0 we use the new html_editor in our report editor but it uses `display-x-fs` (x is an int from 1 to 4). ```css .display-2-fs { font-size: calc(1.575rem + 3.9vw); }

Steps:
    - Install `web_studio`
    - Open studio
    - Go to Reports
    - Create or edit an existing report
    - Add some text and try to change its size
    - Preview will display the right size but printed
        pdf ignores it

`wkhtmltopdf` uses an old version of Webkit which doesn't support CSS3. Since 17.0 we use the new html_editor in our report editor but it uses `display-x-fs` (x is an int from 1 to 4).

```css
.display-2-fs {
  font-size: calc(1.575rem + 3.9vw);
}
```

The problem with this class is the 'calc', which is not supported by the old Webkit version.

see https://github.com/odoo/odoo/issues/136360
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/4092

One solution would be to use the old (hardcoded) bootstrap 4 values in the reports.

opw-3894005

Forward-Port-Of: odoo/odoo#181756

The task description of a task generated after receiving an email from an email alias should be the body of the email (from the message thread). We differentiate this case from the case where the task is generated in another way (e.g. manually or triggered by another module), in which we should not populate the task description. related-https://github.com/odoo/odoo/pull/108360 task-4207145 version-16.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/subm

The task description of a task generated after receiving an email from an email alias should be the body of the email (from the message thread). We differentiate this case from the case where the task is generated in another way (e.g. manually or triggered by another module), in which we should not populate the task description.

related-https://github.com/odoo/odoo/pull/108360

task-4207145
version-16.0

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

Forward-Port-Of: odoo/odoo#181806
Forward-Port-Of: odoo/odoo#181572

Steps to reproduce: 1. In the Chilean localization, create a new invoice with a discount. 2. Confirm and send. The behavior: The Discount Amount is displayed under the Discount Percentage, and vice versa. Why this was the case: The Discount table header was placed after the Price Unit header (`th_priceunit`), and its data was displayed after the Discount Percentage (`th_discount`). OPW-4112378 Forward-Port-Of: odoo/odoo#179127

Steps to reproduce:
1. In the Chilean localization, create a new invoice with a discount.
2. Confirm and send.

The behavior:
The Discount Amount is displayed under the Discount Percentage, and vice versa.

Why this was the case:
The Discount table header was placed after the Price Unit header (`th_priceunit`), and its data was displayed after the Discount Percentage (`th_discount`).

OPW-4112378

Forward-Port-Of: odoo/odoo#179127

Prevent tip product from being taxed rb error: 76973, 76972, 77055, 77054 Forward-Port-Of: odoo/odoo#181771

Prevent tip product from being taxed

rb error: 76973, 76972, 77055, 77054

Forward-Port-Of: odoo/odoo#181771

While the requirements contain `geoip2`, it's used as an optional dependency e.g. `http.py` imports it conditionally and as long as `request.geoip` is not accessed it causes no trouble. However `website` does exactly this right in the `_frontend_pre_dispatch`, it's technically conditional but the conditions are: - a frontend page (not an explicit route and not an attachment) - no tz in the context (which is very likely for new frontend session) Forward-Port-Of: odoo/odoo#176617

While the requirements contain `geoip2`, it's used as an optional dependency e.g. `http.py` imports it conditionally and as long as `request.geoip` is not accessed it causes no trouble.

However `website` does exactly this right in the `_frontend_pre_dispatch`, it's technically conditional but the conditions are:

- a frontend page (not an explicit route and not an attachment)
- no tz in the context (which is very likely for new frontend session)

Forward-Port-Of: odoo/odoo#176617

# Context: The `create` method in the `mail.alias.domain` model currently tries to make the created alias domain record the default for all companies and `mail.alias` records if it's the first of it's kind to be created. But in it's current form it fails to accound for grandfathered databases (pre 17.0) or miss confgurations by a user, where we have archived companies attached to `mail.alias` where the `alias_domain_id` field is False. In such a edge case, it is impossible to create a a

# Context:

The `create` method in the `mail.alias.domain` model currently tries to make the created alias domain record the default for all companies and `mail.alias` records if it's the first of it's kind to be created.

But in it's current form it fails to accound for grandfathered databases (pre 17.0) or miss confgurations by a user, where we have archived companies attached to `mail.alias` where the `alias_domain_id` field is False.

In such a edge case, it is impossible to create a alias domain record, because during the save (create), the user is faced with a Validation Error produce by the checks in the `_check_alias_domain_id_mc` in the `mail.alias` model.

Example error message:
```
"We could not create alias archived-company-alias@example.com because
domain example.com belongs to company ActiveCompany while the owner
document belongs to company ArchivedCompany."
```

It follow that the user is blocked from setting up an alias domain unless they temporarily unarchive a company.

# Proposed solution:

Assuming that the objective is to initialize all current mail aliases in the DB with the "first" alias domain record to be created, we should force the `company_ids` field in the just created `mail_alias_domain` record to contain ALL companies (active or not).

# Reproduction steps:

One way to reproduce the issue on a fresh DB is:
- install mail
- define a domain alias in the general settings
- create a second company
- install Accounting
- make sure a localization pack is loaded for each company (the idea is to create default sale and purchase accounting journals with their email alias)
- archive second company
- in Technical > Aliases menu, clear alias domain from aliases (set `alias_domain_id` = False)
- delete alias domain
- create a new alias domain

--> Validation Error

OPW-3955936

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

Forward-Port-Of: odoo/odoo#169613

Steps to reproduce: - (16.0 only) Project > Configuration > Settings > Enable 'Sub-tasks' - Project > New > Add 2 Stages and a Task - Click the task > Sub-tasks tab > Create a subtask - Go back to the project's task view - Delete the 2nd stage The sub-tasks are now visbile when they should not be. This is because we reload the view after stage deletion, with an action that does not contain display_project_id (16.0) / display_in_project (>= 17.0) in its domain. opw-4191732 --- I co

Steps to reproduce:
- (16.0 only) Project > Configuration > Settings > Enable 'Sub-tasks'
- Project > New > Add 2 Stages and a Task
- Click the task > Sub-tasks tab > Create a subtask
- Go back to the project's task view
- Delete the 2nd stage

The sub-tasks are now visbile when they should not be. This is because we reload the view after stage deletion, with an action that does not contain display_project_id (16.0) / display_in_project (>= 17.0) in its domain.

opw-4191732

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

Forward-Port-Of: odoo/odoo#181789
Forward-Port-Of: odoo/odoo#180753

# Context: A pesky bug has been flying under the radar since at least Odoo 15.0. When passing `email_from=False` to the _find_mail_server, we will always have an early return at: https://github.com/odoo/odoo/blob/f05626e14264cf3bb477c86ad82439726d778c8f/odoo/addons/base/models/ir_mail_server.py#L668C1-L676C1 This comes from the fact that we can generate False == False => True comparisons while filtering the `ir.mail.server` records, by : * `email_from_normalize` is False (since `email_f

# Context:
A pesky bug has been flying under the radar since at least Odoo 15.0. When passing `email_from=False` to the _find_mail_server, we will always have an early return at: 
https://github.com/odoo/odoo/blob/f05626e14264cf3bb477c86ad82439726d778c8f/odoo/addons/base/models/ir_mail_server.py#L668C1-L676C1


This comes from the fact that we can generate False == False => True comparisons while filtering the `ir.mail.server` records, by :
* `email_from_normalize` is False (since `email_from` was also False) and mail server has no from_filter = > email_normalize(m.from_filter) == email_from_normalized => False == False
* `email_from_domain` is False (since `email_from` was also False)  and mail server has a full email address in the from_filter field => email_domain_normalize(m.from_filter) == email_from_domain => False == False

Both edge-cases leads to the first email server config to always be selected for the SMTP connection, even if a valid mail server exist matching for example the default notification email (i.e. notifications@custom.domain).

This can lead to notification emails failing on DB having multiple outgoing email servers setup, where the SMTP server does sender verification (Outlook, Gmail – you can only send as a specific sender email).
Should impact Odoo versions 15 and later.

# Proposed fix:
We wrap the first checkpoint in an if block with email_from. Logically if email_from is already False, we should skip to the second checkpoint (matching notifications default email) and only later try to fall back to the first `ir.mail.server`  record (while also triggering the warning log).

# How to reproduce:
Any workflow triggering an automatic notification email as Odoobot, while having the `email` field set to `False`.

1) Setup DB with website_sale installed
2) Set `email` field of Odoobot `res.partner` (by default id = 2) to False 
3) Setup at least two outgoing email servers (`ir.mail.server`) with the first having no `from_filter` and the second one matching the default notifications email address (default = notifications@mycompany.example.com) 
4) So to the Ecommerce shop and buy any random product and finalizing the transaction. → Triggered notification email will always be sent by mail server id = 1, even if it should match id = 2 in this case

OPW-4140192


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

Forward-Port-Of: odoo/odoo#181872
Forward-Port-Of: odoo/odoo#178340

Steps to reproduce: - Have two Companies A and B - Create an Analytic Account (AA) for Company A - In B (A multiselected), create an invoice: company=Company B Set the AA analytic Distribution - Unselect company A and try to enter the invoice Issue: Access error Solution: After discussion with PO tsb, children companies need to have access to analytic account (and analytic related stuff) from parent opw-3764627 Forward-Port-Of: odoo/odoo#179282

Steps to reproduce:
- Have two Companies A and B
- Create an Analytic Account (AA) for Company A
- In B (A multiselected), create an invoice: company=Company B Set the AA analytic Distribution
- Unselect company A and try to enter the invoice

Issue:
Access error

Solution:
After discussion with PO tsb, children companies need to have access to analytic account (and analytic related stuff) from parent

opw-3764627

Forward-Port-Of: odoo/odoo#179282

Currently the EC Sales List menuitem is not visible when only installing `l10n_fr_reports` (and no other localization activating the item). To reproduce it you need to install `l10n_fr_reports` on a database where the item is not already visible. (It does not work on the runbot.) Forward-Port-Of: odoo/enterprise#71021 Forward-Port-Of: odoo/enterprise#70723

Currently the EC Sales List menuitem is not visible when only installing `l10n_fr_reports` (and no other localization activating the item).

To reproduce it you need to install `l10n_fr_reports` on a database where the item is not already visible. (It does not work on the runbot.)

Forward-Port-Of: odoo/enterprise#71021
Forward-Port-Of: odoo/enterprise#70723

When a visitor clicks on a view link, they are redirected to the login page to authenticate and gain access to the view. This is necessary to ensure the user has the appropriate permissions to open the view and access the records. Current problem: When clicking on a view link, the users are redirected to an error page after successfully logging in. This happens because the system generates a faulty redirection URL (`/knowledge/article/undefined`) for the login page. This occurs because the

When a visitor clicks on a view link, they are redirected to the login page to authenticate and gain access to the view. This is necessary to ensure the user has the appropriate permissions to open the view and access the records.

Current problem:

When clicking on a view link, the users are redirected to an error page after successfully logging in. This happens because the system generates a faulty redirection URL (`/knowledge/article/undefined`) for the login page. This occurs because the `KnowledgeWidget` widget generates the URL using `this.resId` (`/knowledge/article/{this.resId}`) and the widget does not have any `resId` property set.

Steps to reproduce:
1. Open any list or kanban view
2. In the view's cog menu: "Knowledge" > "Insert link in article"
3. Click the "New" button to create a new article
4. After being redirected to the article, click on the "Share" button
5. Publish the article
6. Copy the generated article URL
7. Open a private window and paste the URL
8. Click the view link
9. Enter valid credentials

=> After logging in, the user is redirected to an error page.

TO BE: After logging in, the user should be redirected to the backend view of the article. The user should then be able to open the view by clicking on the view link.

Solution:

To solve this issue, we will use `this.$id` instead of `this.resId` to get the current article id.

Reference: https://github.com/odoo/enterprise/pull/57346

task-4210743

Forward-Port-Of: odoo/enterprise#70651

Steps to reproduce: - Sign > Edit any template > Add a field - Click your field > Select left alignment > Validate The placeholder text overlaps with the arrow block, in 16.0 this does not occur. The culprit is the ps-0 class added to signItem which removes all padding from the block. The formatting was changed in f1b35ae9030ff82afc498bfbd6315414407bb4e1 to make it consistent between the other views (The shift is kept even the move icon is not visible) but the alignment feels consistent

Steps to reproduce:
- Sign > Edit any template > Add a field
- Click your field > Select left alignment > Validate

The placeholder text overlaps with the arrow block, in 16.0 this does not occur. The culprit is the ps-0 class added to signItem which removes all padding from the block.

The formatting was changed in f1b35ae9030ff82afc498bfbd6315414407bb4e1 to make it consistent between the other views (The shift is kept even the move icon is not visible) but the alignment feels consistent even without this class.

opw-4159676

Forward-Port-Of: odoo/enterprise#70307

Steps to reproduce: - Intall Payroll and Switzerland localization > Switch to CH company - Employees > New > Work Information tab > Set any Canton - Create a contract for that employee > Set it to 'Running' state - Payroll > Work Entries > Work Entries > Remove filters - Navigate to next month > Regenerate Work Entries - Generate Payslips > Error is raised This error is raised because the fallback value in _get_ac_threshold is 0, 0 instead of being a float (same as the otherwise returne

Steps to reproduce:
- Intall Payroll and Switzerland localization > Switch to CH company
- Employees > New > Work Information tab > Set any Canton
- Create a contract for that employee > Set it to 'Running' state
- Payroll > Work Entries > Work Entries > Remove filters
- Navigate to next month > Regenerate Work Entries
- Generate Payslips > Error is raised

This error is raised because the fallback value in _get_ac_threshold is 0, 0 instead of being a float (same as the otherwise returned line.amount). This was most likely just a typo using the wrong decimal separator which turned th fallback into a tuple, breaking on the following operations.

opw-4204580

Forward-Port-Of: odoo/enterprise#70751

Currently, order of Many2many insurance_line_ids matters for IJM and LAAC, which can be error prone in the case where you go from example from 2 solutions -> 11,12 to one solution -> 12, the cumulated salaries will not be computed properly in this case. We make the rules Position aware in this PR, meaning that order or quantity of solutions in the contract does not matter anymore. Forward-Port-Of: odoo/enterprise#71012

Currently, order of Many2many insurance_line_ids matters for IJM and LAAC, which can be error prone in the case where you go from example from 2 solutions -> 11,12 to one solution -> 12, the cumulated salaries will not be computed properly in this case. 

We make the rules Position aware in this PR, meaning that order or quantity of solutions in the contract does not matter anymore.

Forward-Port-Of: odoo/enterprise#71012

Steps to reproduce: - Install Timesheet when on Time Off - Timesheet > Start > Input a project in the header - Try to input a task Unlike in previous versions, the tasks are not filtered to only show the belonging to the selected project. This happens because timesheet_grid_holidays adds a value to the fieldInfo domain, having a non empty domain means it is picked over field.domain, which contains the necessary filters otherwised used on tasks. opw-4204658 Forward-Port-Of: odoo/enterpr

Steps to reproduce:
- Install Timesheet when on Time Off
- Timesheet > Start > Input a project in the header
- Try to input a task

Unlike in previous versions, the tasks are not filtered to only show the belonging to the selected project. This happens because timesheet_grid_holidays adds a value to the fieldInfo domain, having a non empty domain means it is picked over field.domain, which contains the necessary filters otherwised used on tasks.

opw-4204658

Forward-Port-Of: odoo/enterprise#70749

In the payment report, a space was missing between the VAT label and the span "Emitter Acc. Ben.". In order to don't rely on spaces, a ps-1 class was added in both "Emitter Acc. Ben." and "Emitter Acc. Ord.". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#68954 Forward-Port-Of: odoo/enterprise#53722

In the payment report, a space was missing between the VAT label and
the span "Emitter Acc. Ben.". In order to don't rely on spaces, a ps-1
class was added in both "Emitter Acc. Ben." and "Emitter Acc. Ord.".

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

Forward-Port-Of: odoo/enterprise#68954
Forward-Port-Of: odoo/enterprise#53722

Forward-Port-Of: odoo/enterprise#70715

Forward-Port-Of: odoo/enterprise#70715

The problem was that the date picker was disabled when we have Use Existing ones only enabled, but it should be enabled when "Use Existing ones" is checked or "Create New" in the config of "Lots/Serial Numbers". Steps to reproduce: - add a product tracked by lots and have also enabled expiration dates - inventory Receipts configuration - in general, check both options "Use Existing ones" and "Create New" under "Lots/Serial Numbers" - now if you receive product in barcode app, you

The problem was that the date picker was disabled when we have Use Existing ones only enabled, but it should be enabled when "Use Existing ones" is checked or "Create New" in the config of "Lots/Serial Numbers".

Steps to reproduce:

- add a product tracked by lots and have also enabled expiration dates

- inventory Receipts configuration

- in general, check both options "Use Existing ones" and "Create New" under "Lots/Serial Numbers"

- now if you receive product in barcode app, you will see expiration date of the lots disbaled

opw-4086325

Forward-Port-Of: odoo/enterprise#70913
Forward-Port-Of: odoo/enterprise#68008

This commit adapts documents tests to changes made in https://github.com/odoo/odoo/pull/180776 Forward-Port-Of: odoo/enterprise#70831 Forward-Port-Of: odoo/enterprise#70795

This commit adapts documents tests to changes made in https://github.com/odoo/odoo/pull/180776

Forward-Port-Of: odoo/enterprise#70831
Forward-Port-Of: odoo/enterprise#70795

Steps to reproduce: - Install the helpdesk_sale_timesheet module. - Create two helpdesk teams (e.g. VIP Support and Customer Care). - Enable time billing and timesheets for the VIP Support team only. - In the portal view of tickets observe that the "Time Spent" label is missing Issue: - In the portal view you will see the 'Time Spent' label missing. Cause: - In the portal view of tickets the 'Time Spent' label is missing because when data is grouped (e.g. by stage, assignee, or t

Steps to reproduce:
- Install the helpdesk_sale_timesheet module.
- Create two helpdesk teams (e.g. VIP Support and Customer Care).
- Enable time billing and timesheets for the VIP Support team only.
- In the portal view of tickets observe that the "Time Spent" label is missing

Issue:
- In the portal view you will see the 'Time Spent' label missing.

Cause:
- In the portal view of tickets the 'Time Spent' label is missing because when data is grouped (e.g. by stage, assignee, 
  or team) it will check for the first group of tickets. It evaluates group in ascending order and if `use_helpdesk_sale_timesheet` is set to false for the first group the 'Time Spent' label will disappears even if it's enabled for other group.

Fix:
- In this commit we will check the `use_helpdesk_sale_timesheet` field for every ticket in the list. If it is set to true for any ticket the "Time Spent" label will be displayed; otherwise it will remain hidden.

limitation :
- In this case we need to add the list because removing `any` from the condition would violating our stability policy.

task-4058210

Forward-Port-Of: odoo/enterprise#69331

Steps to reproduce: - Download 'Project' and 'Subscription' - Create a product with: -- Product type: 'Service' -- Create on order: 'Task' -- Project: Pick any -- Recurring checkbox must not be ticked - Subscription > New > Add any recurring product > Confirm - Create invoice > Confirm invoice > Back to subscription - Upsell > Add your task creation product > Confirm - The project is linked but no task is created The ability to create tasks from upsell orders was disabled in cbbc70f7

Steps to reproduce:
- Download 'Project' and 'Subscription'
- Create a product with: -- Product type: 'Service'
-- Create on order: 'Task'
-- Project: Pick any
-- Recurring checkbox must not be ticked
- Subscription > New > Add any recurring product > Confirm
- Create invoice > Confirm invoice > Back to subscription
- Upsell > Add your task creation product > Confirm
- The project is linked but no task is created

The ability to create tasks from upsell orders was disabled in cbbc70f73e6fe9e29e27dea4415e20a262bbdf82.
According to the commit message, this was done because upsell orders prorate the price of subscriptions accoding to the time until next invoice relative to the subscription's recurrence (i.e. if the upsell is created halfway through the recurrence it is discounted by 50% etc...). Since we do not have a way to prorate tasks it is marked as a technical limitation.

This however does not need to extend to non-recurring products on subscription sale orders as they are not prorated.

opw-4114049

Forward-Port-Of: odoo/enterprise#69794

Coupled with [53d6c3492ec977e4588ee734f3c3a7f06534687a](https://github.com/odoo/odoo/pull/179266/commits/53d6c3492ec977e4588ee734f3c3a7f06534687a) Steps to reproduce: - Helpdesk > Configuration > SLA policies - Create one if necessary or use existing - Helpdesk > Tickets > Create - Configure it so that it corresponds to SLA requirements - Duplicate the ticket and merge them both (data_merge module required) Currently helpdesk ticket uses the default merge fuction, which simply concate

Coupled with [53d6c3492ec977e4588ee734f3c3a7f06534687a](https://github.com/odoo/odoo/pull/179266/commits/53d6c3492ec977e4588ee734f3c3a7f06534687a)

Steps to reproduce:
- Helpdesk > Configuration > SLA policies
- Create one if necessary or use existing
- Helpdesk > Tickets > Create
- Configure it so that it corresponds to SLA requirements
- Duplicate the ticket and merge them both (data_merge module required)

Currently helpdesk ticket uses the default merge fuction, which simply concatenates the values of merged records. This causes a few strange things to happen:

1. sla_ids which registers SLA policy types, has duplicate entries. This recordset should remain a set.

2. Followers of the merged tickets are sometimes not added to the resulting record. The default merge simply swaps the resource id with no regard for a possible duplication of unique key (res_model, res_id, partner_id), which causes the transaction to fail on repeat followers. This is a common problem with every record inheriting mail.thread which does not define its own merge function as well.

3. Keeping every SLA status record is redundant, merging tickets makes it impossbile to keep track of which task each deadline was originally related to anyway. Hence why we only keep those with the shortest deadline for each type. Priority is not a concern here since SLA policies are recomputed according to a ticket's priority rating, so we cannot have 2 SLAs with the same policy and different priorities.

opw-4037262

Forward-Port-Of: odoo/enterprise#69352

**Steps to reproduce:** - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * CFDI to public: [Checked] * Invoice Date: [Today] * Payment terms: [the following month] (e.g. 30 Days) - Confirm the invoice - Register a payment **Issues:** 1) "Payment Policy" is PUE no matter what the dates are because "CFDI to public" has been checked. 2) It is not possible to sign the p

**Steps to reproduce:**
- Install l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Create an invoice:
  * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
  * CFDI to public: [Checked]
  * Invoice Date: [Today]
  * Payment terms: [the following month] (e.g. 30 Days)
- Confirm the invoice
- Register a payment

**Issues:**
1) "Payment Policy" is PUE no matter what the dates are because "CFDI to public" has been checked.
2) It is not possible to sign the payment when the generic rfc (i.e. XAXX010101000) is used.

opw-4145716
opw-4127870

Forward-Port-Of: odoo/enterprise#70470