feat: Post Reporting - reportPost/reportComment analytics operations - EXO-89537

[akhanfir]

New dedicated listener on the generic social.activity.reported event, recording reportPost/reportComment operations with the reporter, the reason, the activity id and the owning space as dimensions.

Replaces #434 (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/content#902), against the eXip note and board task 89537 (US07). One 🟡 anchored inline, one 🟡 spec-deviation below.

---

🟡 Medium — spec deviation: compile-time dependency on social's new ActivityReport class

The spec sells the analytics integration as "a generic, string-keyed platform event … so no compile-time dependency exists between the two repositories in either direction" and "No release-order constraint between social and analytics". This listener is typed Listener<ActivityReport, Long> and imports io.meeds.social.report.model.ActivityReport, so analytics now requires a social artifact that carries that class — a real build-order/version constraint inside the FB line.

The code choice is defensible (analytics already builds on social's BOM, and a typed payload beats a Map), so the recommended fix is to accept it and resync the spec's Integrations/release-order claims, not to weaken the code. Flagged because the spec property is falsified either way (also raised on social#6039's summary).

---

Verified conform: dedicated listener class subscribing to the generic social.activity.reported event (not an extension of the typed activity-lifecycle listener), registered via @PostConstruct like its siblings; glue only — no business logic; operation split reportPost/reportComment per US07; userId = reporter identity id; reason recorded as a dimension; space resolved from the event's streamOwnerIdentityId, which social derives from the same getActivityStreamOwnerIdentity helper the creation guard uses — the single-resolution rule the spec asks for holds through the payload.

The PR is small and exactly the shape the spec's Integrations section describes.

---

Classification: N2 for this repo taken alone (new listener, no REST/DAO/schema/ACL surface — but a cross-repo seam); the delivery as a whole is N1 via social#6039 (max-severity aggregation applies to the feature/mips integration PR). Its approver must know that — no auto-merge on AI review alone.

🤖 Generated with Claude Code

[boubaker]

🟡 Medium — a comment report records no parent activity id, so US07's "Activity link" can't be built for comments

statisticData.setOperation(StringUtils.isBlank(report.getParentObjectId()) ? "reportPost" : "reportComment");
...
statisticData.addParameter("activityId", report.getActivityId()); // for a comment: the comment id — the parent id is never recorded

For a comment, report.getActivityId() is the comment id (comment<N>); report.getParentObjectId() holds the parent activity id but is only used to derive the operation. Board task 89537 lists "Activity link" among the chart dimensions — a comment's link needs the parent activity id (/activity?id=<parent>#comment-<id>), which this statistic cannot produce.

Fix: also record the parent, e.g. if (StringUtils.isNotBlank(report.getParentObjectId())) { statisticData.addParameter("parentActivityId", report.getParentObjectId()); }.

[akhanfir]

Fixed in f9a89d2: the listener now records parentActivityId (from the event's parentObjectId) whenever the target is a comment, so the "Activity link" dimension can build /activity?id=<parent>#comment-<id>.

[boubaker]

✅ Fixed in f9a89d2, verified: parentActivityId is recorded whenever parentObjectId is set, so a comment report now carries what the "Activity link" dimension needs.

[akhanfir]

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

• 🟡 Missing parent activity id for comment reports → ✅ fixed (parentActivityId parameter, thread).
• 🟡 Spec compile-dep wording → ⏳ accepted code-side as you recommend; tracked in the note 50533 resync listed on social#6039.

🤖 Generated with Claude Code

[boubaker]

AI review — Round #2 (final)

Re-review scoped to 296ec4e..f9a89d2 plus verification of Round #1 findings, at head f9a89d250d1090841afd091fa0135551ee9c69f8.

Round #1 finding	Status
🟡 Comment reports recorded no parent activity id (US07 "Activity link")	✅ Fixed — parentActivityId recorded whenever parentObjectId is set, with an in-place comment stating why.
🟡 Spec deviation: compile-time dependency on social's ActivityReport	➖ Accepted — the recommendation was to keep the typed payload and resync the spec's Integrations/release-order claims; the resync is tracked on social#6039's Round #2.

No new findings on the incremental diff. All findings from previous rounds are resolved — nothing outstanding from the AI review side on this PR.

Classification: N2 taken alone; the delivery as a whole is N1 via social#6039 — max-severity aggregation applies at the feature/mips integration PR, whose approver must know that.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 60%)

See analysis details on SonarQube Cloud