Fossil

Check-in [5d75504a]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:More tweaks to the forum.wiki doc
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256:5d75504af03e0451a7dde0d6d1749b3c748dddc679acf81285222b296b2cb473
User & Date: wyoung 2018-08-08 19:30:23
Context
2018-08-08
19:43
More SSO discussion improvements in forum.wiki check-in: bc303c0e user: wyoung tags: trunk
19:30
More tweaks to the forum.wiki doc check-in: 5d75504a user: wyoung tags: trunk
19:25
Small tweak to the advice for "reader" category capability for forums check-in: ea67aade user: wyoung tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/forum.wiki.

78
79
80
81
82
83
84
85

86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
...
109
110
111
112
113
114
115
116


117
118
119
120
121
122
123
124
125
126
...
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
<h2>Setting up a Fossil Forum</h2>

<h3>Permissions</h3>

Fossil forums use the same role-based access control mechanism as
for normal Fossil repository logins.

There are several dedicated permsissions for forums:


  *  <b>Read</b>: The user may read forum posts
  *  <b>Write</b>: The user may create new forum threads and reply to
     existing threads. New posts are held for moderation.
  *  <b>Write Trusted</b>: Same as <b>Write</b>, but posts are inserted
     into the block chain immediately without being held for moderation.
  *  <b>Moderate</b>: User gets buttons on posts which allow them to
     either delete or approve posts held for moderation. User also gets
     access to a page (<tt>/modreq</tt>) showing the list of pending
     moderation tasks.
  *  <b>Administer</b>: User can grant <b>Write Trusted</b> permission
     to another user, or revoke it. (Currently unimplemented.)

By default, no Fossil user has permission to use the forums except for
users with Setup and Admin capabilities, which get these as part of the
large package of other capabilities they get.

For public Fossil repositories that wish to accept new users without
................................................................................

For a private repository, you probably won't want to give the
<tt>anonymous</tt> user any forum access, but you may wish to give
capability "2" to the <tt>reader</tt> user category.

For either type of repository, you are likely to want to give at least
the Write Trusted (4) capability to the <tt>developer</tt> user
category.



By following this advice, you should not need to tediously add
capabilities to individual accounts, except in atypical cases, such as
to grant the Moderate Forum capability (5) to an uncommonly
highly-trusted user.


<h3>Skin Setup</h3>

If you create a new Fossil repository with version 2.7 or newer, its
................................................................................
software where you either end up with two separate user tables and
permission sets, or you must go to significant effort to integrate the
two login systems.

You may instead choose to host your forums in a separate Fossil
repository from your other assets. A good reason to do this is that you
have a public project where very few of those participating in the forum
have special permissions for assets managed by Fossil for the project
itself, so you wish to segregate the two user sets.

Fossil offers a way to split the difference: you can host your forum in
a repository separate from your other Fossil-managed content yet still
have single sign-on for that common set of users that will have logins
on both repositories. Simply enable Fossil's login groups feature in
Admin &rarr; Login-Group, which allows one Fossil repository to
recognize users authorized on another repository.







|
>










|







 







|
>
>


|







 







|
|







78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
...
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
...
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
<h2>Setting up a Fossil Forum</h2>

<h3>Permissions</h3>

Fossil forums use the same role-based access control mechanism as
for normal Fossil repository logins.

There are several dedicated forum-related capability bits you can grant
a user:

  *  <b>Read</b>: The user may read forum posts
  *  <b>Write</b>: The user may create new forum threads and reply to
     existing threads. New posts are held for moderation.
  *  <b>Write Trusted</b>: Same as <b>Write</b>, but posts are inserted
     into the block chain immediately without being held for moderation.
  *  <b>Moderate</b>: User gets buttons on posts which allow them to
     either delete or approve posts held for moderation. User also gets
     access to a page (<tt>/modreq</tt>) showing the list of pending
     moderation tasks.
  *  <b>Administer</b>: User can grant <b>Write Trusted</b> capability
     to another user, or revoke it. (Currently unimplemented.)

By default, no Fossil user has permission to use the forums except for
users with Setup and Admin capabilities, which get these as part of the
large package of other capabilities they get.

For public Fossil repositories that wish to accept new users without
................................................................................

For a private repository, you probably won't want to give the
<tt>anonymous</tt> user any forum access, but you may wish to give
capability "2" to the <tt>reader</tt> user category.

For either type of repository, you are likely to want to give at least
the Write Trusted (4) capability to the <tt>developer</tt> user
category. If you did not give forum read capability (2) to
<tt>anonymous</tt> above, you should give <tt>developer</tt> that
capability here, if you choose to give it capability 3 or 4.

By following this advice, you should not need to tediously add
capabilities to individual accounts except in atypical cases, such as
to grant the Moderate Forum capability (5) to an uncommonly
highly-trusted user.


<h3>Skin Setup</h3>

If you create a new Fossil repository with version 2.7 or newer, its
................................................................................
software where you either end up with two separate user tables and
permission sets, or you must go to significant effort to integrate the
two login systems.

You may instead choose to host your forums in a separate Fossil
repository from your other assets. A good reason to do this is that you
have a public project where very few of those participating in the forum
have special capability bits for assets managed by Fossil for the
project itself, so you wish to segregate the two user sets.

Fossil offers a way to split the difference: you can host your forum in
a repository separate from your other Fossil-managed content yet still
have single sign-on for that common set of users that will have logins
on both repositories. Simply enable Fossil's login groups feature in
Admin &rarr; Login-Group, which allows one Fossil repository to
recognize users authorized on another repository.