# How to reproduce
- Go to Inventory > Settings > Operation Types
- Pick any Operation and disable "Allow extra product"
- Create a picking for that operation type with atleast one product and click on "Mark as Todo"
- Go to the Barcode app and find the created picking
- Scan all the reserved products
- Exit the picking and re-enter

# The problem
The "Add Product" button is displayed and you can scan unreserved products even tough you sould not be allowed to

# Cause of the issue
The problem stems from the fact that even with "Allow extra product" disabled, we still allow to add unreserved products for immediate transfers (created directly in the barcode app). The issue is that we don't really have a way to distinguish immediate transfers from plannified ones made in the Inventory app. So we try to guess using the `_useReservation` attribute (If it is false, we allow additional products).

`_useReservation` is computed as follows : if any move lines from the inital state is not yet picked, set it to true :
https://github.com/odoo/enterprise/blob/ca4b369e4fc9f4655574cf1ca71c81faaadc3e88/stock_barcode/static/src/models/barcode_picking_model.js#L43

So in our case, once all the reserved products are scanned, all the initial move lines are picked and our guessing fails.

# Proposed Solution
Since immediate transfers are never validated and stays in draft mode, guess using the state of the current picking in addition to `useReservation`

opw-6231238

Forward-Port-Of: odoo/enterprise#118378

# How to reproduce
You need to simulate the fact that you are creating an appraisal late so either : 
A) Directly edit the `next_appraisal_date` in SQL
B) Go to Employee App > any Employee > Settings, set Next Appraisal Date to tomorrow and wait for 2 days

Then :
- Click on Request Appraisal
- Save

# The problem
An error is shown saying "You cannot set 'Next Appraisal Date' in the past.". You can workaround this by changing the Next Appraisal Date to a date in the future, but the problem is not every user has the right to do this.

# Cause
`next_appraisal_date` is also defined in hr.appraisal as a relate field of hr.employee : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_appraisal.py#L56-L57

When creating an hr.appraisal, `next_appraisal_date` is present in `vals_list` because it is defined in the view since : https://github.com/odoo/enterprise/commit/58fba3098f33db82dfbccca2db229550402ed3ab https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/views/hr_appraisal_views.xml#L92

This triggers a write on `next_appraisal_date` of hr.employee which triggers a constraint : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_employee.py#L81-L85

opw-6147865

Forward-Port-Of: odoo/enterprise#122440
Forward-Port-Of: odoo/enterprise#114876

The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded article, it gets added to its parent's child_ids in the main tree, even though the parent's other children were not fetched. A folded article only gets its favorited children back from get_sidebar_articles, not its whole child set.

When the parent is then unfolded, unfold() only read the children from the database when child_ids was empty. The favorited child already filled child_ids, so the call was skipped and the remaining children stayed hidden until the next reload.

unfold() now uses a new children_loaded flag instead of the length of child_ids to decide whether to fetch the children. The flag is set once an article's whole child set is loaded: in loadChildren(), and in loadArticles() for the articles that were unfolded, since those come back with all their children. loadChildren() also rebuilds child_ids from the search result so a favorite already loaded is not added twice. The fix lives in the sidebar component because the partial child_ids only exists on the frontend, get_sidebar_articles already returns the right records.

Steps to reproduce:
1. Open the Knowledge app
2. Create an article with two child articles
3. Add one of the two children to your favorites with the star icon
4. Open another article that is not under that parent
5. Fold the parent article in the sidebar, then refresh the page
6. Expand the parent article

=> only the favorited child is shown under the parent, the other child is missing

Ticket [link](https://www.odoo.com/odoo/project.task/6186466)
opw-6186466

Forward-Port-Of: odoo/enterprise#118804

Steps to reproduce:
1. Install `l10n_ke_edi_oscu_pos`, set company to Kenya.
2. Sell and validate an order.
3. Refund it from the POS and validate the refund order.

Issue:
- A traceback is raised when validating the refund: `ValueError: Expected singleton: pos.order(<refund>, <original>)` raised in `get_l10n_ke_edi_oscu_pos_data`.

Cause:
- When syncing a refund, `sync_from_ui` returns both the new refund order and the original refunded order. `waitForPushOrder` forces post-processing for every Kenyan order in that list, so `beforePostPushOrderResolve` receives both ids in `order_server_ids` and forwards them as-is to `action_post_order` and `get_l10n_ke_edi_oscu_pos_data`, both of which expect a single record. `action_post_order` fails the same way, but its error was silently swallowed by the surrounding try/catch, letting the traceback surface only on the second call.
- The same multi-id list is also produced whenever several orders created offline get synced together once back online.

Solution:
- `get_l10n_ke_edi_oscu_pos_data` is only needed for the receipt of the order being validated, so call it with `order.id` instead of the full `order_server_ids` list.
- Replace the `action_post_order` call with `action_post_selected_orders`, which posts each order individually and skips ones already sent to eTIMS, correctly handling both the refund case (original order is already `sent`) and the offline multi-order sync case.

opw-6364221

Forward-Port-Of: odoo/enterprise#123043