Private / hidden issues #6991

Closed
opened 2025-11-02 07:13:00 -06:00 by GiteaMirror · 2 comments
Owner

Originally created by @fnetX on GitHub (Mar 11, 2021).

Feature Request

Description

Currently and on most git hosting providers, issues are always public. While this is of course desired default behaviour, I propose to add an option for internal or private issues (and may be even pull / merge requests) for the following reasons:

  • Security Reports: There is no standardized way to send security reports to developers or maintainers of the software Usually, there's a hint that they should be reported via E-Mail. But this way, they fall out of the default bug tracking and must be discussed elsewhere.
  • Internal discussion: Also especially useful for handling vulnerabilities, discussing fixes and preparing pull requests that are only visible to the public once merged, it might also be a good idea to allow some discussion between maintainers privately.
  • Sensitive information: Sometimes, debugging an issue requires disclosing logs with sensitive information or providing access to test systems etc. They are usually sent via external tools e.g. email. It would be a cool feature to keep this in the issue tracker but allow only for limited access to the maintainers and the reporter.

How this might get implemented

Only my idea of how this could be handled: Upon issue creation, there's a switch to make it private (it could also be called "sensitive" or "allow only maintainers to access this report"). This way, a user could report a security issue and make sure only the maintainers receive the report. It's then hidden and only visible to members of the repo. (Fine-tuning this would of course also be an option as to toggle between the core maintainers and a broader circle of devs or something like this).
It should be possible to add members manually, maybe because they might be useful for this particular issue.
Controlling access could be made via a dedicated menu, but it might also be an idea to keep it simple: All members with certain access to the repo can see private issues and adding people is as simple as mentioning them. The latter one might of course introduce accidental disclosure of information when not being careful, this needs to be discussed further.

I think, such a feature would facilitate software development a lot and make sure that everything can be tracked within one platform instead of relying on external communication. And it would finally allow pull / merge requests to be discussed openly for security vulnerabilities. Often, they just contain mock information to prevent anyone from seeing this until a release etc.
Thank you for considering this.

Originally created by @fnetX on GitHub (Mar 11, 2021). Feature Request ## Description Currently and on most git hosting providers, issues are always public. While this is of course desired default behaviour, I propose to add an option for internal or private issues (and may be even pull / merge requests) for the following reasons: - **Security Reports:** There is no standardized way to send security reports to developers or maintainers of the software Usually, there's a hint that they should be reported via E-Mail. But this way, they fall out of the default bug tracking and must be discussed elsewhere. - **Internal discussion:** Also especially useful for handling vulnerabilities, discussing fixes and preparing pull requests that are only visible to the public once merged, it might also be a good idea to allow some discussion between maintainers privately. - **Sensitive information:** Sometimes, debugging an issue requires disclosing logs with sensitive information or providing access to test systems etc. They are usually sent via external tools e.g. email. It would be a cool feature to keep this in the issue tracker but allow only for limited access to the maintainers and the reporter. ## How this might get implemented Only my idea of how this could be handled: Upon issue creation, there's a switch to make it private (it could also be called "sensitive" or "allow only maintainers to access this report"). This way, a user could report a security issue and make sure only the maintainers receive the report. It's then hidden and only visible to members of the repo. (Fine-tuning this would of course also be an option as to toggle between the core maintainers and a broader circle of devs or something like this). It should be possible to add members manually, maybe because they might be useful for this particular issue. Controlling access could be made via a dedicated menu, but it might also be an idea to keep it simple: All members with certain access to the repo can see private issues and adding people is as simple as mentioning them. The latter one might of course introduce accidental disclosure of information when not being careful, this needs to be discussed further. I think, such a feature would facilitate software development a lot and make sure that everything can be tracked within one platform instead of relying on external communication. And it would finally allow pull / merge requests to be discussed openly for security vulnerabilities. Often, they just contain mock information to prevent anyone from seeing this until a release etc. Thank you for considering this.
GiteaMirror added the issue/duplicate label 2025-11-02 07:13:00 -06:00
Author
Owner

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Mar 11, 2021):

some form of discussions have already been worked on (WIP atm) in https://github.com/go-gitea/gitea/pull/14644 so that could perhaps be adapted for the "Internal discussions' part.

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Mar 11, 2021): some form of discussions have already been worked on (WIP atm) in https://github.com/go-gitea/gitea/pull/14644 so that could perhaps be adapted for the "Internal discussions' part.
Author
Owner

@techknowlogick commented on GitHub (Mar 11, 2021):

Closing as dupe of https://github.com/go-gitea/gitea/issues/3217

@techknowlogick commented on GitHub (Mar 11, 2021): Closing as dupe of https://github.com/go-gitea/gitea/issues/3217
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#6991