deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

(nomenclature in documentation) changed "category" to "role"

Browse source 
I sometimes think my English is not as good as I claim it is.  Or at
least when I'm thinking in perl my English shuts down...
This commit is contained in:
Sitaram Chamarty 2011-10-29 05:59:03 +05:30
parent 26155c4027
commit 57b3ac3a91
2 changed files with 23 additions and 24 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
doc/gitolite.rc.mkd
View file

@ -162,7 +162,7 @@ on feedback from my users to find or fix issues.
NOTE that due to some quoting and interpolation issues I have not been
able to look at, a literal "." needs to be specified in this string as
`\\.` (two backslashes and a dot). So this is how you'd allow any keys in
the "foo" category: `$GL_GITCONFIG_KEYS = "foo\\..*";`
the "foo" section: `$GL_GITCONFIG_KEYS = "foo\\..*";`
* `$GL_NO_CREATE_REPOS`, boolean, default 0
@ -309,10 +309,10 @@ on feedback from my users to find or fix issues.
* `$GL_WILDREPOS_PERM_CATS`, string, default "READERS WRITERS"
Originally, we only allowed "R" and "RW" in the setperms command. Now we
allow the admin to define other categories as she wishes (example:
MANAGERS, TESTERS, etc).
allow the admin to define other roles as she wishes (example: MANAGERS,
TESTERS, etc).
This variable is a space-separated list of the allowed categories.
This variable is a space-separated list of the allowed roles.
PLEASE, *PLEASE*, read the section in
[doc/wildcard-repositories.mkd][wild] for caveats and warnings. This is a
@ -324,8 +324,8 @@ on feedback from my users to find or fix issues.
$GL_WILDREPOS_PERM_CATS = "READERS WRITERS";
You can use your own categories in addition to the standard ones; I
suggest you include READERS and WRITERS for backward compatbility though:
You can use your own roles in addition to the standard ones; I suggest you
include READERS and WRITERS for backward compatbility though:
$GL_WILDREPOS_PERM_CATS = "READERS WRITERS MANAGERS TESTERS";

35
doc/wildcard-repositories.mkd
View file

@ -21,7 +21,7 @@ In this document:
* <a href="#_side_note_line_anchored_regexes">side-note: line-anchored regexes</a>
* <a href="#_contrast_with_refexes">contrast with refexes</a>
* <a href="#_handing_out_rights_to_wildcard_matched_repos">handing out rights to wildcard-matched repos</a>
* <a href="#_admin_adding_other_categories_than_READERS_and_WRITERS">(admin) adding other categories than READERS and WRITERS</a>
* <a href="#_admin_adding_other_roles_than_READERS_and_WRITERS">(admin) adding other roles than READERS and WRITERS</a>
* <a href="#_IMPORTANT_WARNING_ABOUT_THIS_FEATURE_">**IMPORTANT WARNING ABOUT THIS FEATURE**</a>
* <a href="#_setting_a_gitweb_description_for_a_wildcard_matched_repo">setting a gitweb description for a wildcard-matched repo</a>
* <a href="#_reporting">reporting</a>
@ -175,10 +175,10 @@ part of this list*** is controlled by the person who created the repository.
The use case is that, although our toy example has only 3 students, in reality
there will be a few dozen, but each assignment will be worked on only by a
handful from among those. This allows the creator to take ad hoc sets of
users from among the actual users in the system, and place them into one of
two categories (in this example, READERS and WRITERS respectively). In theory
you could do the same thing by creating lots of little "assignment-NN" groups
in the config file but that may be a little too cumbersome for non-secret
users from among the actual users in the system, and give them one of two
roles (in this example, READERS and WRITERS respectively). In theory you
could do the same thing by creating lots of little "assignment-NN" groups in
the config file but that may be a little too cumbersome for non-secret
environments.
Create a small text file that contains the permissions you desire:
@ -208,13 +208,13 @@ The following points are important:
`:` like in a repo URL. The first space-separated word is READERS or
WRITERS, and the rest are simple usernames.
<a name="_admin_adding_other_categories_than_READERS_and_WRITERS"></a>
<a name="_admin_adding_other_roles_than_READERS_and_WRITERS"></a>
### (admin) adding other categories than READERS and WRITERS
### (admin) adding other roles than READERS and WRITERS
Let's say your needs are more complex and you need more categories of users.
For example, you might like to have a setup where only a tester can update
tags, and only a manager can delete branches:
Let's say your needs are more complex and you need more roles. For example,
you might like to have a setup where only a tester can update tags, and only a
manager can delete branches:
repo foo/..*
C = u1
@ -241,14 +241,13 @@ file. The rc file documentation (`doc/gitolite.rc.mkd`) explains how.
#### **IMPORTANT WARNING ABOUT THIS FEATURE**
Please make sure that none of the category names conflict with any of the
Please make sure that none of the role names conflict with any of the
**usernames** in the system. For example, if you have a user called "foo",
make sure you do not include "foo" as a valid category in
make sure you do not include "foo" as a valid role in
`$GL_WILDREPOS_PERM_CATS`.
You can keep things sane by using UPPERCASE names for categories, while
keeping all your usernames lowercase; then you don't have to worry about this
problem.
You can keep things sane by using UPPERCASE names for roles, while keeping all
your usernames lowercase; then you don't have to worry about this problem.
<a name="_setting_a_gitweb_description_for_a_wildcard_matched_repo"></a>
@ -309,7 +308,7 @@ Now find a repo pattern that matches the actual reponame being pushed -- this
tells you which set of rules to apply. There can be multiple matches; if so,
they will all be applied in the sequence they appear in the config file.
If the invoking user has been put in the "WRITERS" category using `setperms`, all
If the invoking user has been given the "WRITERS" role using `setperms`, all
permissions for the the user WRITERS are given to the invoking username (and
similarly for READERS).
@ -330,8 +329,8 @@ Assuming user "u4" trying to push-create a new repo called
RW = @TAs
R = @prof
If u4 puts u5 in the "WRITERS" category using `setperms`, and u5 tries to
access that repo, the ruleset looks like:
If u4 gives u5 the "WRITERS" role using `setperms`, and u5 tries to access
that repo, the ruleset looks like:
repo assignments/u4/a23
C = @students