The database schema changes and admin part of this have been implemented in #2024. I've used the word “unsettling” instead of the abbreviation NSFW in the code and the admin interface.

What's left to do:

• Enable users to mark their profiles as NSFW. I suggest renaming the existing /~/edit/privacy page to /~/edit/visibility and putting the new checkbox there.
• Hide profiles marked as unsettling, unless the viewer has opted in to see them.

I am looking to contribute to the repository for the first time. Does this issue still need to be worked on?

Yes.

I've looked into this task more and am interested in working on it. I understand where users should be able to set their profile as "unsettling", but where users be able to select to opt in to viewing "unsettling" profiles?

On every page which would show an unsettling profile if the user had already opted-in to see them.

There should probably be two buttons: one to deactivate the NSFW filter for only one page view, and another one to deactivate it permanently (by setting a cookie).

Would something like what is shown in the video work? (this is just a proof of concept) If the user opts in to always seeing unsettling profiles then they will not be shown this prompt whenever they visit an unsettling profile.

It's a good start.

• The profile should be completely hidden as long as the visitor hasn't opted-in to see it, including and especially the avatar.
• I think the warning needs to be more detailed and complete. Something like “This page is marked as containing potentially upsetting or embarrassing content. Viewing it is particularly unrecommended if someone else can see your screen or if you're a minor.”
• The first button should be labelled “View this page” instead of “View unsettling profile”.
• The text of the second button should end with “on this computer” or “in this browser” to clarify the scope of the opt-in, and it should use the word “pages” instead of “profiles” to be more general.
• The two buttons should probably have the btn-warning class instead of btn-primary.
• Once the visitor has opted-in to see the marked profile, there should be a short message (class alert-info or alert-warning) at the top of the page indicating that it's marked as unsettling. The alert should contain a button to cancel the opt-in.

If the profile (including the avatar) should be completely hidden, how should the profile appear in search results and other places where users can access profiles? There are lots of places on the site where you can see a user's avatar before clicking on their entire profile.

In the exploration pages and search results we should probably blur the NSFW profiles. (I mean blur the whole box, not just the avatar.)

Do want to blur unsettling profiles in every single place they are used on the site? As I am looking through the code I am noticing a lot of spots where avatar_img(...) is used and then the username is listed. I would have to include a lot of checks to make sure both the username and avatar are blurred since the username is often listed separately outside of the avatar_img() macro. I am just trying to avoid making many unnecessary changes. Right now I am blurring unsettling profiles on the exploration pages and search results.

Blurring only in the exploration and search pages is fine. I'll add blurs elsewhere later if I think they're necessary.

Ok, any advice on how to go about testing? I have looked at some of the other test files but don't see any files where I think these tests may fit in or any other tests that test a similar type of functionality that I could use as a reference.

I would probably put the tests in the test_settings.py file alongside the existing tests for the privacy settings.

I guess the things to check are:

• the user can mark and unmark their profile as unsettling
• when the profile is marked as unsettling, trying to view it shows a confirmation prompt, and viewing a relevant exploration page shows it blurred

Ok. Doesn't the test_participant_can_modify_privacy_settings already check that a user can mark and unmark their profile as unsettling?

No, because it's not a privacy setting.

Right now test_participant_can_modify_privacy_settings loops through all the constants in PRIVACY_FIELDS and checks if each can be selected. I added is_unsettling to PRIVACY_FIELDS so it appears as an option to check on /~/edit/privacy. Should an is_unsettling constant be added somewhere else since it isn't a privacy setting? And do you still want the option for users to mark their profile as unsettling to appear with the other PRIVACY_FIELDS on /~/edit/privacy (or /~/edit/visibility/ as you mentioned the name should be changed)?

If is_unsettling is added to PRIVACY_FIELDS, then that constant should be renamed PROFILE_VISIBILITY_FIELDS, and the test class and methods should also be renamed.

I went through and changed the naming from privacy to visibility for everything that was related to the /~/edit/privacy page (now /~/edit/visibility). I think I have all the functionality implemented to the best of my knowledge (though there is probably a couple of things I could clean up or add/change) Can teams be marked as unsettling? - right now I have accounted for that.

Yes, it should be possible to mark a team as unsettling. Ideally the other team members would be informed of the change, but you don't have to try to implement that, it's a larger issue (#134).

Ok, I went and submitted a PR.