In case a user logs an internal note on an invoice and pings another internal user, who happens to manage notifications by email, the link to the document inside the email was directing to the portal instead of the backend. This happens because of the override of _notify_get_groups in the account module adds an extra recipient group 'additional_intended_recipient' in the first position of the groups list. This group is based on 'portal_customer' but its validation function will evaluate to Tr

In case a user logs an internal note on an invoice and pings another internal user, who happens to manage notifications by email, the link to the document inside the email was directing to the portal instead of the backend.

This happens because of the override of _notify_get_groups in the account module adds an extra recipient group 'additional_intended_recipient' in the first position of the groups list. This group is based on 'portal_customer' but its validation function will evaluate to True for internal users.

In any case, the recipient group for user must be considered first as only internal user will be validated through its function. The recipient group portal_customer can then be added in the second position, ie after user but before portal, and the eventual additional_intended_recipient can be set before portal_customer as it is the case now.

Description of the issue/feature this PR addresses:

Steps to reproduce:
1. Have a internal user that manages notifications by email
2. On a customer invoice log a note and ping this user using '@'

Current behavior before PR:

The email contains a link to the portal

Desired behavior after PR is merged:

The email contains a link to the backend


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

Forward-Port-Of: odoo/odoo#178105
Forward-Port-Of: odoo/odoo#176818

When rendering a template in the render mixin urls are converted from local to full without consideration for the website of the record being processed. We now pass the base url of the record, fetched with `get_base_url` so that email links link to the proper website when needed. task-4104753 Forward-Port-Of: odoo/odoo#178660 Forward-Port-Of: odoo/odoo#176152

When rendering a template in the render mixin
urls are converted from local to full without consideration for the website of the record being processed.

We now pass the base url of the record, fetched with `get_base_url` so that email links link to the proper website when needed.

task-4104753

Forward-Port-Of: odoo/odoo#178660
Forward-Port-Of: odoo/odoo#176152

If nobody gave a global discount (fixed amount/on SO) in a given company before, the first user to give a global discount through the dedicated wizard would create the dedicated Discount product for that company. Nevertheless, it was not done in sudo, so the user would get a traceback if he didn't have admin rights (for company update) or manager rights (for the product creation). opw-4048403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-

If nobody gave a global discount (fixed amount/on SO) in a given company before, the first user to give a global discount through the dedicated wizard would create the dedicated Discount product for that company.

Nevertheless, it was not done in sudo, so the user would get a traceback if he didn't have admin rights (for company update) or manager rights (for the product creation).

opw-4048403





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

Forward-Port-Of: odoo/odoo#178361

With negative unit price it was possible to have a zero division error when ventilating the analytic distributions. Example: Create a new sale order, set the business partner and other header data. Add a line, with a VAT of 15% for example. With a product, It doesn't matter which one. a price. To this line, add 2 analytics distributions. Add a second line whit an other product, a price and an other VAT 7% for example. Add the same analytic distribution. Add a third line, a discount one, same pr

With negative unit price it was possible to have a zero division error when ventilating the analytic distributions. Example:
Create a new sale order, set the business partner and other header data. Add a line, with a VAT of 15% for example. With a product, It doesn't matter which one. a price. To this line, add 2 analytics distributions. Add a second line whit an other product, a price and an other VAT 7% for example. Add the same analytic distribution. Add a third line, a discount one, same price * -1 then then second. same VAT then the second. Add analytic distribution. Make a down payment

This fix also remove the 0 amount down payment line this would create.

opw-4140669

Forward-Port-Of: odoo/odoo#178043

When a widget is destroyed before it is fully initialized, it should not crash. When the widget implementation was merged into the public widget one at [1], that bug was created for public widgets. No existing flow was found to be broken because of this but it would not be a surprise if this actually fixes issues. [1]: https://github.com/odoo/odoo/commit/51b1808ebedf9b810f83d264bb7e9204cab45e4a Found while working on task-3930204 Forward-Port-Of: odoo/odoo#178618

When a widget is destroyed before it is fully initialized, it should not crash. When the widget implementation was merged into the public widget one at [1], that bug was created for public widgets.

No existing flow was found to be broken because of this but it would not be a surprise if this actually fixes issues.

[1]: https://github.com/odoo/odoo/commit/51b1808ebedf9b810f83d264bb7e9204cab45e4a

Found while working on task-3930204

Forward-Port-Of: odoo/odoo#178618

Steps to reproduce: - Payroll > Contracts > Contracts - Pick a running contract - Add a new line to the working schedule such that: -- It starts exactly when the previous entry ends -- Both it and the previous entry have a work entry type -- They both have different types - Work Entries > Work entries - Regenerate work entries for the employee whose contract you editted - It appears as a singular block of the first entry's type For example Monday afernoon has an entry from 13:00 to 17:

Steps to reproduce:
- Payroll > Contracts > Contracts
- Pick a running contract
- Add a new line to the working schedule such that: -- It starts exactly when the previous entry ends
-- Both it and the previous entry have a work entry type -- They both have different types
- Work Entries > Work entries
- Regenerate work entries for the employee whose contract you editted
- It appears as a singular block of the first entry's type

For example Monday afernoon has an entry from 13:00 to 17:00, give it type attendance then create a new line from 17:00 to 18:00 with type ovetime hours. This is interpreted as a singular work entry of type attendance spanning from 13:00 to 18:00.

Work entries of different type should be kept separate or at least show all encompassed wok entry types. Preventing the merge is difficult as other modules likely want this behavior in resource.calendar hence the post processing method used here.

opw-4053366

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

Forward-Port-Of: odoo/odoo#177755

This commit adds a localization module for Jordan. It includes the following: 1. Chart of accounts. 2. Accounts groups. 3. Taxes. 4. Tax report. task-2732319 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176683

This commit adds a localization module for Jordan. It includes the following:
1. Chart of accounts.
2. Accounts groups.
3. Taxes.
4. Tax report.

task-2732319




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

Forward-Port-Of: odoo/odoo#176683

### Steps to reproduce: - Install Time-off module - Create new allocation for an employee for 1 day - Create a leave for this employee with more than 1 day -error will be raised- - Edit the leave to be for just one day and validate it - Refuse this leave and mark it as draft - Change the dates to be more than 1 day ### Current behavior before PR: It is expected to raise an Error each time an employee tries to have a leave which has more days than the allocation he has but this is

### Steps to reproduce:
	- Install Time-off module
	- Create new allocation for an employee for 1 day
	- Create a leave for this employee with more than 1 day -error will be raised-
	- Edit the leave to be for just one day and validate it
	- Refuse this leave and mark it as draft
	- Change the dates to be more than 1 day

### Current behavior before PR:
It is expected to raise an Error each time an employee tries to have a leave which has more days than the allocation he has but this is not happening when the leave is in draft state. So the employee can submit a leave with days more than the allocation.

This issue is happening because when checking if there is excess days in the leave we don't take leaves in draft state into considertion. https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_employee.py#L387:L391

### Desired behavior after PR is merged:
After editing the leaves_domain we are now taking draft leaves into cosideration when we are checking the leave validity.

opw-4090572

Forward-Port-Of: odoo/odoo#176936

* STEP TO REPRODUCE: create an application then change to the stage which we will hire he/she -> Duplicate that application -> the new one already display ribbon 'Hired' * SOLUTION: make copy=False to date_close to avoid this 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#177606 Forward-Port-

* STEP TO REPRODUCE: create an application then change to the stage which we will hire he/she -> Duplicate that application -> the new one already display ribbon 'Hired'
* SOLUTION: make copy=False to date_close to avoid this

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#177606
Forward-Port-Of: odoo/odoo#176879

Steps to reproduce: - Go to a product page - Enable "Discussions and rating" in the eCommerce - Add some comments and ratings on the product - Use the filtering tool on the left => It does not work anymore task-4149745 Forward-Port-Of: odoo/odoo#178661 Forward-Port-Of: odoo/odoo#178524

Steps to reproduce:
- Go to a product page
- Enable "Discussions and rating" in the eCommerce
- Add some comments and ratings on the product
- Use the filtering tool on the left => It does not work anymore

task-4149745

Forward-Port-Of: odoo/odoo#178661
Forward-Port-Of: odoo/odoo#178524

Since odoo/enterprise#38575, portal users can create/edit knowledge articles. However, the test that checks that feature is not correct: - it does not call `check_access_rights()` (for ACLs); - it uses a `res.partner` instead of a `res.users` in `with_user()`. Because the test only checks access rules with a non-existing user, no rules are found, and the check is therefore trivial. In other words, the test passes by accident :-( The fix consists in creating a portal user for the corr

Since odoo/enterprise#38575, portal users can create/edit knowledge articles.  However, the test that checks that feature is not correct:
 - it does not call `check_access_rights()` (for ACLs);
 - it uses a `res.partner` instead of a `res.users` in `with_user()`.

Because the test only checks access rules with a non-existing user, no rules are found, and the check is therefore trivial.  In other words, the test passes by accident :-(

The fix consists in creating a portal user for the corresponding "customer" contact, and add the expected calls to `check_access_rights()`.

Forward-Port-Of: odoo/enterprise#69157