Fossil SCM
Assorted small improvements to top-level caps doc
Commit
f21bfbeede1755a26351144d5cc4cf2cab776e5b70e79d0ca43211b44e1ab848
Parent
3ac560a2d0b9c81…
1 file changed
+19
-14
+19
-14
| --- www/caps/index.md | ||
| +++ www/caps/index.md | ||
| @@ -72,13 +72,14 @@ | ||
| 72 | 72 | **e**. |
| 73 | 73 | |
| 74 | 74 | We suggest that you lean heavily on these fixed user categories when |
| 75 | 75 | setting up new users. Ideally, your users will group neatly into one of |
| 76 | 76 | the predefined categories, but if not, you might be able to shoehorn |
| 77 | -them into our fixed scheme. For example, the administrator of a repo | |
| 78 | -that’s mainly used as a wiki or forum for non-developers could treat the | |
| 79 | -“developer” user category as if it were called “author”. | |
| 77 | +them into our fixed scheme. For example, the administrator of a | |
| 78 | +wiki-only Fossil repo for non-developers could treat the “developer” | |
| 79 | +user category as if it were called “author,” and a forum-only repo could | |
| 80 | +treat the same category as if it were called “member.” | |
| 80 | 81 | |
| 81 | 82 | There is currently no way to define custom user categories. |
| 82 | 83 | |
| 83 | 84 | [svr]: ../server/ |
| 84 | 85 | |
| @@ -87,20 +88,20 @@ | ||
| 87 | 88 | |
| 88 | 89 | When one or more users need to be different from the basic capabilities |
| 89 | 90 | defined in user categories, you can assign caps to individual users. You |
| 90 | 91 | may want to have the [cap reference][ref] open when doing such work. |
| 91 | 92 | |
| 92 | -However, it is useful at this time to expand on the logical | |
| 93 | +It is useful at this time to expand on the logical | |
| 93 | 94 | expression [above](#cat), which covered only the four fixed user categories. |
| 94 | 95 | When we bring the individual user capabilities into it, the complete |
| 95 | 96 | expression of the way Fossil implements user power becomes: |
| 96 | 97 | |
| 97 | 98 | > *setup* ≥ *admin* ≥ *moderator* ≥ *(developer* ∨ *reader)* ≥ *[subscriber]* ≥ *anonymous* ≥ *nobody* |
| 98 | 99 | |
| 99 | 100 | The two additions at the top are clear: [setup is all-powerful][apsu], |
| 100 | -and admin users are [subordinate to the setup | |
| 101 | -user(s)][avsp]. Both are superior to all other users. | |
| 101 | +and since admin users have [all capabilities][ref] except for Setup | |
| 102 | +capability, they are [subordinate only to the setup user(s)][avsp]. | |
| 102 | 103 | |
| 103 | 104 | The moderator insertion could go anywhere from where it’s shown now down |
| 104 | 105 | to above the “anonymous” level, depending on what other caps you give to |
| 105 | 106 | your moderators. Also, there is not just one type of moderator: Fossil |
| 106 | 107 | has [wiki][l], [ticket][q], and [forum][5] moderators, each |
| @@ -119,21 +120,21 @@ | ||
| 119 | 120 | [avsp]: ./admin-v-setup.md#philosophy |
| 120 | 121 | |
| 121 | 122 | |
| 122 | 123 | ## <a name="new"></a>New Repository Defaults |
| 123 | 124 | |
| 124 | -When you create a new repository, Fossil creates only one user account | |
| 125 | -named after your OS user name [by default](#defuser). | |
| 125 | +Fossil creates one user account in new repos, which is named after your | |
| 126 | +OS user name [by default](#defuser). | |
| 126 | 127 | |
| 127 | 128 | Fossil gives the initial repository user the [all-powerful Setup |
| 128 | 129 | capability][apsu]. |
| 129 | 130 | |
| 130 | 131 | Users who visit a [served repository][svr] without logging in get the |
| 131 | 132 | “nobody” user category’s caps which default to |
| 132 | 133 | **[g][g][j][j][o][o][r][r][z][z]**: clone the repo, read the wiki, |
| 133 | 134 | check-out files via the web UI, view tickets, and pull version archives. |
| 134 | -The defaults are suited to random passers-by on a typical FOSS project’s | |
| 135 | +This default is suited to random passers-by on a typical FOSS project’s | |
| 135 | 136 | public web site and its code repository. |
| 136 | 137 | |
| 137 | 138 | Users who [prove they are not a bot][bot] by logging in — even if only |
| 138 | 139 | as “anonymous” — get the “nobody” capability set plus |
| 139 | 140 | **[h][h][m][m][n][n][c][c]**: see internal hyperlinks, append to |
| @@ -149,12 +150,12 @@ | ||
| 149 | 150 | “anonymous”. This category is not well-named, because the default caps |
| 150 | 151 | are all about modifying repository content: edit existing wiki pages, |
| 151 | 152 | change one’s own password, create new ticket report formats, and modify |
| 152 | 153 | existing tickets. This category would be better named “participant”. |
| 153 | 154 | |
| 154 | -Those in the “developer” category get all of the above plus the | |
| 155 | -**[d][d][e][e][i][i]** caps: delete wiki articles and tickets, view | |
| 155 | +Those in the “developer” category get the “nobody” and “anonymous” cap | |
| 156 | +sets plus **[d][d][e][e][i][i]**: delete wiki articles and tickets, view | |
| 156 | 157 | sensitive user material, and check in changes. |
| 157 | 158 | |
| 158 | 159 | [bot]: ../antibot.wiki |
| 159 | 160 | |
| 160 | 161 | |
| @@ -191,16 +192,20 @@ | ||
| 191 | 192 | of whether your local user within that repo has <b>Read</b> capability. |
| 192 | 193 | The repo clone is completely under your user’s power at that point, |
| 193 | 194 | affected only by OS file permissions and such. If you need to prevent |
| 194 | 195 | that, you want to deny **Clone** capability instead. |
| 195 | 196 | |
| 196 | -It is common to withhold **Clone** capability from low-status visitors | |
| 197 | -to prevent them from viewing [embedded | |
| 198 | -documentation](../embeddeddoc.wiki), seeing [the file | |
| 197 | +Withholding the **Read** capability has a different effect: it | |
| 198 | +prevents a web client from viewing [embedded | |
| 199 | +documentation](../embeddeddoc.wiki), using [the file | |
| 199 | 200 | browser](/help?cmd=/dir), and pulling file content via the |
| 200 | 201 | [`/artifact`](/help?cmd=/artifact), [`/file`](/help?cmd=/file), and |
| 201 | 202 | [`/raw`](/help?cmd=/raw) URLs. |
| 203 | +It is is common to withhold **Read** capability from low-status visitors | |
| 204 | +on private or semi-private repos to prevent them from pulling individual | |
| 205 | +elements of the repo over the web one at a time, as someone may do when | |
| 206 | +denied the bulk **Clone** capability. | |
| 202 | 207 | |
| 203 | 208 | |
| 204 | 209 | ## <a name="defuser"></a>Default User Name |
| 205 | 210 | |
| 206 | 211 | By default, Fossil assumes your OS user account name is the same as the |
| 207 | 212 |
| --- www/caps/index.md | |
| +++ www/caps/index.md | |
| @@ -72,13 +72,14 @@ | |
| 72 | **e**. |
| 73 | |
| 74 | We suggest that you lean heavily on these fixed user categories when |
| 75 | setting up new users. Ideally, your users will group neatly into one of |
| 76 | the predefined categories, but if not, you might be able to shoehorn |
| 77 | them into our fixed scheme. For example, the administrator of a repo |
| 78 | that’s mainly used as a wiki or forum for non-developers could treat the |
| 79 | “developer” user category as if it were called “author”. |
| 80 | |
| 81 | There is currently no way to define custom user categories. |
| 82 | |
| 83 | [svr]: ../server/ |
| 84 | |
| @@ -87,20 +88,20 @@ | |
| 87 | |
| 88 | When one or more users need to be different from the basic capabilities |
| 89 | defined in user categories, you can assign caps to individual users. You |
| 90 | may want to have the [cap reference][ref] open when doing such work. |
| 91 | |
| 92 | However, it is useful at this time to expand on the logical |
| 93 | expression [above](#cat), which covered only the four fixed user categories. |
| 94 | When we bring the individual user capabilities into it, the complete |
| 95 | expression of the way Fossil implements user power becomes: |
| 96 | |
| 97 | > *setup* ≥ *admin* ≥ *moderator* ≥ *(developer* ∨ *reader)* ≥ *[subscriber]* ≥ *anonymous* ≥ *nobody* |
| 98 | |
| 99 | The two additions at the top are clear: [setup is all-powerful][apsu], |
| 100 | and admin users are [subordinate to the setup |
| 101 | user(s)][avsp]. Both are superior to all other users. |
| 102 | |
| 103 | The moderator insertion could go anywhere from where it’s shown now down |
| 104 | to above the “anonymous” level, depending on what other caps you give to |
| 105 | your moderators. Also, there is not just one type of moderator: Fossil |
| 106 | has [wiki][l], [ticket][q], and [forum][5] moderators, each |
| @@ -119,21 +120,21 @@ | |
| 119 | [avsp]: ./admin-v-setup.md#philosophy |
| 120 | |
| 121 | |
| 122 | ## <a name="new"></a>New Repository Defaults |
| 123 | |
| 124 | When you create a new repository, Fossil creates only one user account |
| 125 | named after your OS user name [by default](#defuser). |
| 126 | |
| 127 | Fossil gives the initial repository user the [all-powerful Setup |
| 128 | capability][apsu]. |
| 129 | |
| 130 | Users who visit a [served repository][svr] without logging in get the |
| 131 | “nobody” user category’s caps which default to |
| 132 | **[g][g][j][j][o][o][r][r][z][z]**: clone the repo, read the wiki, |
| 133 | check-out files via the web UI, view tickets, and pull version archives. |
| 134 | The defaults are suited to random passers-by on a typical FOSS project’s |
| 135 | public web site and its code repository. |
| 136 | |
| 137 | Users who [prove they are not a bot][bot] by logging in — even if only |
| 138 | as “anonymous” — get the “nobody” capability set plus |
| 139 | **[h][h][m][m][n][n][c][c]**: see internal hyperlinks, append to |
| @@ -149,12 +150,12 @@ | |
| 149 | “anonymous”. This category is not well-named, because the default caps |
| 150 | are all about modifying repository content: edit existing wiki pages, |
| 151 | change one’s own password, create new ticket report formats, and modify |
| 152 | existing tickets. This category would be better named “participant”. |
| 153 | |
| 154 | Those in the “developer” category get all of the above plus the |
| 155 | **[d][d][e][e][i][i]** caps: delete wiki articles and tickets, view |
| 156 | sensitive user material, and check in changes. |
| 157 | |
| 158 | [bot]: ../antibot.wiki |
| 159 | |
| 160 | |
| @@ -191,16 +192,20 @@ | |
| 191 | of whether your local user within that repo has <b>Read</b> capability. |
| 192 | The repo clone is completely under your user’s power at that point, |
| 193 | affected only by OS file permissions and such. If you need to prevent |
| 194 | that, you want to deny **Clone** capability instead. |
| 195 | |
| 196 | It is common to withhold **Clone** capability from low-status visitors |
| 197 | to prevent them from viewing [embedded |
| 198 | documentation](../embeddeddoc.wiki), seeing [the file |
| 199 | browser](/help?cmd=/dir), and pulling file content via the |
| 200 | [`/artifact`](/help?cmd=/artifact), [`/file`](/help?cmd=/file), and |
| 201 | [`/raw`](/help?cmd=/raw) URLs. |
| 202 | |
| 203 | |
| 204 | ## <a name="defuser"></a>Default User Name |
| 205 | |
| 206 | By default, Fossil assumes your OS user account name is the same as the |
| 207 |
| --- www/caps/index.md | |
| +++ www/caps/index.md | |
| @@ -72,13 +72,14 @@ | |
| 72 | **e**. |
| 73 | |
| 74 | We suggest that you lean heavily on these fixed user categories when |
| 75 | setting up new users. Ideally, your users will group neatly into one of |
| 76 | the predefined categories, but if not, you might be able to shoehorn |
| 77 | them into our fixed scheme. For example, the administrator of a |
| 78 | wiki-only Fossil repo for non-developers could treat the “developer” |
| 79 | user category as if it were called “author,” and a forum-only repo could |
| 80 | treat the same category as if it were called “member.” |
| 81 | |
| 82 | There is currently no way to define custom user categories. |
| 83 | |
| 84 | [svr]: ../server/ |
| 85 | |
| @@ -87,20 +88,20 @@ | |
| 88 | |
| 89 | When one or more users need to be different from the basic capabilities |
| 90 | defined in user categories, you can assign caps to individual users. You |
| 91 | may want to have the [cap reference][ref] open when doing such work. |
| 92 | |
| 93 | It is useful at this time to expand on the logical |
| 94 | expression [above](#cat), which covered only the four fixed user categories. |
| 95 | When we bring the individual user capabilities into it, the complete |
| 96 | expression of the way Fossil implements user power becomes: |
| 97 | |
| 98 | > *setup* ≥ *admin* ≥ *moderator* ≥ *(developer* ∨ *reader)* ≥ *[subscriber]* ≥ *anonymous* ≥ *nobody* |
| 99 | |
| 100 | The two additions at the top are clear: [setup is all-powerful][apsu], |
| 101 | and since admin users have [all capabilities][ref] except for Setup |
| 102 | capability, they are [subordinate only to the setup user(s)][avsp]. |
| 103 | |
| 104 | The moderator insertion could go anywhere from where it’s shown now down |
| 105 | to above the “anonymous” level, depending on what other caps you give to |
| 106 | your moderators. Also, there is not just one type of moderator: Fossil |
| 107 | has [wiki][l], [ticket][q], and [forum][5] moderators, each |
| @@ -119,21 +120,21 @@ | |
| 120 | [avsp]: ./admin-v-setup.md#philosophy |
| 121 | |
| 122 | |
| 123 | ## <a name="new"></a>New Repository Defaults |
| 124 | |
| 125 | Fossil creates one user account in new repos, which is named after your |
| 126 | OS user name [by default](#defuser). |
| 127 | |
| 128 | Fossil gives the initial repository user the [all-powerful Setup |
| 129 | capability][apsu]. |
| 130 | |
| 131 | Users who visit a [served repository][svr] without logging in get the |
| 132 | “nobody” user category’s caps which default to |
| 133 | **[g][g][j][j][o][o][r][r][z][z]**: clone the repo, read the wiki, |
| 134 | check-out files via the web UI, view tickets, and pull version archives. |
| 135 | This default is suited to random passers-by on a typical FOSS project’s |
| 136 | public web site and its code repository. |
| 137 | |
| 138 | Users who [prove they are not a bot][bot] by logging in — even if only |
| 139 | as “anonymous” — get the “nobody” capability set plus |
| 140 | **[h][h][m][m][n][n][c][c]**: see internal hyperlinks, append to |
| @@ -149,12 +150,12 @@ | |
| 150 | “anonymous”. This category is not well-named, because the default caps |
| 151 | are all about modifying repository content: edit existing wiki pages, |
| 152 | change one’s own password, create new ticket report formats, and modify |
| 153 | existing tickets. This category would be better named “participant”. |
| 154 | |
| 155 | Those in the “developer” category get the “nobody” and “anonymous” cap |
| 156 | sets plus **[d][d][e][e][i][i]**: delete wiki articles and tickets, view |
| 157 | sensitive user material, and check in changes. |
| 158 | |
| 159 | [bot]: ../antibot.wiki |
| 160 | |
| 161 | |
| @@ -191,16 +192,20 @@ | |
| 192 | of whether your local user within that repo has <b>Read</b> capability. |
| 193 | The repo clone is completely under your user’s power at that point, |
| 194 | affected only by OS file permissions and such. If you need to prevent |
| 195 | that, you want to deny **Clone** capability instead. |
| 196 | |
| 197 | Withholding the **Read** capability has a different effect: it |
| 198 | prevents a web client from viewing [embedded |
| 199 | documentation](../embeddeddoc.wiki), using [the file |
| 200 | browser](/help?cmd=/dir), and pulling file content via the |
| 201 | [`/artifact`](/help?cmd=/artifact), [`/file`](/help?cmd=/file), and |
| 202 | [`/raw`](/help?cmd=/raw) URLs. |
| 203 | It is is common to withhold **Read** capability from low-status visitors |
| 204 | on private or semi-private repos to prevent them from pulling individual |
| 205 | elements of the repo over the web one at a time, as someone may do when |
| 206 | denied the bulk **Clone** capability. |
| 207 | |
| 208 | |
| 209 | ## <a name="defuser"></a>Default User Name |
| 210 | |
| 211 | By default, Fossil assumes your OS user account name is the same as the |
| 212 |