Collaborators and Organizations #82

Merged
lhinderberger merged 11 commits from ivan-paleo/Documentation:collabo-orga into master 2 years ago

Added documentation on how to invite collaborators and on how to create and manage organizations.
As usual: feedback welcome!

Added documentation on how to invite collaborators and on how to create and manage organizations. As usual: feedback welcome!
lhinderberger requested changes 2 years ago
lhinderberger left a comment

Thank you for your pull request! Please find my remarks below.

Thank you for your pull request! Please find my remarks below.
order: 40
---
## What is an organization?

I suggest we spend some more paragraphs pointing out the advantages of Organizations and explain the roles involved (Owner, Admin, Teams) a bit more.

I suggest we spend some more paragraphs pointing out the advantages of Organizations and explain the roles involved (Owner, Admin, Teams) a bit more.
Poster

I have to admit I'm not too confident on that topic...

I have to admit I'm not too confident on that topic...
Poster

But I'll give my best!

But I'll give my best!
Poster

I'm wondering what can owners do that admins can't? Except highlighting who created the organization, there is not much difference between admin and owner, right? Or is it that only the owner can e.g. delete the organization?

I'm wondering what can owners do that admins can't? Except highlighting who created the organization, there is not much difference between admin and owner, right? Or is it that only the owner can e.g. delete the organization?
Poster

OK, I've experimented and found some differences.

OK, I've experimented and found some differences.
ivan-paleo marked this conversation as resolved
![new-orga](/assets/images/collaborating/create-organization/NewOrga.PNG)
In the new form, choose a name for your organization (here "PolarClub"), define its visibility and choose what the administrators of repositories can do. Validate by clicking the green `Create Organization`:

To me, it still is not quite clear what the option "Repository admin can add and remove access for teams" does. I think we should go into more detail here.

To me, it still is not quite clear what the option "Repository admin can add and remove access for teams" does. I think we should go into more detail here.
Poster

I didn't go into more details because I don't know more...! XD

I didn't go into more details because I don't know more...! XD
Poster

Do you have an idea where I can find information on that topic?

Do you have an idea where I can find information on that topic?
Poster

OK, after lots of trials, I think I've managed to understand it. If I'm correct, this is indeed important to detail it in the documentation, because it is not really intuitive and self-explanatory!

OK, after lots of trials, I think I've managed to understand it. If I'm correct, this is indeed important to detail it in the documentation, because it is not really intuitive and self-explanatory!
ivan-paleo marked this conversation as resolved
## Switch between your personal account and the organization
On the dashboard, click on the avatar on the left and select the context (personal account or organization) you want to work with. Alternatively, access your repositories or your organization from the tabs on the right side.
![dashboard](/assets/images/collaborating/create-organization/Dashboard.png)

File paths are case-sensitive - currently, this does not render with npm run serve. You might want to adjust this path to PNG (or even better, all the other filenames to lowercase).

The style used in Codeberg Documentation is to have filenames kebap-cased

File paths are case-sensitive - currently, this does not render with npm run serve. You might want to adjust this path to PNG (or even better, all the other filenames to lowercase). The style used in Codeberg Documentation is to have filenames kebap-cased
ivan-paleo marked this conversation as resolved
![orga](/assets/images/collaborating/create-organization/Orga.PNG)
From there, you can access all repositories (there is none in this example) and create a new one. There is a list of all the members (`People`) and teams; in this example, there is only 1 member (Knut the polar bear), and 1 team (`Owners`) with 1 member and no repository.

I'd prefer to write the numbers out in this paragraph i.e. 1 -> one

I'd prefer to write the numbers out in this paragraph i.e. 1 -> one

Maybe add (yourself) behind "one team (Owners) with one member"

Maybe add (yourself) behind "one team (`Owners`) with one member"
ivan-paleo marked this conversation as resolved
From there, you can access all repositories (there is none in this example) and create a new one. There is a list of all the members (`People`) and teams; in this example, there is only 1 member (Knut the polar bear), and 1 team (`Owners`) with 1 member and no repository.
## Edit organization
The cog next to the organization's name will lead you to the organization's settings, where you can change the organization's name; add a full name, a description, a link to a website and a location; change the visibility and persmissions; and add/change the avatar:

We might want to highlight that cog in an additional detail screenshot.

We might want to highlight that cog in an additional detail screenshot.

We should also describe the difference between "Organization Name" and "Organization Full Name"

We should also describe the difference between "Organization Name" and "Organization Full Name"

Typo persmissions -> permissions

Typo persmissions -> permissions

Thinking about it again, it's probably better to not list all the fields of the form in the text again (it's already there, in the screenshot). Something like this might work better:

"The cog next to the organization's name will lead you to the organization's settings, where you can change general settings related to your organization, such as its name, avatar, website or visibility. It is also where you can delete your organization again and access more advanced settings, like organization webhooks."

After that we should explain the difference between "Organization Name" and "Organization Full Name"

Thinking about it again, it's probably better to not list all the fields of the form in the text again (it's already there, in the screenshot). Something like this might work better: "The cog next to the organization's name will lead you to the organization's settings, where you can change general settings related to your organization, such as its name, avatar, website or visibility. It is also where you can delete your organization again and access more advanced settings, like organization webhooks." After that we should explain the difference between "Organization Name" and "Organization Full Name"
ivan-paleo marked this conversation as resolved
In the `Labels` tab, you can create labels that will be used across all repositories of this organization. This will help with issues and pull requests. The default label set is a good starting point.
In the top right corner, you have access to the people (members) and teams of your organization. These can also be accessed from the organization's page.

Until #83 is resolved, there needs to be a <a name="teams"></a> here, due to the link further down on the page.

Until #83 is resolved, there needs to be a `<a name="teams"></a>` here, due to the link further down on the page.
Poster

Yes, I forgot indeed!

Yes, I forgot indeed!
ivan-paleo marked this conversation as resolved
To edit a team, go to the `Teams` tab and click on the team you want to edit:
![team-settings](/assets/images/collaborating/create-organization/team-settings.png)

Case-sensitive filenames (see above)

Case-sensitive filenames (see above)
ivan-paleo marked this conversation as resolved
![team-settings](/assets/images/collaborating/create-organization/team-settings.png)
Click on `Settings` to edit the team as shown above for the creation of a team.

Let's highlight that button in the screenshot

Let's highlight that button in the screenshot
ivan-paleo marked this conversation as resolved
This is also where you can add or remove members to a team, and assign repositories to a team.
## People
Somewhat counter-intuitively, this is not where you can add members; this is done in the `Teams` tab (see [Teams](#teams) above). But you can remove members from the `People` tab.

Let's move that paragraph below the screenshot and add an introductory paragraph here instead. Something like:

"On the People tab, you can get an overview of all the people who collaborate in your Organization."

Let's move that paragraph below the screenshot and add an introductory paragraph here instead. Something like: "On the `People` tab, you can get an overview of all the people who collaborate in your Organization."
ivan-paleo marked this conversation as resolved
## People
Somewhat counter-intuitively, this is not where you can add members; this is done in the `Teams` tab (see [Teams](#teams) above). But you can remove members from the `People` tab.
![people](/assets/images/collaborating/create-organization/People.PNG)

Case-sensitive filenames (see above)

Case-sensitive filenames (see above)
ivan-paleo marked this conversation as resolved
![people](/assets/images/collaborating/create-organization/People.PNG)
The visibility of the members can also be edited here: `Hidden` means that the membership of the member will not be shown on his/her profile, while `Visible` means that the membership will be shown on the profile. Note that your membership will always be visible to you on your profile; this visibility setting is for other users only.

Wording: his/her -> their (sounds a bit more fluent when read out loud, in my opinion).

I would change the second half to ", while Visible makes the avatar of the organization appear in the info card on their profile, as shown in the screenshot below. Note that your membership..."

With a screenshot below :)

Wording: his/her -> their (sounds a bit more fluent when read out loud, in my opinion). I would change the second half to ", while `Visible` makes the avatar of the organization appear in the info card on their profile, as shown in the screenshot below. Note that your membership..." With a screenshot below :)
ivan-paleo marked this conversation as resolved
The visibility of the members can also be edited here: `Hidden` means that the membership of the member will not be shown on his/her profile, while `Visible` means that the membership will be shown on the profile. Note that your membership will always be visible to you on your profile; this visibility setting is for other users only.
The role of each member is shown here, as well as whether they have activated the two-factor authentification (`2FA`, see [Setting up Two-factor Authentication](/contentsecurity/2fa)).

Please remove the leading /content from the links, as it otherwise yields Error 404.

Also please add a / before security

Please remove the leading /content from the links, as it otherwise yields Error 404. Also please add a `/` before security
ivan-paleo marked this conversation as resolved
lhinderberger added the
Kind: Documentation
Status: Ready for Review
labels 2 years ago
lhinderberger changed title from WIP: collaborators and organizations to Collaborators and Organizations 2 years ago
lhinderberger added
Status: Review
and removed
Status: Ready for Review
labels 2 years ago
Poster

Would you mind also commenting the file invite-collaborators.md? Maybe I should have created a separate PR, but I thought that the two topics are very much related.

Would you mind also commenting the file `invite-collaborators.md`? Maybe I should have created a separate PR, but I thought that the two topics are very much related.
Poster

I've edited according to your comments, adding the webP images as a bonus.
There were major changes, so it would be good if you could have a second look at it.

I've edited according to your comments, adding the webP images as a bonus. There were major changes, so it would be good if you could have a second look at it.

Would you mind also commenting the file invite-collaborators.md?

Oh, I must have missed that one - I'll have a look at it right away :)

Maybe I should have created a separate PR, but I thought that the two topics are very much related.

I think it's okay to put those two in the same PR, they are quite closely related.

> Would you mind also commenting the file `invite-collaborators.md`? Oh, I must have missed that one - I'll have a look at it right away :) > Maybe I should have created a separate PR, but I thought that the two topics are very much related. I think it's okay to put those two in the same PR, they are quite closely related.
Poster

I'll check the file names for my next commit based on your comments.

I'll check the file names for my next commit based on your comments.
lhinderberger requested changes 2 years ago
lhinderberger left a comment

Here's my comments on the revised edition.

Once these are fixed, I can give green light from my side - with a second reviewer still to be determined.

Here's my comments on the revised edition. Once these are fixed, I can give green light from my side - with a second reviewer still to be determined.
</picture>
You can choose whether members of the team can only access some repositories explicitly added to the team, or whether they can access all repositories of the organziation.
You can also allow members to be able to create new repositories for the organization. In this case, the member who creates the repository will be granted administrator rights for this repository, that is, editing all settings of the repository except those in the `Danger Zone` (transfer ownership, delete wiki data and repository, and archive repository). The member will then be added as a collaborator to the repository with administrator rights (see [Invite Collaborators](/collaborating/invite-collaborators) for details).

This paragraph is a bit long. Maybe we should instead provide an overview of the roles that users can have in an Organization under its own sub-heading, with a few bullet points per role. Maybe, if possible, even as a comparison table.

This paragraph is a bit long. Maybe we should instead provide an overview of the roles that users can have in an Organization under its own sub-heading, with a few bullet points per role. Maybe, if possible, even as a comparison table.

That suggestion applies to all other places in the document where user permissions are described as well.

That suggestion applies to all other places in the document where user permissions are described as well.

If you prefer, we can also leave it like it is now as a baseline and make an overview table at a later point in time.

If you prefer, we can also leave it like it is now as a baseline and make an overview table at a later point in time.
Poster

The table is a very good idea, it will make these permissions more understandable and comparable. I'll try to make something nice.

Is the standard markdown format for tables OK for Codeberg, or are there special details?

The table is a very good idea, it will make these permissions more understandable and comparable. I'll try to make something nice. Is the [standard markdown format for tables](https://www.markdownguide.org/extended-syntax/#tables) OK for Codeberg, or are there special details?
Poster

Can you recommend a way to add a green tick mark and a red cross in a markdown file, which will be nicely rendered on Codeberg?

Can you recommend a way to add a green tick mark and a red cross in a markdown file, which will be nicely rendered on Codeberg?

Nice to hear that you like the table idea and want to try it :)

I'd recommend to use HTML tables for this, as (at least in my experience) Markdown tables tend to be a bit cumbersome and inflexible to work with.

As for the check mark / cross: In Codeberg Documentation, FontAwesome is used, so it should be possible to write:

<i class="fas fa-check" style="color: green"></i>

for a green check mark and

<i class="fas fa-times" style="color: red"></i>

for a red cross.

Nice to hear that you like the table idea and want to try it :) I'd recommend to use HTML tables for this, as (at least in my experience) Markdown tables tend to be a bit cumbersome and inflexible to work with. As for the check mark / cross: In Codeberg Documentation, FontAwesome is used, so it should be possible to write: ```<i class="fas fa-check" style="color: green"></i>``` for a green check mark and ```<i class="fas fa-times" style="color: red"></i>``` for a red cross.
Poster

I tried that in the md file:

<table>
...
 <tbody>
  <tr>
   <td> Edit/delete organization </td>
   <td> <i class="fas fa-check" style="color: green"></i> </td>
   <td> <i class="fas fa-times" style="color: red"></i> </td>
   <td> <i class="fas fa-times" style="color: red"></i> </td>
   <td> <i class="fas fa-times" style="color: red"></i> </td>
  </tr>
 </tbody>
 ...
</table>

But I don't see any check mark or cross in the preview in VScodium. Is it because VSC doesn't support it or because I do something wrong?

I tried that in the md file: ``` <table> ... <tbody> <tr> <td> Edit/delete organization </td> <td> <i class="fas fa-check" style="color: green"></i> </td> <td> <i class="fas fa-times" style="color: red"></i> </td> <td> <i class="fas fa-times" style="color: red"></i> </td> <td> <i class="fas fa-times" style="color: red"></i> </td> </tr> </tbody> ... </table> ``` But I don't see any check mark or cross in the preview in VScodium. Is it because VSC doesn't support it or because I do something wrong?
Poster

(don't forget it's my first time doing HTML!)

(don't forget it's my first time doing HTML!)

The icons won't show up in VScodium/VSCode because only the final Eleventy render is set up to include FontAwesome. The Markdown preview in your IDE doesn't know about that.

In order to preview how the final page will look like, I strongly recommend to install Node.js and then run

npm install
npm run serve

That way, you'll also get a nice auto-refreshing preview of your articles, without needing to set up anything in addition.

The icons won't show up in VScodium/VSCode because only the final Eleventy render is set up to include FontAwesome. The Markdown preview in your IDE doesn't know about that. In order to preview how the final page will look like, I strongly recommend to install Node.js and then run ``` npm install npm run serve ``` That way, you'll also get a nice auto-refreshing preview of your articles, without needing to set up anything in addition.
You can also allow members to be able to create new repositories for the organization. In this case, the member who creates the repository will be granted administrator rights for this repository, that is, editing all settings of the repository except those in the `Danger Zone` (transfer ownership, delete wiki data and repository, and archive repository). The member will then be added as a collaborator to the repository with administrator rights (see [Invite Collaborators](/collaborating/invite-collaborators) for details).
If you have allowed repository administrators to grant or remove access for teams (see [Create an Organization](#create-orga) above), they can do so in `Settings > Collaborators` tab of the repository.
If you choose either `Read` or `Write` access, you can additionally define which sections of the repositories the members will have (read or write) access to. On the other hand, `Administrator` access automatically grants read and write access to all sections; this part of the form is therefore hidden in this case. Administrator rights are also required to add or remove collaborators and teams to the repositories.

I'm afraid I don't understand this paragraph. What do you mean with "sections of the repositories"?

I'm afraid I don't understand this paragraph. What do you mean with "sections of the repositories"?
ivan-paleo marked this conversation as resolved
<img src="/assets/images/collaborating/create-organization/profile.png" alt="profile">
</picture>
Members can have one of two roles: `Member` or `Owner`.

I suggest to drop that sentence, as it does not really provide much additional information.

I suggest to drop that sentence, as it does not really provide much additional information.
ivan-paleo marked this conversation as resolved
---
## Why invite collaborators?
If your project repository is public (see [Your first Repository](/getting-started/first-repository) on how to set up the visibility of a repository), everyone can see your repository and every Codeberg user can contribute through issues and pull requests. But this is not collaborating since you will have to fix the issues and deal with the pull requests on your own.

I'd write the last sentence a bit differently:

"This is contributing, but not collaborating, since you're still the only one who can *directly* commit changes to your repository."

I'd write the last sentence a bit differently: `"This is contributing, but not collaborating, since you're still the only one who can *directly* commit changes to your repository."`
ivan-paleo marked this conversation as resolved
## Add a collaborator
To add a user to a repository as a collaborator, first go to the settings of your repository.
![settings](/assets/images/collaborating/invite-collaborators/settings.png)

Please apply the <picture> blocks and webp images in this article too.

And, as you've already written, please remember the filenames :)

Please apply the `<picture>` blocks and webp images in this article too. And, as you've already written, please remember the filenames :)
Poster

I had not done that yet but I had already planed it for the revised version.

I had not done that yet but I had already planed it for the revised version.
ivan-paleo marked this conversation as resolved
Poster

I've made the changes; hopefully the table looks fine (content + form). If not, let me know!

I've made the changes; hopefully the table looks fine (content + form). If not, let me know!
lhinderberger reviewed 2 years ago
## Access rights
The table below gives an overview of the rights of the different types of teams:
<table>

I like the overall appearance of the table and I think it really helps clarifying the different levels of permissions within an Organization.

I like the overall appearance of the table and I think it really helps clarifying the different levels of permissions within an Organization.

I suggest to sort the permission rows from least to most exclusive and the role columns from most to least privileged, so that the permission ticks form a block/triangle shape, which makes it easier to spot permission differences at first glance.

Example: https://about.gitlab.com/pricing/gitlab-com/feature-comparison/ (although here, the columns are sorted ascendingly).

I suggest to sort the permission rows from least to most exclusive and the role columns from most to least privileged, so that the permission ticks form a block/triangle shape, which makes it easier to spot permission differences at first glance. Example: https://about.gitlab.com/pricing/gitlab-com/feature-comparison/ (although here, the columns are sorted ascendingly).
Poster

I can do that, partly at least. I think it makes more sense to group things that belong together (e.g. all the things that repo creators can do). But within the groups and between the groups does make sense indeed.

I can do that, partly at least. I think it makes more sense to group things that belong together (e.g. all the things that repo creators can do). But within the groups and between the groups does make sense indeed.

Yes, let's try it out and see how that looks like 👍

Yes, let's try it out and see how that looks like :thumbsup:
ivan-paleo marked this conversation as resolved
lhinderberger requested changes 2 years ago
lhinderberger left a comment

While I really like the new table and its overall appearance, there were a number of errors that need to be fixed before this PR can be approved.

Have you used npm run serve for a visual check before submitting this PR?

While I really like the new table and its overall appearance, there were a number of errors that need to be fixed before this PR can be approved. Have you used `npm run serve` for a visual check before submitting this PR?
<table>
<caption style="caption-side:bottom">
<sup>1</sup> Access to specific sections can be restricted by owners.

This line probably need a linebreak at its end.

This line probably need a linebreak at its end.

Also, let's link to further up in the text, where "sections" is explained.

Also, let's link to further up in the text, where "sections" is explained.
Poster

Is that the way?

<a href="#sections">sections</a>

with

<a name="sections"></a>

where the link should lead to?

Do I need empty lines before/after?

Is that the way? ``` <a href="#sections">sections</a> ``` with ``` <a name="sections"></a> ``` where the link should lead to? Do I need empty lines before/after?

Yes, that should work.

I don't know for sure if it requires empty lines, but in this case, I don't think so because they're inline elements.

Optionally, you can choose to use Markdown syntax instead of <a href=... for setting the link: [sections](#sections).

Yes, that should work. I don't know for sure if it requires empty lines, but in this case, I don't think so because they're inline elements. Optionally, you can choose to use Markdown syntax instead of `<a href=...` for setting the link: `[sections](#sections)`.
Poster

I didn't expect that I could mix HTML and Markdown, good to know :)

I didn't expect that I could mix HTML and Markdown, good to know :)
ivan-paleo marked this conversation as resolved
<thead>
<tr>
<th rowspan="2"> Task </th>
<th rowspan="2"> Team "Owners" </th>

This should be vertically aligned to the top, to be in line with "Other Teams"

This should be vertically aligned to the top, to be in line with "Other Teams"
ivan-paleo marked this conversation as resolved
<td> <i class="fas fa-times" style="color: red"></i> </td>
<td> <i class="fas fa-times" style="color: red"></i> </td>
</tr>
<tr>

This renders with grey background, but the other even/odd rows do not alternate colors. That's a CSS bug -> #89

This renders with grey background, but the other even/odd rows do not alternate colors. That's a CSS bug -> #89

(This does not require any changes by you, I wrote this here just for reference)

(This does not require any changes by you, I wrote this here just for reference)
ivan-paleo marked this conversation as resolved
<td> <i class="fas fa-check" style="color: green"></i> </td>
</tr>
<tr>
<td> Pull from repository </td>

As far as I can tell, this is not correct:

Once you have read access you can pull from a repository. However, you cannot approve Pull Requests (two entirely different things).
PRs can be approved and merged with Write access to a repository.

As far as I can tell, this is not correct: Once you have read access you can pull from a repository. However, you cannot approve Pull Requests (two entirely different things). PRs can be approved and merged with Write access to a repository.
Poster

I found it weird too, but this is how I understand the text relating to the team options:

"Read = Members can view and clone team repositories.
Write = Members can read and push to team repositories.
Admin = Members can pull and push to team repositories and add collaborators to them."

If my interpretation is wrong (I find yours much more meaningful indeed), then the wording here should be edited. And I can edit the table accordingly of course.

I found it weird too, but this is how I understand the text relating to the team options: "Read = Members can view and clone team repositories. Write = Members can read and push to team repositories. Admin = Members can pull and push to team repositories and add collaborators to them." If my interpretation is wrong (I find yours much more meaningful indeed), then the wording here should be edited. And I can edit the table accordingly of course.

Hmm, "can pull to team repositories" probably means merging pull requests, but that's actually something mere Writers can do too. So, I'm afraid this needs further investigation. Maybe someone who knows more about Gitea's internals can tell us more about this - maybe @ashimokawa or @6543 ? :)

Hmm, "can pull to team repositories" probably means merging pull requests, but that's actually something mere Writers can do too. So, I'm afraid this needs further investigation. Maybe someone who knows more about Gitea's internals can tell us more about this - maybe @ashimokawa or @6543 ? :)
Poster

Any news on that?

Any news on that?

Neither of the two has answered, but that might just be due to a bug in the mentions system, Codeberg/Community#257

Neither of the two has answered, but that might just be due to a bug in the mentions system, Codeberg/Community#257
Poster

Would it make sense to contact them directly? As far as I can tell, that's the only open issue to finalize this PR (or at least until a second collaborator reviews it)

Would it make sense to contact them directly? As far as I can tell, that's the only open issue to finalize this PR (or at least until a second collaborator reviews it)

It might be better to ask a question in Codeberg/Community instead.

It might be better to ask a question in Codeberg/Community instead.
<td> <i class="fas fa-check" style="color: green"></i> <sup>2</sup> </td>
</tr>
<tr>
<td> Edit the repository created by the member (excluding Danger Zone) </td>

Suggested wording: "Edit the repository created by the member" -> "Edit repository settings"

Also, Read and Write collaborators cannot edit repository settings.

Suggested wording: "Edit the repository created by the member" -> "Edit repository settings" Also, Read and Write collaborators cannot edit repository settings.
Poster

That's why the "created by the member" is important: if the owners allow members to create repositories, the member who created the repository is granted admin rights for this repo, i.e. he/she does have the rights to edit repository settings except those in the Danger Zone. This is independent of Read, Write or Admin rights.

That's why the "created by the member" is important: if the owners allow members to create repositories, the member who created the repository is granted admin rights for this repo, i.e. he/she does have the rights to edit repository settings except those in the Danger Zone. This is independent of Read, Write or Admin rights.

I will have to read up on this and get back to you later.

Currently, it seems to me a bit like there's two separate, independent permissions systems, one for organizations (Levels Owner/Team Admin/Team Member) and one for repositories (Levels Owner/Write/Read). If that is the case, it might be good to create two separate tables for each permissions system. Then there wouldn't be ambiguity concerning Read/Write and "member who creates" (= Repository Admin by virtue of being the one who created the repo inside an organization, even if they're not a Team Admin - but again, I'll have to read up on this to be sure).

I will have to read up on this and get back to you later. Currently, it seems to me a bit like there's two separate, independent permissions systems, one for organizations (Levels Owner/Team Admin/Team Member) and one for repositories (Levels Owner/Write/Read). If that is the case, it might be good to create two separate tables for each permissions system. Then there wouldn't be ambiguity concerning Read/Write and "member who creates" (= Repository Admin by virtue of being the one who created the repo inside an organization, even if they're not a Team Admin - but again, I'll have to read up on this to be sure).
Poster

This is my understanding too.
Having two tables might be the best solution indeed!

This is my understanding too. Having two tables might be the best solution indeed!
Poster

But probably not needed if we just mention that creating a repository grants admin rights (see below).

But probably not needed if we just mention that creating a repository grants admin rights (see below).

I haven't had the time to verify the assumption above - maybe you want to simply test it on codeberg-test.org instead? There you could create a test organization.

I haven't had the time to verify the assumption above - maybe you want to simply test it on codeberg-test.org instead? There you could create a test organization.
Poster

Oh, I did already! And you were right :)

Oh, I did already! And you were right :)

Nice 👍

Nice 👍
ivan-paleo marked this conversation as resolved
<td> <i class="fas fa-check" style="color: green"></i> </td>
</tr>
<tr>
<td> Edit the repository created by the member (including Danger Zone) </td>

Wording: See above

Wording: See above
Poster

In this case, what about "Edit repository settings in the Danger Zone"?

In this case, what about "Edit repository settings in the Danger Zone"?

That would be an option too, but "Edit repository settings (including Danger Zone)" would be fine as well. Choose what you like most :)

That would be an option too, but "Edit repository settings (including Danger Zone)" would be fine as well. Choose what you like most :)
ivan-paleo marked this conversation as resolved
<td> <i class="fas fa-times" style="color: red"></i> </td>
</tr>
<tr>
<td> Add/remove collaborator to the repository created by the member </td>

Wording and Permissions: See above

Wording and Permissions: See above
Poster

Admin rights granted to the member who created the repo include adding/removing collaborators to the repo (see above).

Admin rights granted to the member who created the repo include adding/removing collaborators to the repo (see above).
ivan-paleo marked this conversation as resolved
</table>
When owners allow members of a team to be able to create new repositories for the organization, the member who creates the repository will be granted administrator rights for this repository, that is, editing all settings of the repository except those in the `Danger Zone` (transfer ownership, delete wiki data and repository, and archive repository). The member will then be added as a collaborator to the repository with administrator rights (see [Invite Collaborators](/collaborating/invite-collaborators) for details).

These two sentences seem redundant relative to each other.

These two sentences seem redundant relative to each other.
Poster

Yes, kind of. I just wanted to stress that such member will have admin rights and will be listed as collaborator (not just as part of a team).
What about just deleting the last "with administrator rights"?

Yes, kind of. I just wanted to stress that such member will have admin rights and will be listed as collaborator (not just as part of a team). What about just deleting the last "with administrator rights"?

Yes. Also, if my assumption about the two independent permission systems turns out to be true, it might be enough to say that the member who creates the repository will be a Repository Administrator for the new repository.

Yes. Also, if my assumption about the two independent permission systems turns out to be true, it might be enough to say that the member who creates the repository will be a Repository Administrator for the new repository.
Poster

Indeed!

Indeed!
Poster

With this, there is no need for a second table then, right?

With this, there is no need for a second table then, right?
Owner

Sorry, this is just a test

Sorry, this is just a test
ivan-paleo marked this conversation as resolved
To add a user to a repository as a collaborator, first go to the settings of your repository.
<picture>
<source srcset="/assets/images/collaborating/invite-collaborators/settings.webp" type="image/webp">

The .webp images were not part of the commit, thus this article shows no images.

This is something that could have been easily spotted using npm run serve.

The .webp images were not part of the commit, thus this article shows no images. This is something that could have been easily spotted using `npm run serve`.
Poster

Well, using npm run serve is not so trivial for me: since I'm using my work PC, I have to check with admin to install NodeJS and then try to understand what "run npm install at the root of the source tree" means. When all that is done, I can use npm run serve.

Well, using `npm run serve` is not so trivial for me: since I'm using my work PC, I have to check with admin to install NodeJS and then try to understand what "run `npm install` *at the root of the source tree*" means. When all that is done, I can use `npm run serve`.

I see, that indeed makes it more complicated. Do I assume correctly that a private PC is not available for this? In that case, if your IT department declines to install Node.js, we'll have to accept that and I'd stop pushing you to use npm run serve 😉

But in case you do get access to Node.js:

The source tree is the directory tree containing all source code - in our case it's basically your copy of this repository.

The root of the source tree is the top-level directory of it, so the one containing the top-level README etc.

And executing a command there means to navigate to that directory, open a command line there (Git Bash or Powershell is fine too) and to then run that command from the command line.

I see, that indeed makes it more complicated. Do I assume correctly that a private PC is not available for this? In that case, if your IT department declines to install Node.js, we'll have to accept that and I'd stop pushing you to use `npm run serve` :wink: But in case you do get access to Node.js: The source tree is the directory tree containing all source code - in our case it's basically your copy of this repository. The root of the source tree is the top-level directory of it, so the one containing the top-level README etc. And executing a command there means to navigate to that directory, open a command line there (Git Bash or Powershell is fine too) and to then run that command from the command line.
Poster

I indeed only have a mac as a private computer. And since I need most of the tools on my work PC already (Git, RStudio...) it makes sense to keep working from that PC too (and installing all that on a mac would also take a lot of time).

But I'll ask IT about it (I guess it's a common theme, but they are always very busy).

And thanks for the instructions (I guess "open a command line there" is a Linux thing, but I just need to adjust the working directory with cd - see I've already learned a lot ;) )!

I indeed only have a mac as a private computer. And since I need most of the tools on my work PC already (Git, RStudio...) it makes sense to keep working from that PC too (and installing all that on a mac would also take a lot of time). But I'll ask IT about it (I guess it's a common theme, but they are always very busy). And thanks for the instructions (I guess "open a command line there" is a Linux thing, but I just need to adjust the working directory with `cd` - see I've already learned a lot ;) )!
ivan-paleo marked this conversation as resolved

@ivan-paleo I'm getting an Error 500 while trying to reply to your comment "With this, there is no need for a second table then, right?" - I'll post my response here hoping that it works:

Why wouldn't we need separate tables in this case?

In my opinion, a second table for repository-level permissions (in a separate article) would be good in any case, because it also explain permission levels for repositories that are not part of an organization.

@ivan-paleo I'm getting an Error 500 while trying to reply to your comment "With this, there is no need for a second table then, right?" - I'll post my response here hoping that it works: Why wouldn't we need separate tables in this case? In my opinion, a second table for repository-level permissions (in a separate article) would be good in any case, because it also explain permission levels for repositories that are not part of an organization.
Poster

@ivan-paleo I'm getting an Error 500 while trying to reply to your comment "With this, there is no need for a second table then, right?" - I'll post my response here hoping that it works:

Why wouldn't we need separate tables in this case?

In my opinion, a second table for repository-level permissions (in a separate article) would be good in any case, because it also explain permission levels for repositories that are not part of an organization.

Yes, it's a good idea to include that table in another article. My comment was just about the present article. The second table would be really redundant with the first one; this is what I realized when I tried to prepare it after the modifications on the 1st one!

> @ivan-paleo I'm getting an Error 500 while trying to reply to your comment "With this, there is no need for a second table then, right?" - I'll post my response here hoping that it works: > > Why wouldn't we need separate tables in this case? > > In my opinion, a second table for repository-level permissions (in a separate article) would be good in any case, because it also explain permission levels for repositories that are not part of an organization. Yes, it's a good idea to include that table in another article. My comment was just about the present article. The second table would be really redundant with the first one; this is what I realized when I tried to prepare it after the modifications on the 1st one!
lhinderberger added the
Status: Blocked
label 2 years ago
Poster

I've edited the table of access rights based on hw's table.

What do you think?

I've edited the table of access rights based on [hw's table](https://codeberg.org/Codeberg/Community/issues/302#issuecomment-116112). What do you think?
lhinderberger approved these changes 2 years ago

Looks good to me. Do you want to contribute a similar table for non-organization repo permissions in another PR? :)

Looks good to me. Do you want to contribute a similar table for non-organization repo permissions in another PR? :)

Regarding the question what else should be in the repo permissions article: For the beginning a mere table of permissions would be sufficient. For a more polished article we could add a bit of introductory prose.

Regarding the question what else should be in the repo permissions article: For the beginning a mere table of permissions would be sufficient. For a more polished article we could add a bit of introductory prose.
Poster

I have been thinking about it again. Let me explain you the way I see it so that I can confirm (or not) whether I'm missing something.

  • In case of a normal (= not org/team) repo, admins can do everything owners can, right?
  • In case of an org repo, only owners can manage the org (edit/delete org, add/remove members/teams, define access rights of teams, and edit org repo settings in the danger zone), right?

If that is correct, we only need to mention in this article that only owners can do the things listed above, and that the read/write/admin permissions are the same as the standard repo permissions (linking to the forthcoming article).
I would do a bullet list rather than a table in this case.

Does that sound like a valid way to go?

I have been thinking about it again. Let me explain you the way I see it so that I can confirm (or not) whether I'm missing something. * In case of a normal (= not org/team) repo, admins can do everything owners can, right? * In case of an org repo, only owners can manage the org (edit/delete org, add/remove members/teams, define access rights of teams, and edit org repo settings in the danger zone), right? If that is correct, we only need to mention in this article that only owners can do the things listed above, and that the read/write/admin permissions are the same as the standard repo permissions (linking to the forthcoming article). I would do a bullet list rather than a table in this case. Does that sound like a valid way to go?
Poster

Regarding the question what else should be in the repo permissions article: For the beginning a mere table of permissions would be sufficient. For a more polished article we could add a bit of introductory prose.

It sounds like a good idea. In which section do you see it? Also "collaborating with others"?

> Regarding the question what else should be in the repo permissions article: For the beginning a mere table of permissions would be sufficient. For a more polished article we could add a bit of introductory prose. It sounds like a good idea. In which section do you see it? Also "collaborating with others"?

Yes and yes :)

Yes and yes :)
Poster

In my latest commit, I've tried to homogenize all these permission issues:

  • I have written a new article about repo permissions in general
  • I have updated the section about permissions in the org article
  • I have tried to avoid unnecessary repetitions between the articles
  • I have interlinked these two articles + the one about collaborators

Hopefully, everything is clearer now and correct. Please check carefully!

In my latest commit, I've tried to homogenize all these permission issues: * I have written a new article about repo permissions in general * I have updated the section about permissions in the org article * I have tried to avoid unnecessary repetitions between the articles * I have interlinked these two articles + the one about collaborators Hopefully, everything is clearer now and correct. Please check carefully!
lhinderberger approved these changes 2 years ago
lhinderberger left a comment

Beautiful! 👍👍👍 Please change the article key (see below) and then this PR is ready to merge.

Great work! :)

Beautiful! 👍👍👍 Please change the article key (see below) and then this PR is ready to merge. Great work! :)
---
eleventyNavigation:
key: RepoPerm

Let's not use abbreviations. It's better to be explicit than to save a few bytes, in my opinion 😉
Also, that would be consistent with all other article keys in Codeberg/Documentation.

Let's not use abbreviations. It's better to be explicit than to save a few bytes, in my opinion :wink: Also, that would be consistent with all other article keys in Codeberg/Documentation.
Poster

No problem, I'll do it in a minute. My idea was not to save a few keys, but I thought the Key shouldn't be too long.

No problem, I'll do it in a minute. My idea was not to save a few keys, but I thought the Key shouldn't be too long.
ivan-paleo marked this conversation as resolved
lhinderberger removed the
Status: Blocked
label 2 years ago
Poster

Done!
What about a second review? I think it would make sense here.

Done! What about a second review? I think it would make sense here.
n approved these changes 2 years ago
n left a comment
Collaborator

Looks good. Great work!

Looks good. Great work!
lhinderberger merged commit 5e2a1ce0e8 into master 2 years ago

Merged and deployed - thank you @ivan-paleo for these two very nice articles! 👍

Also, we have just reached 100 commits to this repository. 🥳🎉🍾

Merged and deployed - thank you @ivan-paleo for these two very nice articles! 👍 Also, we have just reached 100 commits to this repository. 🥳🎉🍾

Reviewers

lhinderberger approved these changes 2 years ago
n approved these changes 2 years ago
The pull request has been merged as 5e2a1ce0e8.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Depends on
Loading…
There is no content yet.