Users with hidden emails will see a noreply email on their profile

[n0toose]

Gitea, unlike GitLab and GitHub, would show the user's email address on their profile and gave some users something close to a heart attack.

This is obviously not healthy, so I built a new feature that would add an icon showing a padlock next to it, to show whether the email would be visible to other users or not. Such an indicator is important, because hiding your email address will mean that a "noreply@..." email address will be used for Git web operations, and this can mess the metadata of a repository if you just don't want your address to be shown on your profile, but still use it for commits.

If you're one of those people, it is very likely that you may not want that if you do livestreams, screencasts or just showing your screen to someone else somehow.

For that reason, the "noreply" email address will now be shown on the user's profile. This should show people that the noreply address will be used for every single Git-related thing that they do on the platform. It's probably less misleading this way, too.

Fixes https://codeberg.org/forgejo/forgejo/issues/1950

[n0toose]

Hopefully this is good enough to be merged as-is, but I'd like to ask for a more careful check just to be sure. :P

I am not sure if the tests are a bit redundant, especially because user2 should never be able to see the noreply address of user1, but I guess that checking doesn't hurt and could prevent future regressions.

[Freso]

The current tests below suggest the opposite of this, ie. that user still sees (.Contains) their own e‐mail (user1@example.com) and that they don’t see (.NotContains) their noreply e‐mail (user[12]@noreply.example.org)… which way is it supposed to be?

[n0toose]

ACK, this is a problem.

[n0toose]

Investigating possible logic error when ShowUserEmail is disabled in the config

[Freso]

Not sure if this investigating is still on-going, but the current/new comment still doesn’t seem to match what the tests are testing. (If it’s still being investigated, then disregard this comment!)

[techknowlogick]

Hey, thanks for this PR! I'm hesitant about the change to use the no-reply email as that's not an actual address that can receive email. I hear your point re: showing it to say "this is what will be used elsewhere in the system", but am unsure if the profile may be the appropriate place to give that disclaimer (GH has it elsewhere, such as next to the merge button saying "this merge commit will be associated with xyz@..."), or even on the settings page.
An alternative could be having the information on the page but requiring some interaction to show it. I've seen other sites hide it with dots and then have a tooltip letting the user "click to reveal" (screenshot below). The example below also has it so that the next click action is "click to copy" once it is shown.

[n0toose]

Hey, thanks for this PR! I'm hesitant about the change to use the no-reply email as that's not an actual address that can receive email. I hear your point re: showing it to say "this is what will be used elsewhere in the system", but am unsure if the profile may be the appropriate place to give that disclaimer

Yeah, I see what you mean. Using this project as an avenue to take something that has been already defined by another platform (i.e. GitHub) and trying to "make it better" through experiments may lead to some things that are not executed as well as they were before - I'm generally eager to alter the scope of my PR or throw away some work, given that I have something to work with (thanks for the feedback!), as long as every involved party / "stakeholder" ends up "further than they were yesterday".

One subset of the users we're talking about, that being "people sharing their screen when using the software", are experiencing this problem now and I'd find it optimal to fix it as fast as possible.

I could implement the "Click to reveal" feature, but I don't think I can implement it fast and right because I'm not an experienced. I would love to implement it later, but it might be best to settle for something fast for now. Here are two ideas:

• Show "Email hidden" instead of the placeholder email. Janky (as in, I would not be satisfied with it and I would definitely want to fix it later), but it would do the job and could be implemented fast enough to make it to the earliest next release possible. We could also include a "disclaimer" in the tooltip (I can do this without changing an existing string) and then go over the PR page later (I already did this with the Settings page here and here). I would prefer this option.
• Re-introduce the GitHub-like behavior of hiding the email field completely (like here: Fix profile page email display, respect settings #23747) while retaining parts of my feature that I spent a lot of time on in my first ever PR (Show visibility status of email in own profile #23900, but that makes me biased) - I think retaining the unlocked padlock icon (while leaving room for a "public" 🌐, as originally intended) would still be useful as the Gitea behavior of not showing the address in public when you choose to present it on your profile is still not 100% like GitHub's.

The logic (and the knowledge of the precise lines I would need to change) would mean that it would not be much work on my end and would get all of us a little bit further than before. What do you think I should do? @techknowlogick

[techknowlogick]

@n0toose my feelings are leaning towards starting with option 2 (I like your suggestion of keeping the open padlock showing the user that the email is public) and then possibly revisiting this with the "click to show" logic once more research could be done into it (vs doing it quickly and refactoring it as time goes on), as I suspect adding this type of component would add a general pattern that could be used elsewhere, and so more considerations may be needed.
Or, with option 1, there is also the option of not showing anything (ie, only modify the templates to remove showing anything on private email), but possibly still retaining the go code in the router so that when future changes happen, it's still there (this may amount to some code that isn't used still being run though, so there are of course tradeoffs with this alternative approach).

This, of course, isn't a blocking comment, just some suggestions on the approach, as really the only thing that I'd be hesitant about is showing the no-reply address. I am of course supportive of a change to the existing behaviour, as the case of leaking private information while screen sharing is definitely something I agree should be addressed :)

[n0toose]

my feelings are leaning towards starting with option 2 (I like your suggestion of keeping the open padlock showing the user that the email is public)

Thanks for the feedback! I will go for that option then (and deliberately leave the string for the private email in).

[n0toose]

@techknowlogick I revisited this PR and spent some time thinking about the way I approached it. I would like to justify my original unorthodox decision of showing the private email address better and ask whether it's a bad idea again. I'd like to try justifying showing the placeholder email to the user, and particularly on the profile, mostly philosophically.

deep breath

but am unsure if the profile may be the appropriate place to give that disclaimer

The reason why I chose to show the hidden email was because the hidden email will be associated with private commits. The private email is the user's assumed identity on the web UI, and it makes sense to me to use the profile to remind that fact instead of just before before they make a commit).

The user visits their own profile very often - it serves the function of creating an identity to show other people using your repositories, a bio or a profile README. It also consists of a Public Activity feed; I can put the Public Activity out there and associate it with my identity, or just hide it and use it as an own personal reference of my interactions with an instance ("The instance associates commits and comments with my identity."). It's also a place where I can reach the repositories I host on an instance.

The profile is not just a profile - where you get to define how others on the instance see you -, it's also a place shows you what you do on your instance and your "relationship" with it. How you tell an instance to identify you and how your commits will be shown to other people is a part of that relationship. Not sure if that made sense, but I see showing hidden email as similar as showing the Public Activity tab to the user, even if it's not hidden. The latter answers the question of "what commits and comments the instance associates with me", whereas the former says "what email address does the instance associate with me and use for commits".

(GH has it elsewhere, such as next to the merge button saying "this merge commit will be associated with xyz@..."), or even on the settings page.

I'm coming from the perspective of public instances, but in the context of a company, "Do I want the instance to associate me and my commits with a noreply address instead of my work address?" is the question that I'd want to ask using the UI.

I think that showing this next to the merge button makes sense, but I also think that not showing it earlier is a bit late.