**Problem:**
when doing a refund from pos of an avco (or fifo) product, with the option 
"ship later" the cost of the product does not appear on the pos order line

**Steps to reproduce:**
- Enable Settings "Allow Ship Later", "Automatic Accounting"
- Navigate to Sales/Configuration/Product Categories
- Create a new category with Inventory Valuation field as "Automated" 
and the Costing Method field as "Average Cost (AVCO)"
- Open Point of Sale/Product
- Create a new storable product
- In the general information tab set a cost and select your new 
category for the product category field
- In the Sales tab, make sure that "Available in POS" is checked 
and select a category
- Set an on Hand quantity
- Open a point of sale from the Point of Sale Dashboard
- Select your product and click on Payment
- On the top right of the screen select a customer with an adress,
click on Invoice and on Ship later
- Select a payment method and validate
- Navigate to Point of Sale/Orders
- click on the last order created, and click on the "Pickings" smart button
- validate the picking
- come back to the store in point of sale
- select the three horizontal lines on the top right and click on Orders
- filter by paid orders
- select the last order created and click on refund and then on payment
- check Invoice and Ship Later on the top right, select a payment method and validate
- Navigate back to Point of Sale/orders and select the last order created

**Current behavior:**
 The total cost is zero on the pos order line
 Even if the delivery is validated via the Picking smart button
 the total cost is still zero

**Expected behavior:**
 It should reflect the cost of the product (depending on the costing method)

**Cause of the issue:**

When the pos order is created from Point of Sale, the process_saved_order method is called
this method calls (1)create_order_picking and then (2)compute_total_cost.
https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/point_of_sale/models/pos_order.py#L183-L184 

**Scenario A** Inside (1) create_order_picking, if the PosOrder doesn't have 
a shipping_date the if statement is False
https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/point_of_sale/models/pos_order.py#L1017 
and the method _create_picking_from_pos_order_lines is called.
This method then calls _action_done.
https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/point_of_sale/models/stock_picking.py#L70 
Inside the stock_account override of _action_done, _create_in_svl is called.
https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/stock_account/models/stock_move.py#L289
This method sets the value of the stock_valuation_layer_ids attribute
of the stock move to a new stock valuation layer.

**Scenario B** Inside (1) create_order_picking, if the PosOrder has a 
shipping_date (in the case where we selected "Ship Later") the 
method _launch_stock_rule_from_pos_order_lines is called.
https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/point_of_sale/models/pos_order.py#L1017-L1018 
and nowhere inside this method is _action_done called.
This makes sense because the stock move hasn't been validated.

When (2) compute_total_cost is then called by process_saved_oder, if the product category is avco, _compute_average_price will be called. 
If we are in Scenario B there is no stock valuation layer for this stock move.
Consequently there will be no candidates and the price will not be computed.
https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/stock_account/models/product.py#L795-L798

opw-4614503

Forward-Port-Of: odoo/odoo#207482

### Steps to reproduce:
	1. Create a portal user.
	2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view
	3. Now, add the portal user as a follower on a task.
	4. Change the state of a task to execute an automation rule.
	5. Email will be received by a portal user but it will not be visible on the messaging history on the portal.

### Cause:
This is happening because when running an automation rule that will send an email we set the 'mail.message' state as System notification by default which leads that this mail will be sent normally to every follower of the record but will be only shown in the chat history for internal users not portal as we are just showing 'comment', 'incoming_email' and 'outgoing_email' messages.

### Fix:
Checking if the server action that is being run is sending an email we will
set the state of the 'mail.message' as 'auto_comment' -introduced in https://github.com/odoo/odoo/pull/94018/commits/d1dd307555ac78841384d1158de5a0a7787370db - and add 'auto_comment'
to the domain of the field website_message_id which is for the messages
shown to the portal user in his view

P.S. LNA confirmed that we need to show it to the portal user.

opw-4459754

Forward-Port-Of: odoo/odoo#194401

### Steps to reproduce:
	- Navigate to Recruitment > Job Position > Any job position > Job applications (smart button)
	- Create an applicant
	- Set a Recruiter for the applicant
	- Move the stage to 'Contract Signed'
	- Click on 'Create Employee'
	- Notice a validation error that the opertion cannot be completed

### Cause:
This is happening as the 'Job applications' smart button has default value for the user_id in context

https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95236d6f045c30d64/addons/hr_recruitment/views/hr_job_views.xml#L207-L211

so when creating an employee it will add the missing fields from defaults and it will get the default value in the context which for an existing user so when creating the employee with this user_id it will trigger the sql constraint

https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95236d6f045c30d64/addons/hr/models/hr_employee.py#L145-L148

### Fix:
clean the context before creating the partner and the employee corresponding to this applicant

opw-4629219

Forward-Port-Of: odoo/odoo#204997

This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry exceeds the interval of the payslip, which can happen when a work entry starts before the payslip interval or ends after the payslip interval.

Previously, the UTC times were used. Consider an EST work entry that starts at 18:00 one night and ends at 01:00 the next morning. The UTC times would be 22:00 and 05:00 respecively, up to a 1-hour difference for daylight savings time. Now suppose that the paysliip for this work entry only goes up to that following morning. Instead of using the local times of 18:00 and 01:00, the payslip would use the UTC times of 22:00 and 05:00, which would only count 2 of those hours instead of 6.

This is resolved by converting the UTC times to local before using them to clamp the work entries to the payslip interval.

opw-4790119

Forward-Port-Of: odoo/enterprise#85548

### Steps to reproduce:
	1. Create a portal user.
	2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view
	3. Now, add the portal user as a follower on a task.
	4. Change the state of a task to execute an automation rule.
	5. Email will be received by a portal user but it will not be visible on the messaging history on the portal.

### Cause:
This is happening because when running an automation rule that will send an email we set the 'mail.message' state as System notification by default which leads that this mail will be sent normally to every follower of the record but will be only shown in the chat history for internal users not portal as we are just showing 'comment', 'incoming_email' and 'outgoing_email' messages.

### Fix:
Checking if the server action that is being run is sending an email we will set the state of the 'mail.message' as 'auto_comment' and add 'auto_comment' to the domain of the field website_message_id which is for the messages shown to the portal user in his view

opw-4459754

Forward-Port-Of: odoo/enterprise#82352