github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 10:39:38 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Option to hide users' email address #183

New Issue
Closed
opened 2025-11-02 03:12:57 -06:00 by GiteaMirror · 12 comments
GiteaMirror commented 2025-11-02 03:12:57 -06:00
Owner
Copy Link

Originally created by @derSuessmann on GitHub (Dec 30, 2016).

  • Gitea version (or commit ref): 1.0

Description

Currently, Gitea displays the users' email address on the explore users and users' profile pages. The exist two issues in Gogs #3358 and #3381. In addtion I would like to state my case:

In some cases the users' email address should be protected. This may be to avoid the harvesting of email addresses for UCE or another reason. In my context, running a Gitea server in a school's network, I am even more concerned about stalking.

Generally there seem to be two options:

  1. Add a site wide configuration option to hide the users' email address.
  2. Add a user setting for opting in.

The first option may be more attractive for schools. The second targets a broader audience. Maybe both should be implemented.
...

Originally created by @derSuessmann on GitHub (Dec 30, 2016). - Gitea version (or commit ref): 1.0 ## Description Currently, Gitea displays the users' email address on the explore users and users' profile pages. The exist two issues in Gogs [#3358](https://github.com/gogits/gogs/issues/3358) and [#3381](https://github.com/gogits/gogs/issues/3381). In addtion I would like to state my case: In some cases the users' email address should be protected. This may be to avoid the harvesting of email addresses for UCE or another reason. In my context, running a Gitea server in a school's network, I am even more concerned about stalking. Generally there seem to be two options: 1. Add a site wide configuration option to hide the users' email address. 2. Add a user setting for opting in. The first option may be more attractive for schools. The second targets a broader audience. Maybe both should be implemented. ...
GiteaMirror added the topic/uitype/enhancement labels 2025-11-02 03:12:57 -06:00
GiteaMirror commented 2025-11-02 03:12:58 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 30, 2016):

There is a PR https://github.com/go-gitea/gitea/pull/336 to resolve this, please discuss there.

@lunny commented on GitHub (Dec 30, 2016): There is a PR https://github.com/go-gitea/gitea/pull/336 to resolve this, please discuss there.
GiteaMirror commented 2025-11-02 03:12:58 -06:00
Author
Owner
Copy Link

@derSuessmann commented on GitHub (Dec 30, 2016):

I am ok with continuing the discussion over there, but I think it is the wrong way around. A newcomer will normally search the issues and not the pull requests. (That was exactly what I did and I did not find that someone was already working on my issue. The discussion on Gitter helped me a lot, so I decided to open this issue)
The issue should be discussed as an issue and the discussion on the pull request should be about the proposed solution.
This issue should stay open until there is a solution (like PR #336 has been merged). This would also be the right way according to the Contribution Guidelines.

@derSuessmann commented on GitHub (Dec 30, 2016): I am ok with continuing the discussion over there, but I think it is the wrong way around. A newcomer will normally search the issues and not the pull requests. (That was exactly what I did and I did not find that someone was already working on my issue. The discussion on Gitter helped me a lot, so I decided to open this issue) The issue should be discussed as an issue and the discussion on the pull request should be about the proposed solution. This issue should stay open until there is a solution (like PR #336 has been merged). This would also be the right way according to the [Contribution Guidelines](https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md).
GiteaMirror commented 2025-11-02 03:12:58 -06:00
Author
Owner
Copy Link

@bkcsoft commented on GitHub (Dec 30, 2016):

@lunny this extends on #336, I'd like to keep this one open until it's all resolved :)

@bkcsoft commented on GitHub (Dec 30, 2016): @lunny this extends on #336, I'd like to keep this one open until it's all resolved :)
GiteaMirror commented 2025-11-02 03:12:58 -06:00
Author
Owner
Copy Link

@bkcsoft commented on GitHub (Dec 30, 2016):

@derSuessmann My proposal is this:

  • Have user-setting for displaying ones email. Migration should set this to true for backwards compatability.
  • Have a site-wide option DEFAULT_SHOW_EMAIL=boolean which sets the default for newly created users, should also be set to true by default for the same reason

Thoughts?

@bkcsoft commented on GitHub (Dec 30, 2016): @derSuessmann My proposal is this: - Have user-setting for displaying ones email. Migration should set this to `true` for backwards compatability. - Have a site-wide option `DEFAULT_SHOW_EMAIL=boolean` which sets the default for newly created users, should also be set to `true` by default for the same reason Thoughts?
GiteaMirror commented 2025-11-02 03:12:58 -06:00
Author
Owner
Copy Link

@bkcsoft commented on GitHub (Dec 30, 2016):

DEFAULT_SHOW_EMAIL should be configurable from /install just like Offline-Mode etc...

@bkcsoft commented on GitHub (Dec 30, 2016): `DEFAULT_SHOW_EMAIL` should be configurable from `/install` just like Offline-Mode etc...
GiteaMirror commented 2025-11-02 03:12:58 -06:00
Author
Owner
Copy Link

@derSuessmann commented on GitHub (Dec 31, 2016):

I agree, but would prefer DEFAULT_KEEP_EMAIL_PRIVATE as it has a positive logic and includes the hiding of the real email address in git log. My proposal for a change is:

User requirement
The user of Gitea may want to keep his email address private from other users to prevent email harvesting for UCE or stalking.

Change requirements

  • The change must not change the behavior of an updated installation (REQ1). If an existing installation is updated with the changed version, the email address of all users will still be visible until they change their settings.
  • The change must enable a user of Gitea to decide whether his email address will be shown (REQ2). This should be implemented as a user setting in the Profile section below the Email address. The option should be called "Keep Email Private" in the dialog and KeepEmailPrivate as a field in the user struct.
  • The change must introduce a new site-wide option DEFAULT_KEEP_EMAIL_PRIVATE (REQ3). If the option is true all new user will get KeepEmailPrivate set to true, otherwise false.
  • The email address must not be shown to other users on the explore/users and users profile pages if KeepEmailPrivate is true (REQ4).
  • The email address should be replaced with a concatenation of the user name in lower case, "@noreply" and the domain name from the settings (<LowerName>@noreply.<DOMAIN>) in the git log, if KeepEmailPrivate is true (REQ5).
  • An ApiFormat() call should return the same email address as shown in the git log (REQ6). This requirement is linked to (REQ5).
  • The value of DEFAULT_KEEP_EMAIL_PRIVATE should be set on the install page (REQ6).
  • The change does not differentiate between what is visible to an administrator and a normal user on the explore/users and users' profile pages.
@derSuessmann commented on GitHub (Dec 31, 2016): I agree, but would prefer DEFAULT_KEEP_EMAIL_PRIVATE as it has a positive logic and includes the hiding of the real email address in git log. My proposal for a change is: **User requirement** The user of Gitea may want to keep his email address private from other users to prevent email harvesting for UCE or stalking. **Change requirements** - The change _must not_ change the behavior of an updated installation (REQ1). If an existing installation is updated with the changed version, the email address of all users will still be visible until they change their settings. - The change _must_ enable a user of Gitea to decide whether his email address will be shown (REQ2). This _should_ be implemented as a user setting in the Profile section below the Email address. The option _should_ be called "Keep Email Private" in the dialog and `KeepEmailPrivate` as a field in the user struct. - The change _must_ introduce a new site-wide option `DEFAULT_KEEP_EMAIL_PRIVATE` (REQ3). If the option is true all new user will get `KeepEmailPrivate` set to true, otherwise false. - The email address _must not_ be shown to other users on the explore/users and users profile pages if `KeepEmailPrivate` is true (REQ4). - The email address _should_ be replaced with a concatenation of the user name in lower case, `"@noreply"` and the domain name from the settings (`<LowerName>@noreply.<DOMAIN>`) in the git log, if `KeepEmailPrivate` is true (REQ5). - An `ApiFormat()` call _should_ return the same email address as shown in the git log (REQ6). This requirement is linked to (REQ5). - The value of `DEFAULT_KEEP_EMAIL_PRIVATE` _should_ be set on the install page (REQ6). - The change _does not_ differentiate between what is visible to an administrator and a normal user on the explore/users and users' profile pages.
GiteaMirror commented 2025-11-02 03:12:59 -06:00
Author
Owner
Copy Link

@derSuessmann commented on GitHub (Dec 31, 2016):

All requirements can be fulfilled. I have just pushed the code to the keep-email-private branch in my fork. First tests were successful.

@derSuessmann commented on GitHub (Dec 31, 2016): All requirements can be fulfilled. I have just pushed the code to the [keep-email-private branch](https://github.com/derSuessmann/gitea/tree/keep-email-private) in my fork. First tests were successful.
GiteaMirror commented 2025-11-02 03:12:59 -06:00
Author
Owner
Copy Link

@bkcsoft commented on GitHub (Jan 3, 2017):

@derSuessmann I like it, please make a PR 😉 Only think I can say up front is WRT REQ5, that would be <LowerName>-noreply@<Domain> otherwise you'll end up in someones spam-filter 😄

@bkcsoft commented on GitHub (Jan 3, 2017): @derSuessmann I like it, please make a PR 😉 Only think I can say up front is WRT REQ5, that would be `<LowerName>-noreply@<Domain>` otherwise you'll end up in someones spam-filter 😄
GiteaMirror commented 2025-11-02 03:12:59 -06:00
Author
Owner
Copy Link

@derSuessmann commented on GitHub (Jan 3, 2017):

I think the email address should be a special domain like noreply.<domain>. The reason is simply I do want my email server get all the mail for invalid users. Perhaps it should even be users.noreply.<domain> to keep it more Github-like. This will help users already using Github. As nobody should use this email address for sending an email I think it is quite OK if it may end up in a spam filter.

@derSuessmann commented on GitHub (Jan 3, 2017): I think the email address should be a special domain like `noreply.<domain>`. The reason is simply I do want my email server get all the mail for invalid users. Perhaps it should even be `users.noreply.<domain>` to keep it more Github-like. This will help users already using Github. As nobody should use this email address for sending an email I think it is quite OK if it may end up in a spam filter.
GiteaMirror commented 2025-11-02 03:12:59 -06:00
Author
Owner
Copy Link

@derSuessmann commented on GitHub (Jan 3, 2017):

Finally, I came to the conclusion that it would be best, if the site administrator could configure the domain of the email address for the "Keep Email Private" users in git log.

  • The email address should be replaced with a concatenation of the user name in lower case, "@" and a domain name from the settings (<LowerName>@<NO_REPLY_ADDRESS>) in the git log, if KeepEmailPrivate is true (REQ5-NEW).
  • There should be a site-wide setting for the NO_REPLY_ADDRESS (REQ7).
@derSuessmann commented on GitHub (Jan 3, 2017): Finally, I came to the conclusion that it would be best, if the site administrator could configure the domain of the email address for the "Keep Email Private" users in git log. - The email address should be replaced with a concatenation of the user name in lower case, "@" and a domain name from the settings (`<LowerName>@<NO_REPLY_ADDRESS>`) in the git log, if `KeepEmailPrivate` is true (REQ5-NEW). - There _should_ be a site-wide setting for the `NO_REPLY_ADDRESS` (REQ7).
GiteaMirror commented 2025-11-02 03:13:00 -06:00
Author
Owner
Copy Link

@bkcsoft commented on GitHub (Jan 6, 2017):

right, that makes even more sense. Now for git-log... we can't do that without rewriting the git history, which is completely out of the question for a ton of reasons 😒

@bkcsoft commented on GitHub (Jan 6, 2017): right, that makes even more sense. Now for git-log... we can't do that without rewriting the git history, which is completely out of the question for a ton of reasons 😒
GiteaMirror commented 2025-11-02 03:13:00 -06:00
Author
Owner
Copy Link

@derSuessmann commented on GitHub (Jan 6, 2017):

Perhaps, I should be clearer:

  • The email address should be replaced with a concatenation of the user name in lower case, "@" and a domain name from the settings (<LowerName>@<NO_REPLY_ADDRESS>) in the git log for new commits by the user, if KeepEmailPrivate is true (REQ5-NEW).
@derSuessmann commented on GitHub (Jan 6, 2017): Perhaps, I should be clearer: - The email address should be replaced with a concatenation of the user name in lower case, "@" and a domain name from the settings (`<LowerName>@<NO_REPLY_ADDRESS>`) in the git log for _new commits by the user_, if `KeepEmailPrivate` is true (REQ5-NEW).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label topic/ui type/enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#183
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?