[19.0][FIX] impersonate_login: preserve attachment creator ownership

[gdgellatly]

Summary

• Avoid rewriting create_uid / write_uid on ir.attachment during impersonation in impersonate_login.
• This keeps Odoo core attachment access semantics for temporary/generated attachments (not yet linked to a record via res_model/res_id).
• Fixes access errors during PO confirm/email compose where generated report attachments were created under the original impersonator and immediately unreadable by the active impersonated user.

Options considered

• Option A (implemented): Exclude ir.attachment from impersonate create_uid/write_uid rewriting in base overrides.
  • Pros: very small patch, aligns with core ir.attachment ownership checks, no security rule override.
  • Cons: attachment audit attribution stays with effective user instead of impersonator for these records.
• Option B (tried, reverted): Narrow ir.attachment._check_access override to whitelist only orphan attachments created by impersonate_from_uid in impersonated sessions.
  • This initially caused a recursion error because filtering forbidden attachment records triggered attachment access checks again.
  • Even after a recursion-safe adjustment, behavior remained brittle and more invasive in a security-critical path.
• Option C (rejected): Broadly bypass core attachment check branch around owner mismatch.
  • Rejected as too risky from a security perspective.

Failures observed during investigation

• Access error on read for generated attachment in mail compose flow:
  • Sorry, you are not allowed to access this document ... Records: ir.attachment(...), User: <impersonated uid>
• Recursion failure with _check_access override approach:
  • RecursionError: maximum recursion depth exceeded

[gdgellatly]

This came up in testing a workflow that automatically popped a mail template with an attachment, purchases specifically. I tried to make real narrow but I either got recursion errors or same access error.

[gdgellatly]

I am just wondering if my experience is a symptom of #904 and the storing of mail messages

[OCA-git-bot]

Hi @Kev-Roche,
some modules you are maintaining are being modified, check this out!