How to Reproduce : 
1. Remove 'Create' access on the 'Knowledge Article' model for Portal and 
   Internal users.
2. Now log in as a Portal.
3. Try to create a new private article.
4. Log in as an Internal user.
5. Try to create a new private article.

Both Internal and Portal users can still create private articles even after
'Create access' is removed.

Article creation logic in `knowledge.article` was bypassing the usual access
rights because of `sudo` (mainly to add the creator as a member, since creation
rights on the member model are not granted). This allowed users to create
private articles even without create access.

This commit introduces:
1. Model-level access check in `create`. Sudo the creation of articles only when
   the user has create rights.

2. UI imp to hide the '+' button in the sidebar and the `New` button in
   the topbar when the user doesn't have create access.

3. New test cases to verify that model-level access rights are respected when creating an article.

task-4916280

Forward-Port-Of: odoo/enterprise#101804
Forward-Port-Of: odoo/enterprise#93034

**Issue:**
Payslips show blank worked days for employees with contracts without a `resource_calendar_id` (fully flexible, despite having valid work entries

**Cause:**
`_get_worked_day_lines()`  skips worked day computation if the contract has no calendar

https://github.com/odoo/enterprise/blob/1a10e0444fdb71a072262a1f14f0bfc766d109c6/hr_payroll/models/hr_payslip.py#L665-L674

**Steps to Reproduce:**
- Assign an employee a fully flexible contract with attendance as work entry source.
- Create work entries based on the attendance records of the employee record
- Go to employees > contracts > new Payslip Worked Days section is empty, even though attendance shifts are showing up on top.

**Fix:**
removing the calendar requirement in the main method and adding a fallback calendar in the called utility method

**Note:** same issue happens if work entry source of the contract is Planning

opw-4931972

Forward-Port-Of: odoo/enterprise#98194
Forward-Port-Of: odoo/enterprise#93935

**BUG:** 
Traceback when **suggesting** deleting a BOM step from the shopfoor. 

**STEPS TO REPRODUCE:** 
- Open a shopfloor MO (with PLM installed)
-- Add a suggestion step (MO > cog> Update instructions > Improvement Suggestion > Add a step). 
-- Add a second suggestion step after the first one.
-- Delete the second suggestion step  (MO > cog> Update instructions > Improvement Suggestion > Delete a step).
-- Add a third suggest suggestion step after the second one we just suggested deleting.
-- > Traceback 

**ORIGIN:** 
First, when adding the suggestions:
 - 2 Quality Check (QC) are created on the **new_bom_id** in `add_quality_check_from_tablet.save()` 
 - 2 Quality Point (QP) are also created in  `add_check_in_chain()`, (only in mrp_workorder_plm override) 
- The 2nd new QC is linked to previous QC in `_insert_in_chain`

Secondly, when deleting the 2nd added suggestion (_on the same MO, as suggestions are linked to the new bom_id and wont appear on other MOs until ECO is validated_):
- The QP of the second QC is deleted (but the QC itself is not deleted) here:

https://github.com/odoo/enterprise/blob/f91b0c8c41f40a71cbea3cd4f5ccc6873af3c004/mrp_workorder_plm/wizard/propose_change.py#L72-L74

Finally, when adding a new suggestion after the one we just suggested deleting, in `_add_check_in_chain`, a traceback happens by trying to access the QP point we deleted in the resequencing part of  `_add_check_in_chain` here:
https://github.com/odoo/enterprise/blob/eb716c18944ec50c9c8c74a2888ed5f3032a7b08/mrp_workorder_plm/models/mrp_workorder.py#L62-L63

**FIX:**
We accept that not all QCs must have QPs  `[0]` -> `[:1]` (see note on another approach idea) changing

```diff
- point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[0] 
+ point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[:1] 
```

**NOTES:**
-1 Another fix could have been to delete the QC at the same time as the QP but I did not find any `remove_from_chain` function to safely remove the QC from the chain of QC. Along those lines we could rethink the sequencing / resequencing of QC and QP as the logic seems to differ between both. 
-2 Added some comments to remove the field and the line setting the `is_deleted` field in master as it was not used anywhere in the code (the color highlighting in the ECO is done with `<list decoration-danger="change_type=='remove'" ...>`)


ticket #5180122

Forward-Port-Of: odoo/enterprise#101366

## Context
In the barcode app (`stock_barcode`), users can update inventory counts
by scanning a product's barcode or by manually entering the barcode.

## Issue
When the barcode is entered manually, the lot/serial number is created with
the *Company* field set to the current company. This causes issues when
working with intercompany flows, because lots with a company assigned
cannot be used by other companies. This behavior is also inconsistent
with the other ways of updating a company's inventory. In fact, the following
flows create serial/lot numbers with no company assigned:
- Inventory / Products / Products / *Forecasted Report* or *On Hand*
- Inventory / Operations / Adjustments / Physical Inventory
- Barcode / Inventory Count / Add product (add the serial number from
the *Inventory Count* screen, **not** by clicking on the cogwheel in
the top-right corner)

## Cause
The line assigning a `company_id` was added by https://github.com/odoo/enterprise/commit/c0151bce3c60c69e7cadeb719a81c4a702b71c34.
At the time, that behavior was consistent with the backend behavior,
as the `company_id` of a lot/serial number would always be set to `self.env.company`.
In fact, the feature allowing a lot/serial to be shared among multiple
companies was introduced later, in saas-17.2 (https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69).
This last commit adds a compute method for the `stock.lot.company_id` field:

https://github.com/odoo/odoo/blob/6026866900fd0ac1bf6495ae249cd08f56c85342/addons/stock/models/stock_lot.py#L130-L136

Since then, lot/serial numbers shouldn't be created with a `company_id`,
as this restrict other companies to use those numbers. Users can always
add a company to a lot/serial number later if necessary.

## Solution
The line assigning a `company_id` to the `stock.lot` can be removed,
as it does not reflect the current behavior (saas-17.2+).
Nowadays, a `company_id` should be set **only** if the user wants a
lot/serial number to be used by a specific company; it should not be
the default behavior.

## Steps to reproduce
1. Install *Barcode* (`stock_barcode`).
2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*.
3. In Settings / Users & Companies / Companies, create a second company.
Use either company for the following steps.
4. Create a product tracked *By Unique Serial Number*.
5. Open the Barcode app, then click *Inventory Count*.
6. Scan your product (or add it manually, but **do not** set the *Serial/Lot Number*).
7. Scan "SN001" (or add it manually through the cogwheel menu), then click *Apply*.
8. Go to Inventory / Products / Lots / Serial Numbers.
9. The serial number created from the Barcode app is assigned to the current company.

opw-5264216

Forward-Port-Of: odoo/enterprise#102130