When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines.

Steps to reproduce:
-------------------
* Install timesheet_grid and project_mrp_account
* Create product A, storable
* Create product B with a cost of 20 and also storable
* Update the available quantity of product B
* Create a BoM for product A, it should only require one product B
* Update Marc Demo access right and make sure he doesn't have access to any accounting stuff and he has atleast timesheet approver
* Create a first MO for 1 product A and produce it
* Create a second MO for 1 prodcuct A but just confirm it
* Login as Marc Demo and try to scrap the component of the second MO
> Observation: You get an access error here https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/stock_account/models/analytic_account.py#L95

opw-5954989

Forward-Port-Of: odoo/odoo#261588
Forward-Port-Of: odoo/odoo#255824

Steps to reproduce:
- Install documents_account and account_accountant.
- Create and post a customer invoice.
- Add an image attachment via a log note.
- Click Send & Print.
-> KeyError: `proforma_pdf_attachment`

Cause:
When attaching an image via a log note, the file becomes the main
attachment but is intentionally unlinked (res_model=False) by the
system to avoid UI clutter. Downstream modules unknowingly sync this
orphaned file. Later, when "Send & Print" generates the real PDF,
the system attempts to update the orphaned downstream record, causing
model linkage conflicts and eventually a crash.

Solution:
Add `no_document=True` to the context during `_message_post_after_hook`
for invoices. Previously, for incoming emails or log notes, the mail
framework would trigger document creation immediately before the core
accounting module could evaluate and orphan invalid files (like images).
This change suppresses that premature sync, allowing downstream modules
to explicitly handle the sync after the attachment's final state is
resolved.

opw-5930888

### Steps to reproduce:

- In the settings: Enable "Storage Locations"
- Inventory > Configuration > Warehouse Management > Operation Types
- On receipts, in the Barcode App tab enable: "Force a destination on all products"
- Open the barcode app, create a new receipt
- Scan a product > Validate
#### > You are not blocked by the fact that you did not scan any destination even just to validate the default one

### Cause of the issue:

The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app.

### Note:

Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322
In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576
It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination.

### Note 2:

We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter:
https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109

opw-6110690

Forward-Port-Of: odoo/enterprise#115534
Forward-Port-Of: odoo/enterprise#114429

Steps to reproduce:
- Set a journal with documents folder sync.
- Create and post a customer invoice.
- Add an image attachment via a log note.
- Click Send & Print.
-> KeyError: `proforma_pdf_attachment`

Cause:
Adding an image via log note sets it as the main attachment, but it 
is intentionally orphaned (res_model=False) to prevent UI clutter. 
`documents_account` incorrectly syncs this unlinked file, creating a 
workspace document with a missing model.

During "Send & Print", the official invoice PDF replaces the image as
the main attachment. The document versioning logic intercepts this swap
and attempts to re-parent the new PDF to match the orphaned document.
This destroys the PDF's linkage to the invoice, causing a crash when
the system later attempts to fetch the PDF.

Solution:
Since the base module now suppresses premature document creation during 
the message post, we explicitly handle the sync ourselves. We override 
`_fix_attachments_on_record_from_files_data` to iterate over the 
validated attachments and trigger document creation only for files 
that retained their `res_model`. We also add a check inside 
`_update_or_create_document` to strictly block orphaned attachments.

opw-5930888