127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
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 Forum</b>: The user may read forum posts
* <b>Write Forum</b>: The user may create new forum threads and reply
to existing threads. New posts are held for moderation.
* <b>WriteTrusted Forum</b>: Same as <b>Write Forum</b> except that
posts are inserted into the block chain immediately without being held
for moderation.
* <b>Moderate Forum</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>Supervise Forum</b>: User can grant or revoke
<b>WriteTrusted</b> capability for other users. (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
involving a human, go into Admin → Access and enable the "Allow
|
|
|
>
|
>
|
<
<
>
>
|
|
|
|
|
>
>
>
|
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
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 Forum</b> (<tt>2</tt>): The user may read forum posts.
* <b>Write Forum</b> (<tt>3</tt>): The user may create new forum
threads, reply to existing threads, and edit their own posts. New
posts are held for moderation, and they are marked to prevent them
from being included in clone and sync operations.
* <b>WriteTrusted Forum</b> (<tt>4</tt>): Same as <b>Write Forum</b>
except that forum updates bypass the [#moderation | moderation and
private artifact restrictions].
* <b>Moderate Forum</b> (<tt>5</tt>): User gets buttons on posts
which allow them to either reject or approve posts held for
moderation. User also gets access to a page (<tt>/modreq</tt>)
showing the list of pending moderation tasks.
* <b>Supervise Forum</b> (<tt>6</tt>): User can grant or revoke
<b>WriteTrusted</b> capability for other users. (Currently
unimplemented.)
* <b>Email Alerts</b> (<tt>7</tt>): User can sign themselves up for
email notifications, a.k.a. alerts.
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
involving a human, go into Admin → Access and enable the "Allow
|
165
166
167
168
169
170
171
172
173
174
175
176
177
178
|
Read Forum capability (2) to users in the <tt>reader</tt> category.
For either type of repository, you are likely to want to give at least
the WriteTrusted capability (4) to users in the <tt>developer</tt>
category. If you did not give the Read Forum 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.
|
>
>
>
>
>
>
>
>
>
>
>
>
|
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
Read Forum capability (2) to users in the <tt>reader</tt> category.
For either type of repository, you are likely to want to give at least
the WriteTrusted capability (4) to users in the <tt>developer</tt>
category. If you did not give the Read Forum 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.
You must give at least one user or user category the Email Alerts
capability (7), else the only people able to sign themselves up for
email notifications are those with the Setup or Admin capability. Those
users could sign others up via Admin → Notification, but you
probably want to give this capability to one of the user categories.
Give it to <tt>nobody</tt> if you want anyone to sign up without any
restrictions. Give it to <tt>anonymous</tt> if you want the user to
solve a simple CAPTCHA before signing up. Give it to <tt>reader</tt> or
<tt>developer</tt> if you want only users with Fossil logins to have
this ability. (That's assuming you give one or both of these
capabilities to every user on your Fossil repository.)
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.
|
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
|
<h2 id="mod-user">Using the Moderation Feature</h2>
Having described all of the work that Fossil performs under the hood on
behalf of its users, we can now give the short list of work left for the
repository's administrators and moderators:
<ol>
<li>Add the <b>Moderate Forum</b> (<tt>5</tt>) capability to any of
your users who should have this ability. You don't need to do this
for any user with Setup (<tt>s</tt>) or Admin (<tt>a</tt>)
capability; it's
[http://fossil-scm.org/index.html/artifact/b16221ffb736caa2?ln=1246-1257
| already included].</li>
<li>When someone without <b>WriteTrusted Forum</b> (<tt>4</tt>)
capability submits a post, reply, or edit, an entry will appear on
the timeline if the type filter is set to "Forum" or "Any Type". A
notification will also appear on the <tt>/modreq</tt> page; a
moderator may wish to keep that page open in a browser tab,
reloading it occasionally to check for pending moderation
requests.</li>
<li>A moderator viewing an unmoderated post sees two buttons at the
bottom, "Approve" and "Reject" in place of the "Delete" button that
the post's creator sees. Beware that both actions are durable and
have no undo. Be careful!</li>
</ol>
|
|
<
|
|
>
>
|
>
|
|
|
|
|
|
|
|
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
|
<h2 id="mod-user">Using the Moderation Feature</h2>
Having described all of the work that Fossil performs under the hood on
behalf of its users, we can now give the short list of work left for the
repository's administrators and moderators:
<ol>
<li>Add the <b>Moderate Forum</b> capability (<tt>5</tt>) to any of
your users who should have this ability. You don't need to do this
for any user with Setup (<tt>s</tt>) or Admin (<tt>a</tt>)
capability; it's
[http://fossil-scm.org/index.html/artifact/b16221ffb736caa2?ln=1246-1257
| already included].</li>
<li>When someone updates the forum, an entry will appear in the
timeline if the type filter is set to "Forum" or "Any Type". If that
user has only the <b>Write Forum</b> capability (<tt>3</tt>), any
other user with the <b>Moderate Forum</b> capability (<tt>5</tt>)
will see a conditional link appear at the top of the main forum
page: "Moderation Requests". Clicking this takes the moderator to
the <tt>/modreq</tt> page. A moderator may wish to keep the main
forum page open in a browser tab, reloading it occasionally to see
when the "Moderation Requests" link reappears.</li>
<li>A moderator viewing an update pending moderation sees two
buttons at the bottom, "Approve" and "Reject" in place of the
"Delete" button that the post's creator sees. Beware that both
actions are durable and have no undo. Be careful!</li>
</ol>
|