added more options to print via cups: - duplex mode (recto/verso), - landscape mode. Task: 3598690 Forward-Port-Of: odoo/odoo#177882

added more options to print via cups:
- duplex mode (recto/verso),
- landscape mode.

Task: 3598690

Forward-Port-Of: odoo/odoo#177882

Commit that introduced the issue: https://github.com/odoo/odoo/commit/1ffcea337ba463c383483ca53ff57aa6b725b5a2 Issue: ====== Traceback after signature command Steps to reproduce the issue: ============================= - Go to chatter - Open mail composer - type /signature + enter - traceback Origin of the issue: ==================== The change in the mentioned commit added an issue , becuase `user_id` isn't always a number sometimes it's an array. Solution: ========= We c

Commit that introduced the issue: https://github.com/odoo/odoo/commit/1ffcea337ba463c383483ca53ff57aa6b725b5a2

Issue:
======
Traceback after signature command

Steps to reproduce the issue:
=============================
- Go to chatter
- Open mail composer
- type /signature + enter
- traceback

Origin of the issue:
====================
The change in the mentioned commit added an issue , becuase `user_id` isn't always a number sometimes it's an array.

Solution:
=========
We copy the same logic done here https://github.com/odoo/odoo/blob/fd830fd9171e52d379f82b4adee221a6cf83d8eb/addons/bus/static/src/services/bus_service.js#L125

task-4143860

Forward-Port-Of: odoo/odoo#178181

[FIX] hr_holidays: take time into account during deserialization Steps to reproduce: - Install Time Off - Set your time-zone to UTC+1 - Modify your working schedules for Monday Morning to start at 00:30 - Create a leave for Monday and Tuesday in the Time Off app Issues: The calendar show 3 days for the leave. This is due to the field `all_day`, since it's set we will deserialize the record with the function `deserializeDate`. https://github.com/odoo/odoo/blob/44a1b163481b0b781028

[FIX] hr_holidays: take time into account during deserialization

Steps to reproduce:
- Install Time Off
- Set your time-zone to UTC+1
- Modify your working schedules for Monday Morning to start at 00:30
- Create a leave for Monday and Tuesday in the Time Off app

Issues:
The calendar show 3 days for the leave. This is due to the field
`all_day`, since it's set we will deserialize the record with the
function `deserializeDate`.

https://github.com/odoo/odoo/blob/44a1b163481b0b781028ce337d72fbb0c8730475/addons/web/static/src/views/calendar/calendar_model.js#L503-L509

This function doesn't take into account the time in the record, which
means that it will just deserialize the date which is Sunday in our
case because of the timezone conversion to UTC.

Because of this the frontend thinks that the leave takes place from
Sunday to Tuesday.

We can remove `all_day` thanks to this [fix](https://github.com/odoo/odoo/commit/3ccc6bfa86618b0ca13c13960c15b60f8f75f3ce) which enable `allDaySlot`
options by default which allow us to preserve the original behavior of
the calendar view in hr_holidays while correctly deserializing the
datetime.

opw-4043180

Forward-Port-Of: odoo/odoo#173147

Problem: When a discount is based on quantity and we update the quantity to a value that does not have a discount, the stale discount value remains. Steps to reproduce: - Create a product with two vendor lines for the same vendor but different discounts based on quantity: - Vendor1: Quantity 10 - Discount 5% - Vendor1: Quantity 20 - Discount 10% - Create a new quotation with the product and set the quantity to 10. - Update the quantity to 20. - Update the quantity to 1. The 10% discoun

Problem:
When a discount is based on quantity and we update the quantity to a value that does not have a discount, the stale discount value remains.

Steps to reproduce:

- Create a product with two vendor lines for the same vendor but different discounts based on quantity: - Vendor1: Quantity 10 - Discount 5% - Vendor1: Quantity 20 - Discount 10%
- Create a new quotation with the product and set the quantity to 10.
- Update the quantity to 20.
- Update the quantity to 1. The 10% discount still appears, even though it should have been removed.

opw-4123984

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

Forward-Port-Of: odoo/odoo#177404

When calling apply_inheritance_specs and moving a node (before after or inside), we merge the text content of the adjacents nodes. If the parent and target node both have no text, we should not set the text to an empty string. When a node has no text, it is serialized as follows: `<node/>` But if it has an empty string, it has the following representation: `<node></node>` In the linked PR, we now apply the studio inheritance manually, and since we use the resulting tree directly i

When calling apply_inheritance_specs and moving a node (before after or inside), we merge the text content of the adjacents nodes. If the parent and target node both have no text, we should not set the text to an empty string.

When a node has no text, it is serialized as follows:

`<node/>`

But if it has an empty string, it has the following representation:

`<node></node>`

In the linked PR, we now apply the studio inheritance manually, and since we use the resulting tree directly instead of parsing the result, the `remove_blank_text` option of the parser has no effect.

This causes existing tests to show some difference.

opw-3819667

Forward-Port-Of: odoo/odoo#175867

To reproduce: - Install `account` in a fresh DB - Change the CoA to one which doesn't use anglo-saxon accounting - Notice how anglo-saxon accounting is still activated on the company Analysis: - Since `anglo_saxon_accounting` has a default value of False, we don't bother to specify its value in the templates which don't use it. - So, when switching CoA from one which uses anglo-saxon accounting to one which doesn't, False doesn't get written. Solution: - We explicitly reset it when c

To reproduce:
- Install `account` in a fresh DB
- Change the CoA to one which doesn't use anglo-saxon accounting
- Notice how anglo-saxon accounting is still activated on the company

Analysis:
- Since `anglo_saxon_accounting` has a default value of False, we don't bother to specify its value in the templates which don't use it.
- So, when switching CoA from one which uses anglo-saxon accounting to one which doesn't, False doesn't get written.

Solution:
- We explicitly reset it when changing CoA.
- We could have put a default value of False in the template values, but that doesn't combine nicely with the existing code, so this solution is preferred.

This has been causing issues for new SaaS databases, since the `saas_worker` first generates a database template for the Accounting app, and only afterwards generates database templates for each localization by changing the CoA.

As far as I can see, no other fields need the same treatment.

taskid: none

Forward-Port-Of: odoo/odoo#178113

During refactoring of hr_holidays for 17.0 (commit https://github.com/odoo/odoo/commit/8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a) a typo was introduced. Forward-Port-Of: odoo/odoo#177563

During refactoring of hr_holidays for 17.0 (commit https://github.com/odoo/odoo/commit/8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a) a typo was introduced.

Forward-Port-Of: odoo/odoo#177563

Changed the note on the attached_on field to properly note that the Inside quote option will include the document on the pdf of the quotation and sale order instead of just the quotation. Previously only said that it would be on the quote and caused confusion for customers when it would also show on the sale order. opw-4106894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177681

Changed the note on the attached_on field to properly note that the Inside quote option will include the document on the pdf of the quotation and sale order instead of just the quotation. Previously only said that it would be on the quote and caused confusion for customers when it would also show on the sale order.

opw-4106894




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

Forward-Port-Of: odoo/odoo#177681

This commit fixes the group_expand in porject_entreprise when searching for a assignees (thus on the res.users model). The problem was that the portal users were also displayed, which makes no sense as they cannot be assigned to tasks. taskid:3703637 Forward-Port-Of: odoo/enterprise#56038

This commit fixes the group_expand in porject_entreprise when searching for a assignees (thus on the res.users model). The problem was that the portal users were also displayed, which makes no sense as they cannot be assigned to tasks.

taskid:3703637

Forward-Port-Of: odoo/enterprise#56038

Forward-Port-Of: odoo/enterprise#67980

Forward-Port-Of: odoo/enterprise#67980

Steps: - Install `marketing_automation` and `web_studio` - Open Marketing Automation and studio - Click "Edit Menu" - Click "New Menu" - Set a name - Set Existing Model - Select "Marketing Activity" - Confirm - Try to use this new menu - Traceback This is because a compute is triggered in marketing_activity and we use `literal_eval` on domain fields unsetted. `literal_eval` works only with string https://docs.python.org/3/library/ast.html#a

Steps:
    - Install `marketing_automation` and `web_studio`
    - Open Marketing Automation and studio
    - Click "Edit Menu"
    - Click "New Menu"
    - Set a name
    - Set Existing Model
    - Select "Marketing Activity"
    - Confirm
    - Try to use this new menu
    - Traceback

This is because a compute is triggered in marketing_activity and we use `literal_eval` on domain fields unsetted.

`literal_eval` works only with string https://docs.python.org/3/library/ast.html#ast.literal_eval

opw-4115586

Forward-Port-Of: odoo/enterprise#68920