Support a member-only organisation profile README

[kernusr]

Feature Description

Many thanks to everyone who worked on the development of features .profile/README.md! It's great!

When so much has been done for public profiles, I would like to know what you think about private README.md?

I won’t tell you why this is needed, because everyone will determine for themselves why they need it. I'll just leave this link to GitHub https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile#adding-a-member-only-organization-profile-readme

Personally, my company and I use this functionality on GitHub and we really want to see something similar in Gitea. But first I would like to discuss the issue with the community

Screenshots

No response

[Arpit1048]

@kernusr i would like to pick this issue - lmk if there are any concerns

[PanGan21]

Hi! Is this issue open for contribution or @Arpit1048 you are still working on it?

[hwhsu1231]

I posted a feedback on GitHub Community Discussion recently, which is talking about the similar feature request:

https://github.com/orgs/community/discussions/125724

I recommended that Gitea adopt the following organization profile READMEs for Public and Member-Only modes:

• Public Mode: .profile/public/README.md
• Member-Only Mode: .profile/private/README.md

[kemzeb]

• Public Mode: .profile/public/README.md
• Member-Only Mode: .profile/private/README.md

I do agree it would be easier to throw both private and public org READMEs into a single .profile repository. I'm not familiar with private org READMEs, but one potential concern that I think would arise is that they may contain information or links that organizations may not want to share with the public. Currently I see two solutions for this:

• Make .profile a private repository (don't think this would make sense)
• Follow GitHub's steps and create a separate, private repository i.e. .profile-private to hold the private org README

[lafriks]

.profile-private/README.md imho makes more sense as this way it would be better to control who can view it with existing repository access controls as there might be use cases where only small group (specific team) of org members can see it while others only see public one. This would cover more use cases

[changchaishi]

I want to work on this, is this ok?

[lunny]

I want to work on this, is this ok?

You are welcome to do this. Please describe your design or proposal about the implementation especially whether we should use a new repository like @lafriks described. This will make the following review process more easier and less rewritten.

[changchaishi]

I propose to use a new repository for this issue as @lafriks described. The GitHub organization's member profile uses a separate repository as well.

For the design:

1. the existing function in org/home.go and contexts in components can be reused to gather repository by simply adding a new parameter for profileType={PUBLIC/Private}
2. The nature of a member who can view and create a repository is already included in the org home logic and context. Just renaming those context variables to include Public/Private keywords can make the design work.
3. Adding a drop-down menu to select Public or Member view, in which the selected will inject the view_as query key to the URL and rerender the page to load the desired readme
4. Before the overview tab is loaded, the org home page can already determine the existence of .profile and .profile-private README.md, when both are present and the doer is indeed a member, the drop-down menu will show.

The challenges in this design:

1. Adding a drop-down menu on the org home page and using query parameters for rerendering the desired readme could work. But the query string or forms for home.tmpl is not in a good structure to add a new query parameter using view_as. So in my implementation, I resolve both query-string for public and member at once then feed them into the template.
2. Since the new repository is proposed, a name with .profile-private in the create repository page should automatically resolve the repo name and check/uncheck and disable the checkbox by recognizing those repo names.
3. The addition of a drop-down menu may need help with styling.

These are things I've implemented in #32872, sorry for the inconvenience that I did not discuss here at first.

[lunny]

Can we put the content in the same repository? I don't know whether people would like to change something both in the .profile and .profile-private. If that is, putting them in the same repository will reduce the commits submissions.

[changchaishi]

Can we put the content in the same repository?

I'm unsure if we can because I'm quite new to this project.

I don't know whether people would like to change something both in the .profile and .profile-private. If that is, putting them in the same repository will reduce the commits submissions.

If changing both profiles is frequent and similar, they should stick with 1 public profile. If they need something that looks similar but uses a different link (like templating)? I think it is possible to integrate such commits through actions using a profile as base repo.

---

For the design, I am more inclined to use the different repo names and have different visibilities (1 public 1 private). So non-members will not see the private profile readme in the overview tab, but they can see it just by navigating to the .profile/private/README.md.

This comment is built on I think the git repo does not have a file-level visibility feature.

[changchaishi]

Since the new repository is proposed, a name with .profile-private in the create repository page should automatically resolve the repo name and check/uncheck and disable the checkbox by recognizing those repo names.

I dug into the code, the logic can be added in web_src by replacing checkbox logic from the static template with the Vue component