feat: Post Reporting - Report entry in the news article view EXO-89471

[akhanfir]

Adds the Report entry to the news article detail menu, driven by the activity's server-derived canReport/hasReported flags threaded down from the hosting activity view, with live state sync after reporting. Content edits (title/body) reset existing reports; posting/publishing/categories updates keep them active.

Note for PO/testers: the Report entry appears only when the article view is hosted by an activity (opened from the stream) — an article reached outside the stream (news app, direct link) offers no Report entry, since the eligibility flags travel with the activity payload.

Replaces #895 (retargeted from feature/mips to feature/devx).

[boubaker]

AI review — Round #1

Reviewed as part of the Post Reporting delivery (with Meeds-io/social#6039 and Meeds-io/analytics#435). No blocking finding on this PR — one observation and one nit, anchored inline where possible.

---

🟢 Observation — articles are reportable only from the stream-hosted view, by construction

The activity prop (and with it canReport) is threaded only through ExoNewsDetailsActivity, which content registers as an activity-stream extension — so the Report entry appears only when the article is opened from the stream page, where social's ActivityReportDrawer (an activity-stream-drawers extension) is mounted and the activity-report-drawer-open event has a listener. On the standalone news detail page the prop is null, the entry is hidden, and there is no dead click — coherent. Worth one line to the PO though: an article reached outside the stream (news app, direct link) offers no Report entry, while the same article in the stream does.

Also: this PR is part of the delivery but absent from the spec's Repositories touched table, and the spec's Functional divergences confirmed still says content-backed activities are excluded from reporting — the resync is tracked on social#6039's summary.

---

Verified conform: the explicit stale-flip fires only on CONTENT_AND_TITLE updates (posting/publishing/categories don't reset), with a test pinning each direction (testContentEditMarksArticleReportsStale / testNonContentEditKeepsArticleReportsActive) — this is the precise content-change gating the social-side lifecycle listener should also adopt (see the 🟠 on social#6039); the in-place comment explains why the explicit delegation exists (article edits never broadcast the activity update lifecycle); menu entry driven by the server-derived flags, never re-derived client-side; live sync via the activity-reported document event with the comment/post discrimination handled.

---

Classification: N3 taken alone (additive UI + a service-to-service delegation, no REST/DAO/schema/ACL surface); the delivery as a whole is N1 via social#6039 — max-severity aggregation applies at the feature/mips integration PR.

🤖 Generated with Claude Code

[boubaker]

🟢 Nit — pre-existing bug one line above: beforeDestroy re-registers the extension listener instead of removing it

beforeDestroy() {
  document.addEventListener(`extension-${this.extensionApp}-${this.extensionType}-updated`, this.refreshExtensions); // pre-existing: should be removeEventListener
  document.removeEventListener('activity-reported', this.handleActivityReported); // your line is correct
}

Your new listener is cleaned up correctly, but the pre-existing line above it adds the extension-updated listener on destroy (leaking one registration per component lifecycle). Since this block is being touched, worth fixing to removeEventListener in the same PR.

[akhanfir]

Fixed in a0ec6bd (same amended commit): the pre-existing addEventListener in beforeDestroy is now removeEventListener, and the commit message records the leak fix.

[boubaker]

✅ Fixed in a0ec6bd, verified: beforeDestroy now removes the extension-updated listener, and the report flags moved to native booleans consistently with social's serialization change.

[akhanfir]

Review fixes — addressed at a0ec6bd (amended into the single delivery commit)

• 🟢 beforeDestroy pre-existing listener leak → ✅ fixed (thread).
• 🟢 Stream-hosted-only observation → ✅ the PR description now carries the note for the PO/testers.
• Flag consumption aligned with social#6039's boolean serialization (truthy checks).

🤖 Generated with Claude Code

[boubaker]

AI review — Round #2 (final)

Re-review scoped to 4a2e9e5..a0ec6bd plus verification of Round #1 items, at head a0ec6bd778b3ff73847970b7fdb85d432c865963.

Round #1 item	Status
🟢 Pre-existing beforeDestroy re-registered the extension listener	✅ Fixed — now removeEventListener.
🟢 Observation: articles reportable only from the stream-hosted view	➖ Informational — no change requested; worth a line to the PO at Mips validation.

The incremental diff also aligns the report flags on the native booleans social#6039 now serializes — consistent, no new findings. Nothing outstanding from the AI review side on this PR.

Classification: N3 taken alone; the delivery as a whole is N1 via social#6039 — max-severity aggregation applies at the feature/mips integration PR.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
87.5% Coverage on New Code
6.1% Duplication on New Code

See analysis details on SonarQube Cloud