#10288 - Always load attachments

[g-Bergsma]

What & why

Fixes a defect in the Outlook/Graph email attachment retrieval logic where the hasAttachments property on a Graph message is used as a gate before fetching attachments. hasAttachments only reflects regular (non-inline) attachments, so messages containing only inline attachments (e.g. a screenshot pasted into the email body) report hasAttachments: false and are skipped entirely — even though the attachment is present and retrievable via $expand=attachments. This change removes the hasAttachments gate and instead always fetches attachments, applying inline/regular distinction afterward via isInline and contentId/cid: correlation.

Linked work

Fixes #10288

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)

• New unit tests in OutlookAPIHelperTests.Codeunit.al pass locally; full module test suite green.

Risk & compatibility

• Behavior change, not breaking change: Messages that previously had attachments silently skipped (inline-only case) will now have those attachments fetched and processed. Any downstream logic that assumed "no attachments" for these messages should be reviewed, but this is a bug fix restoring intended behavior, not an API surface change.
• Performance: Removing the hasAttachments gate means the attachment-fetch call ($expand=attachments or equivalent) now runs unconditionally, including for messages with genuinely zero attachments. This adds a Graph API call that was previously skipped in that case — likely negligible, but worth noting for high-volume inbound email scenarios.
• No data upgrade impact: This is a runtime logic change only; no schema, table, or field changes involved.
• No permission changes: Does not touch permission sets or object access.
• No breaking changes to public interfaces: Internal fix to the Outlook API helper codeunit's fetch logic; no changes to published/public methods, events, or extensibility points expected (confirm this holds once you see the actual diff).
• Telemetry: No new telemetry added.
• Follow-up work: None anticipated beyond this fix.

[github-actions]

Issue #10288 is not valid. Please make sure you link an issue that exists, is open and is approved.

[g-Bergsma]

@microsoft-github-policy-service agree company="Boltrics Professionals BV"