feat: "Report User" feature

[sandrade-dcl]

Pull Request Description

Fix #7299
Fix #7300
Fix #7479
Fix #7765
Fix #7766

What does this PR change?

It implements the Report User feature in the Explorer side:

• Addition of the new "Report" option in all user context menus: This option allow the player to report any user, being redirected to a Web Form where he will be able to send all the information to Decentraland.

• Modification of the current "Blocked Screen" modal: Now this modal shows more information about why the player has been banned (ban period and reason).

• New Ban Warning notification: The player will receive a notification informing about a possible banning if he continues violating the rules. Clicking on it, the user will be redirected to the support webpage.

• New Banned notification: The player will receive a notification informing about he was banned. Clicking on it, the "Blocked Screen" modal will be opened.

• New Un-Banned notification: The player will receive a notification informing about he was un-banned (after being banned). Clicking on it, nothing happens.

Test Steps

Report an user

1. Execute the build using these app args: --debug --report-user --dclenv zone.
2. Open any user context menu (from the friends list, from the passport or from a community member) and check that you see the new option "Report".
3. Click on the "Report" option and check that the new Reporting Web Form opens.

When your user is flagged

1. Execute the build using these app args: --debug --report-user --dclenv zone.
2. Once you are inside Decentraland, got o https://tools.decentraland.systems/user_moderation to send a ban warning to your address.
3. Once he send you the warning, check that a new notification appears telling you that you have been flagged.
4. Click in the notification and you should be redirected to the support webpage.

When your user is banned

1. Execute the build using these app args: --debug --report-user --dclenv zone.
2. Once you are inside Decentraland, go to https://tools.decentraland.systems/user_moderation to ban your address.
3. Once he marks you as banned, check that a new notification appears telling you that you have been banned.
4. Click in the notification and the "Blocked Screen" modal should be opened.
5. Exit the app and enter again. Check that the "Blocked Screen" modal appears right after you log in and it doesn't allow you to continue.

Check that the feature flag is working properly

1. Execute the build without using the app arg --report-user.
2. Check that the new "Report" option doesn't appear in any user context menu.

Code Review Reference

Please review our Code Review Standards before submitting.

[github-actions]

Windows and Mac build successful in Unity Cloud! You can find a link to the downloadable artifact below.

Name	Link
Commit	85b9e50
Logs	https://github.com/decentraland/unity-explorer/actions/runs/23544442682
Download Windows	https://github.com/decentraland/unity-explorer/suites/61969380422/artifacts/6103313251
Download Windows S3	https://explorer-artifacts.decentraland.org/@dcl/unity-explorer/branch/feat/add-report-user-option-in-user-context-menus/pr-20231-85b9e50/Decentraland_windows64.zip
Download Mac	https://github.com/decentraland/unity-explorer/suites/61969380422/artifacts/6103083123
Download Mac S3	https://explorer-artifacts.decentraland.org/@dcl/unity-explorer/branch/feat/add-report-user-option-in-user-context-menus/pr-20231-85b9e50/Decentraland_macos.zip
Built on	2026-03-25T14:28:57Z

[decentraland-bot]

Re-review — "Report User" feature

Thanks for the fixes, Santiago! Here's my updated assessment:

Issue 1 — Duplicated report-user logic ✅ Fixed

The confirmation → fetch self profile → open URL pattern is now properly extracted into ReportUserHelper.ShowConfirmAndReportAsync. All 5 call sites use this shared helper. Great job.

Issue 3 — MembersListView.contextMenuSettings encapsulation ✅ Mostly fixed

MembersListView now exposes only what's needed via public Sprite ReportSprite => contextMenuSettings.ReportSprite; — that's the right approach.

However, CommunitiesBrowserView still declares the field as:

[SerializeField] public CommunityMemberListContextMenuConfiguration contextMenuSettings = null!;

and the controller accesses it as view.contextMenuSettings.ReportSprite. Ideally this would follow the same pattern as MembersListView (expose a property, keep the field private). Minor nit — not blocking.

Issue 2 — BannedNotificationHandler unsubscribe — Acknowledged as intentional ✅

---

Remaining suggestions from the first review (still applicable):

🟡 Hardcoded #FF2D55 parsed at runtime — This color is now parsed via ColorUtility.TryParseHtmlString in even more places (at least 6 call sites). Consider a shared constant:

private static readonly Color DangerRed = ColorUtility.TryParseHtmlString("#FF2D55", out var c) ? c : Color.red;

🟡 == default(Color) in ButtonWithDelegateContextMenuControlSettings — default(Color) is transparent black (0,0,0,0), which is a valid color. If someone intentionally passes transparent black, they'd get the default white/FCFCFC instead. A nullable Color? parameter would be more robust, but low risk in practice.

🟡 DOFade in AnimatePersistentNotificationCanvasGroupAsync finally block — The fade-out in the finally block runs without a cancellation token:

finally
{
    notificationCanvasGroup.interactable = false;
    notificationCanvasGroup.blocksRaycasts = false;
    await notificationCanvasGroup.DOFade(0, ANIMATION_DURATION).ToUniTask();
}

If the object is destroyed during the fade-out, this could throw. Consider adding a try/catch around it or passing a linked token.

---

CI Status

Tests (playmode + editmode) and builds are still pending on the latest push. No new tests added for the report-user flow.

Verdict

The two flagged issues are resolved. The remaining items are suggestions, not blockers. Looks good overall — solid refactoring with the ReportUserHelper extraction. 👍

[dalkia]

Looks good to me! Great work

Leaving some comments for consideration, non-blockers

[m3taphysics]

@claude re-review

[claude]

Claude finished @m3taphysics's task in 2m 38s —— View job

---

PR Re-Review — feat: "Report User" feature

• Gather context from previous review comments
• Read current state of key files
• Check if remaining issues have been addressed
• Post re-review summary

---

Previously Raised Issues — Status

Issue	File	Status
DRY violation — duplicated report-user logic across 5+ controllers	Multiple	✅ Fixed — extracted into ReportUserHelper.ShowConfirmAndReportAsync
Missing exception handling in UniTaskVoid	BannedNotificationHandler.cs	✅ Fixed
Dangling block with out-of-scope ct	BannedNotificationHandler.cs	✅ Fixed
Missing exception handling in ReportUser flows	All 5 controllers	✅ Fixed — ReportUserHelper has proper try/catch internally
MembersListView.contextMenuSettings changed to public	MembersListView.cs	✅ Fixed — field is private, exposes public Sprite ReportSprite property (line 67)
CommunitiesBrowserView.contextMenuSettings public	CommunitiesBrowserView.cs	✅ Fixed — field is private (line 58), exposes public Sprite ReportSprite property (line 61)

---

Non-Blocking Suggestions (acknowledged from previous reviews, still applicable)

These were flagged by the previous review as 🟡 suggestions, not blocking:

• Hardcoded #FF2D55 parsed at runtime — ColorUtility.TryParseHtmlString is called in MembersListView.cs:120, CommunityRequestsReceivedGroupView.cs:67, and other locations. Not a blocker but a shared constant would be cleaner.
• DOFade in finally without cancellation token — AnimatePersistentNotificationCanvasGroupAsync (line 418) and AnimateNotificationCanvasGroupAsync (line 400) in NewNotificationController.cs both run a fade-out without a cancellation token in their finally blocks. Consistent pattern, acknowledged as intentional.

---

No new blocking issues found.

REVIEW_RESULT: PASS ✅

[sandrade-dcl]

@claude re-review

[claude]

Claude finished @sandrade-dcl's task in 4m 17s —— View job

---

PR Re-Review — feat: "Report User" feature

• Gather context from previous review comments
• Read current state of key changed files
• Check if remaining issues have been addressed
• Post re-review summary

---

Previously Raised Issues — Status

Issue	File	Status
Hardcoded #FF2D55 parsed at runtime in 5+ locations	Multiple	✅ Fixed — ContextMenuColors.DESTRUCTIVE_ACTION constant used across all call sites
DOFade in finally without cancellation token	NewNotificationController.cs	✅ Fixed — cancellationToken: cts.Token added; safe because cts field is re-assigned before the async continuation runs
CommunitiesBrowserView.contextMenuSettings public	CommunitiesBrowserView.cs:58	✅ Fixed — field is [SerializeField] private, exposes public Sprite ReportSprite property (line 61)
All exception handling issues	All controllers	✅ Fixed (from prior reviews)
DRY violation — duplicated report-user logic	Multiple	✅ Fixed — ReportUserHelper.ShowConfirmAndReportAsync used everywhere

No new blocking issues found in the two latest commits (fb900d30, 76c15a0e).

---

REVIEW_RESULT: PASS ✅

[sandrade-dcl]

@claude re-review

[claude]

Claude finished @sandrade-dcl's task in 5m 6s —— View job

---

PR Re-Review — feat: "Report User" feature

• Gather context from previous review comments
• Read current state of key changed files
• Check if remaining issues have been addressed
• Post re-review summary

---

New Commits Since Last PASS

Commit	Change
eb62a264	BannedUsers URL corrected — removed /moderation path segment ✅
f30617a6	Merge from dev — no feature-file changes ✅

---

Previously Raised Issues — Status

All issues from prior reviews remain resolved. No regressions introduced by the merge.

---

New Blocking Issue Found

NewNotificationController.cs — DOFade in finally can permanently disable notifications ❌

The cancellationToken: cts.Token added in 76c15a0e works correctly for a single close-click (by the time finally runs, StopAnimation() has already assigned a fresh cts). However, if the user clicks close twice within the 0.5 s fade-out — easily reproducible on persistent ban notifications, where the close button remains active during the animation — the second click cancels the new token mid-DOFade, throwing an unhandled OperationCanceledException inside the finally block. This propagates up through DisplayNewNotificationAsync (a UniTaskVoid.Forget()), leaving isDisplaying = true permanently so no further notifications display in the session.

Affected lines: 400 and 418.

Fix: use .SuppressCancellationThrow() on the DOFade awaitable in both finally blocks so the fade always completes or is silently cancelled without propagating. See inline comments for exact suggestions. Fix this →

---

REVIEW_RESULT: FAIL ❌

[sandrade-dcl]

@claude re-review

[claude]

Claude finished @sandrade-dcl's task in 44s —— View job

---

PR Re-Review — feat: "Report User" feature

• Gather context from previous review comments
• Read current state of NewNotificationController.cs
• Check if remaining issues have been addressed
• Post re-review summary

---

Previously Raised Issues — Status

Issue	File	Status
DOFade in finally can throw OperationCanceledException, permanently leaving isDisplaying = true	NewNotificationController.cs:400	✅ Fixed — .SuppressCancellationThrow() added to both finally blocks
DOFade in finally — same issue in AnimatePersistentNotificationCanvasGroupAsync	NewNotificationController.cs:418	✅ Fixed — .SuppressCancellationThrow() added
All prior issues from earlier reviews	Multiple files	✅ Remain resolved

---

All previously raised issues have been addressed. No new blocking issues found.

REVIEW_RESULT: PASS ✅

[balducciv]

Test in Zone passed

Report a user

• can see the 'Report User' button
• can access the form
• can submit the form
• When the build is executed without the args --report-user the Report User option does not show.

Windows:

test user: 0x2160d7753c1653ea5b7fbb5e523259d0c86d0a79 (metamask)
reported user: 0x55c54fc1865afe5b0cf15703f04b63a3488695c0 (metamask)

25.03.2026_15.35.09_REC.report.user.windows.metamask.mp4

Fill in the form with users:
email + OTP ✅
google account ✅
metamask ✅

26.03.2026_11.31.49_REC.-.email.otp.report.submitted.mp4

Mac

test user: 0x2160d7753c1653ea5b7fbb5e523259d0c86d0a79 (metamask)
reported user: 0xcca24140cfbdbc2f93bb8b471f67f7c8bea06804 (email + otp)

25.03.2026_15.18.04_REC.report.a.user.env.zone.Mac.mp4

Flag/Warn a user ✅

• Flagged/warn message displays correctly in zone env
• User can click the message and is directed to the support page

Windows

wallet: 0x33f2d6bf2f4a4d9ab9b6fc1d6bf0060043115b30 (metamask)

• Screen recording shows both warn and ban work as expected.

25.03.2026_15.45.44_REC.warn.and.ban.user.mp4

• When user re enters the explorer, the banned message displays

25.03.2026_15.48.45_REC.-.re.enter.client.ban.mp4

Ban a user ✅

• Banned message displays correctly in zone env
• User can click the message and is directed to the support page
• The user sees a modal with the option to click Exit or Support

Windows

wallet: 0xcca24140cfbdbc2f93bb8b471f67f7c8bea06804 (email + otp)

Mac

user warned and banned:

25.03.2026_15.57.24_REC.warn.and.ban.mp4

[balducciv]

Test in Org passed

PR reviewed and approved by QA on both platforms following instructions. ✅
Smoke test for this PR was performed on Windows and Mac to verify that the normal flow is working as expected ✅

Report a user

• can see the 'Report User' button
• can access the form
• can submit the form
• When the build is executed without the args --report-user the Report User option does not show.

Windows: user: 0x5bfc3c2e26af97a0d3ebf5a23b76994b22d8d65e

reporting user: 0x5bfc3c2e26af97a0d3ebf5a23b76994b22d8d65e (metamask)
reported user: 0x265ee92c459e4104051e338539bf2b85ee8feb41 (metamask)

ORG.-.can.see.Report.button.can.see.the.form.mp4

Mac: test user: 0x265ee92c459e4104051e338539bf2b85ee8feb41

reporting user: 0x265ee92c459e4104051e338539bf2b85ee8feb41 (metamask)
reported user: 0x5bfc3c2e26af97a0d3ebf5a23b76994b22d8d65e (metamask)

25.03.2026_17.12.34_REC.-.ORG.-.can.see.report.user.form.mp4

Fill in the form with users:
email + OTP ✅
google account ✅
metamask ✅

26.03.2026_11.45.52_REC.-.submit.report.google.mp4

metamask

26.03.2026_11.54.58_REC.metamask.2.mp4

Warn/Flag a user

• Flagged/warn message displays correctly in org env
• User can click the message and is directed to the support page

Ban a user

• Banned message displays correctly in org
• User can click the message and is directed to the support page
• The user sees a modal with the option to click Exit or Support

Mac:

25.03.2026_17.22.21_REC.warn.and.ban.mp4

Windows:

warn.and.ban.user.-.org.-.windows.mp4

[balducciv]

Both the explorer and the web parts have been thoroughly tested and passed.
The only remaining issue is that the production evidence files are private; Mauro is addressing this, and it does not affect the end-to-end functionality.