Monitor and help create the private issues functionality as possible #24

Closed
opened 2025-03-10 03:32:16 +00:00 by ryanlerch · 5 comments
ryanlerch commented 2025-03-10 03:32:16 +00:00 (Migrated from codeberg.org)

Originally on: https://pagure.io/fedora-infra/forgejo-deployment/issue/14

Monitor and help create the private issues functionality as possible

As of now, Forgejo does not support the creation of confidential or private issue tickets on publicly visible namespaces and this happens to be a major blocker for implementing Forgejo in Fedora Project, especially with the projects that require the confidential or private issue tickets.

Some resources from the Forgejo upstream https://codeberg.org/forgejo/forgejo/issues/4944 and https://codeberg.org/forgejo/design/issues/2 indicate that this is being worked on.

Originally on: https://pagure.io/fedora-infra/forgejo-deployment/issue/14 Monitor and help create the private issues functionality as possible As of now, Forgejo does not support the creation of confidential or private issue tickets on publicly visible namespaces and this happens to be a major blocker for implementing Forgejo in Fedora Project, especially with the projects that require the confidential or private issue tickets. Some resources from the Forgejo upstream https://codeberg.org/forgejo/forgejo/issues/4944 and https://codeberg.org/forgejo/design/issues/2 indicate that this is being worked on.
gridhead commented 2025-03-10 04:31:00 +00:00 (Migrated from codeberg.org)

From the Git Forge Open meeting on 05th March 2025,

@jednorozec, @nilsph and @gridhead proposed the use of emails as a "workaround" (not a fix) for private issue tickets to minimize the crosstalk among multiple private issue tickets with various stakeholders. This has not been finalized yet.

See https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-03-05/git-forge-meeting.2025-03-05-14.00.log.html.

From the Git Forge Open meeting on 05th March 2025, @jednorozec, @nilsph and @gridhead proposed the use of emails as a "workaround" (not a fix) for private issue tickets to minimize the crosstalk among multiple private issue tickets with various stakeholders. This has not been finalized yet. See https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-03-05/git-forge-meeting.2025-03-05-14.00.log.html.
gridhead commented 2025-03-11 05:36:50 +00:00 (Migrated from codeberg.org)

One of the earliest attempts[1] to do this by @gusted was made against Gitea (that he does not recommend[2] following). There actually seems to be an issue ticket proposing the same idea to the upstream[3] but has had no significant updates since. There's a design branch[4] by @fnetx but even that has had the most recent update about seven months back, leading us to think if there is any work done on it yet. This still happens to be a major blocker for Fedora Project as discussed with the Forgejo friends during FOSDEM 2025[5] and can likely cause potential delays in the process of migrating away from Pagure. Any pointers as to where to start from can be useful.

Index

  1. https://github.com/go-gitea/gitea/pull/17711
  2. https://codeberg.org/forgejo/design/issues/2#issuecomment-2105623
  3. https://github.com/go-gitea/gitea/issues/3217
  4. https://codeberg.org/forgejo/design/src/branch/private-issues
  5. https://codeberg.org/forgejo/discussions/issues/290#issue-969036
One of the earliest attempts[1] to do this by @gusted was made against Gitea (that he does not recommend[2] following). There actually seems to be an issue ticket proposing the same idea to the upstream[3] but has had no significant updates since. There's a design branch[4] by @fnetx but even that has had the most recent update about seven months back, leading us to think if there is any work done on it yet. This still happens to be a major blocker for Fedora Project as discussed with the Forgejo friends during FOSDEM 2025[5] and can likely cause potential delays in the process of migrating away from Pagure. Any pointers as to where to start from can be useful. Index 1. https://github.com/go-gitea/gitea/pull/17711 2. https://codeberg.org/forgejo/design/issues/2#issuecomment-2105623 3. https://github.com/go-gitea/gitea/issues/3217 4. https://codeberg.org/forgejo/design/src/branch/private-issues 5. https://codeberg.org/forgejo/discussions/issues/290#issue-969036
gridhead commented 2025-03-18 05:53:45 +00:00 (Migrated from codeberg.org)

I hate to be the bearer of the poor news but there neither seem to be any active work nor any upcoming plans for the private issue tickets feature in Forgejo Development. The conversations that happened yesterday suggested that it is quite a difficult task to accomplish in Forgejo and certain workarounds were suggested to implement "the idea" of private issue tickets without having to do that directly.

image

image

image

I hate to be the bearer of the poor news but there neither seem to be any active work nor any upcoming plans for the private issue tickets feature in Forgejo Development. The conversations that happened yesterday suggested that it is quite a difficult task to accomplish in Forgejo and certain workarounds were suggested to implement "the idea" of private issue tickets without having to do that directly. ![image](/attachments/b394d27c-2225-46e0-82e9-4a7b893d9ecb) ![image](/attachments/e6563836-4f7a-4a63-b105-a468e51ed2fb) ![image](/attachments/7e7a606e-e9cb-49c6-9f57-e4aee427d94d)
gridhead commented 2025-03-18 05:58:04 +00:00 (Migrated from codeberg.org)

@ryanlerch and I met this morning to discuss the possible plans for this. I am getting myself more acquainted with the codebase as we go on. It seems like we would either have to pull this off by ourselves or resort to using workarounds. Given the focus on security that the upstream has, we can expect them to be selective of what makes it into the codebase. Should we choose to push the code upstream, our goal should be to avoid any longer-term maintenance of the said feature apart from the bug fixes that we might require in our usecase.

@ryanlerch and I met this morning to discuss the possible plans for this. I am getting myself more acquainted with the codebase as we go on. It seems like we would either have to pull this off by ourselves or resort to using workarounds. Given the focus on security that the upstream has, we can expect them to be selective of what makes it into the codebase. Should we choose to push the code upstream, our goal should be to avoid any longer-term maintenance of the said feature apart from the bug fixes that we might require in our usecase.
nilsph commented 2025-07-15 14:53:02 +00:00 (Migrated from codeberg.org)

As discussed, make this a spike to find out what was and is, and have a tracking epic (#113). Now I only need to find out how to make this block that one.

As discussed, make this a spike to find out what was and is, and have a tracking epic (#113). Now I only need to find out how to make this block that one.
ryanlerch added this to the Sprint 2 project 2025-11-03 04:34:15 +00:00
Sign in to join this conversation.
No milestone
No project
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
Reference
forge/forge#24
No description provided.