Support public code/issue access for private repositories

[wxiaoguang]

Close #8649, close #639 (will add "anonymous access" in following PRs)

[lunny]

Looks like the user can watch or star the private repositories. Is that normal or should it be hidden?

[wxiaoguang]

Looks like the user can watch or star the private repositories. Is that normal or should it be hidden?

There is no clear definition for that part.

For example: if a user is added into an org team, then they could only access "wiki" in a private repo, the user could still see "stars" and "watches", the same. So i think it is not a problem.

[lunny]

Looks like the user can watch or star the private repositories. Is that normal or should it be hidden?

There is no clear definition for that part.

For example: if a user is added into an org team, then they could only access "wiki" in a private repo, the user could still see "stars" and "watches", the same. So i think it is not a problem.

I think maybe there is an old bug when watching a repository. Users may receive emails which he should not be received.

[yp05327]

IMO, this feature can be something like sharing a file from cloud drive: generate a unique share URL to access the repo with read permission, a pin code is optional.

The current solution will cause the repo public to all signed-in users. By my understand, the use case is sharing my private code with read permission to someone who is not a user or a user without permission, not all signed-in users.
If the share target is a user of this instance, then just add read permission to code and issue unit is enough? (it is not implemented) If the target is not a user, I can also share it with the share URL? (also we need to consider how to handle it when force login is enabled in this case)

---

Edited:
It seems that this PR is fixing #639, #8649 is a bit different feature.

[wxiaoguang]

I do not understand what's your concern.

The current solution will cause the repo public to all signed-in users. By my understand, the use case is sharing my private code with read permission to someone who is not a user

It needs a new control like AnonymousAccess, this framework is designed well enough to support it in the future.

or a user without permission, not all signed-in users.

I do not understand what's your concern.

If the share target is a user of this instance, then just add read permission to code and issue unit is enough? (it is not implemented) If the target is not a user, I can also share it with the share URL? (also we need to consider how to handle it when force login is enabled in this case)

That's not the real use case. In many cases the site admin or org admin do not want to add users one by one.

It seems that this PR is fixing #639, #8649 is a bit different feature.

I don't understand why " #8649 is a bit different feature", this feature could fully satisfy that requirement.

[yp05327]

My use case is i was applying for a job, they wanted to see source code from my previous projects. I did not want to open source the source code due to unrelated reasons... But i wanted the folks at the company to be able to read over my source code without having to have specific read/write permissions.

The request sounds like: I only want to public to some special people, not all signed-in users.
e.g. I'm using gitea.com, I have a private repo, I want to public it to the company for applying the job, but I don't want to public it to other users in gitea.com, as it is a public instance.
So I think this PR is not satisfied with #8649.

[wxiaoguang]

So I think this PR is not satisfied with #8649.

#8649 (comment)

It satisfies. For anonymous access, it needs a new control like AnonymousAccess, this framework is designed well enough to support it in the future.

[wxiaoguang]

@go-gitea/maintainers ready for long time.

[SugarD-x]

It seems that this PR is fixing #639, #8649 is a bit different feature.

I don't understand why " #8649 is a bit different feature", this feature could fully satisfy that requirement.

I think the idea with #639 is to have private repos remain private, but have their tracker and wiki access be public so the public can contribute to reporting issues or provide documented usage help without being able to see the private code. At least that's it from my understanding, as I've been begging for the same for years. It doesn't change the behavior of the repos themselves. It just opens up a portion of the system to the public while the rest remains private. (Think about how private repos commonly post their commits via bots in Discord and Slack servers that are viewable to the public so they can see what is being worked on, but they can't see the actual code being committed or modified. It adds a secure way to communicate with the public without releasing your core work for everyone to see).

#8649 appears to be more focused on "unlisting" repos, which makes them non-searchable, but still accessible via a controlled, provided link. That is quite a bit different in the sense of the feature from the former. Now I'm sure one PR could theoretically handle controls for both of these requests, but they are definitely not one in the same, if that makes sense.

[wxiaoguang]

Thank you for your feedback.

Now I'm sure one PR could theoretically handle controls for both of these requests, but they are definitely not one in the same, if that makes sense.

Yes, the scenario is different while I think we can handle them by the same approach. After "WIP: Add anonymous access support #33257", I guess most cases should be able to be handled. Will try to improve it to make it usable in 1.24