Fossil

Check-in [31631b75]
Login

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

Overview
Comment:Covered capability 7 in the forum.wiki document, and made several improvements to the "Using the Moderation Feature" section.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 31631b756e08ae1e4840befe24541237d6a8ace3806d8cf52282294ff42d7fc6
User & Date: wyoung 2018-08-13 03:51:18.283
Context
2018-08-14
03:55
The blob-to-SMTP encoding logic was not strictly following RFC 5321 in that it was only dealing with the lone dot on the line case, doubling it to prevent the SMTP server from interpreting that as end-of-message. It missed the case where, if anything follows the dot, SMTP drops the leading dot, so you must also double the leading dot in that case. Basically, you always double a leading dot, regardless of line length.

This only affects Fossil's direct-to-SMTP email sending case, not those that send via a piped command or via DB. That is dealt with later in [8c0ec30bc3]. ... (check-in: 51740ce4 user: wyoung tags: trunk)

2018-08-13
03:51
Covered capability 7 in the forum.wiki document, and made several improvements to the "Using the Moderation Feature" section. ... (check-in: 31631b75 user: wyoung tags: trunk)
03:23
Assorted minor improvements to the www/alerts.md document. The major one is re-emphasizing the need to give capability 7 to some user or user category. Ask me how I came to think this necessary. :) ... (check-in: 3e75a683 user: wyoung tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to www/forum.wiki.
︙︙
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 &rarr; 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 &rarr; 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 &rarr; 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>