Add an option to ignore (block) a user when reporting their events

[turt2live]

This is primarily useful if the content being reported really doesn't belong on your screen, and the room moderators are slow to react.

Ideally we'd use the word "block" instead of "ignore", but we call it "ignore user" everywhere else. See element-hq/element-meta#301 for further context on the word choice.

This change includes a minor refactor to the styles of labelled toggles (for reusability).

---

Here's what your changelog entry will look like:

✨ Features

• Add an option to ignore (block) a user when reporting their events (#8471).

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
27.5% Duplication

[t3chguy]

LGTM otherwise

[t3chguy]

not sure how I feel about the too - ignoreUser should be fine, no?

[turt2live]

it just didn't feel right to not acknowledge what the flag was doing. Given the context of the dialog, "ignore user" could mean "instead", "in addition to", or "don't file report". If we used the word "block" throughout the application instead, it'd be more than fine to leave it at blockUser.

[janogarcia]

@turt2live Toggles, in general, should be used for actions that take place immediately upon acting on them.

Thus, for this case (enabled on form submission), I'd suggest changing it to a checkbox with supporting text as in the mockup below.

[turt2live]

sounds good @janogarcia - should we also add a backlog item to use the same design for areas we already use a toggle switch? (mostly widget permissions stuff)

[janogarcia]

This will eventually be addressed as part of the the design systems improvements I'm working on, along with other changes. Already on my list but feel free to file an issue for it.

[turt2live]

@janogarcia new look:

let me know if further changes need to be made.

[janogarcia]

@turt2live There's no Netlify build available this time so, based on your screenshot:

• Use $primary-content color for the checkbox label (Ignore user)
• Use $secondary-content color for the checkbox supporting text and the modal body text (Reporting this message will send its…).

There's a lot more stuff that we could improve in this modal (copy, visual design), and modals in general, but I'm trying to keep the scope reasonable, as upcoming redesigns will address that.

[janogarcia]

So, there's a 99.9% probability that I'll forget to send my PR comments via the dedicated form:

Please refer to my previous comment
#8471 (comment)

[t3chguy]

@janogarcia

I can see the Netlify build from the last change 6 days ago

[janogarcia]

@t3chguy Ouch, thanks! I always check the Merge state section on the bottom and look for the Netlify link in the PR description. Could it be that the bot that adds the link to the description stopped working?

[janogarcia]

@t3chguy That said, I can't seem to find the deployment status on your second screenshot anywhere here.

[t3chguy]

Could it be that the bot that adds the link to the description stopped working?

We got rid of this and stated in the Element Web rooms, it was causing issues with editing PR descriptions due to overwriting them

[t3chguy]

@janogarcia do you not see this section at the bottom?

[janogarcia]

The deployment section seems to be missing on my end:

[t3chguy]

@janogarcia strange, can't find any github documentation on whether this section needs permission to show, the View deployment in the PR timeline should be accessible though, I can see it even in incognito

[turt2live]

@turt2live There's no Netlify build available this time so, based on your screenshot:

• Use $primary-content color for the checkbox label (Ignore user)
• Use $secondary-content color for the checkbox supporting text and the modal body text (Reporting this message will send its…).

There's a lot more stuff that we could improve in this modal (copy, visual design), and modals in general, but I'm trying to keep the scope reasonable, as upcoming redesigns will address that.

@janogarcia I can do this, however it'd be the only dialog in the app which ends up with this treatment. Can we keep it consistent for now and fix dialogs in a future PR? Alternatively, could blindly give all dialogs this treatment, though can't guarantee we have bandwidth to fix inconsistencies.

[janogarcia]

@turt2live Makes sense. Let's keep it consistently bad for now (better to have one rather than two suboptimal implementations 🙃). But I promise to come back to this at some point and end with all the awful debt once and for all. 🪄✨👹

[janogarcia]

the View deployment in the PR timeline should be accessible though, I can see it even in incognito

@t3chguy Yeah, that even remains visible.

[turt2live]

@janogarcia if I can get your review changed to an approval as a formality, it would be appreciated :)

will see what I can do to de-risk maintenance of dialogs outside of this issue (to make them consistently better instead of consistently bad)

[janogarcia]

@turt2live I re-requested a review for myself. Is that how it's supposed to work?

[turt2live]

Should be able to go to the Files Changed tab -> Review Changes dropdown -> Approve radio button -> Submit

(doesn't necessarily require a review request, but good to have one)

[turt2live]

oh, you did that. Ignore me - thanks!

[janogarcia]

Awesome. Thanks for the tip!