Fossil

Check-in [812dd52c]
Login

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

Overview
Comment:Added the "How Moderation Works" section to www/forum.wiki, and improved the newly-renamed "Using the Moderation Feature" section as a result.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256:812dd52c7d5e305d7f974417f54888f820baf61b3cf7117d4daebb2612fd2247
User & Date: wyoung 2018-08-12 23:24:06
Context
2018-08-13
00:31
Assorted improvements to the forum.wiki document, mainly to the new moderation material. check-in: c1be5508 user: wyoung tags: trunk
2018-08-12
23:24
Added the "How Moderation Works" section to www/forum.wiki, and improved the newly-renamed "Using the Moderation Feature" section as a result. check-in: 812dd52c user: wyoung tags: trunk
22:27
Added "id"s to every header tag in the forum.wiki document, so you can create links to sub-sections. check-in: 03c298dc user: wyoung tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/forum.wiki.

335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
...
460
461
462
463
464
465
466
467
468
469






















































470
471
472
473
474
475
476
477
478
479
480
481
482

483
484
485
486
487
488
489
490
491
send email without having to care exactly which server implementation is
running at a given site.

<a id="status"></a>If you reload the Email Notification Setup page, the
Status section at the top should show:

<verbatim>
    Outgoing Email:	Piped to command "sendmail -t"
    Pending Alerts:	0 normal, 0 digest
    Subscribers:	0 active, 0 total
</verbatim>


<h4 id="subscribe">Subscribe to Alerts</h4>

Above, we see that there are no subscribers, so the next step is to add
one.
................................................................................
    $ fossil ale send
</verbatim>

This only does the same thing as the final command above, rather than
send you an ale, as you might be hoping. Sorry.


<h2 id="moderation">Moderation</h2>

Fossil forum moderation is easy:























































<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, you'll get a notice on the timeline if
    the type filter is set to "Forum" or "Any Type". It will also appear
    on the <tt>/modreq</tt> page; you might want to keep that page open

    in a tab in your browser, and reload it occasionally to check for
    pending moderation requests.</li>

    <li>On an unmoderated post, click the "Approve" or "Reject" button.
    "Approve" writes the message semi-permanently into the Fossil
    blockchain, from which only [./shunning.wiki | shunning] can remove
    it. "Reject" deletes the post permanently, with no way to retrieve
    it. Be careful!</li>
</ol>







|
|
|







 







|

|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>










|
|
|
>
|
|

<
|
|
|
|

335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
...
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540

541
542
543
544
545
send email without having to care exactly which server implementation is
running at a given site.

<a id="status"></a>If you reload the Email Notification Setup page, the
Status section at the top should show:

<verbatim>
    Outgoing Email: Piped to command "sendmail -t"
    Pending Alerts: 0 normal, 0 digest
    Subscribers:    0 active, 0 total
</verbatim>


<h4 id="subscribe">Subscribe to Alerts</h4>

Above, we see that there are no subscribers, so the next step is to add
one.
................................................................................
    $ fossil ale send
</verbatim>

This only does the same thing as the final command above, rather than
send you an ale, as you might be hoping. Sorry.


<h2 id="moderation">How Moderation Works</h2>

When a person with the normal <b>Write Forum</b> capability (<tt>3</tt>)
either:

  *  creates a new post, or
  *  replies to an existing post, or
  *  edits a post/reply
  
...the new content is saved into Fossil's block chain, but two special
things happen to it:

<ol>
    <li>The artifact's ID is saved to the <tt>private</tt> table,
    preventing Fossil from sending such artifacts to any of the
    repository's clones.  (This is the same mechanism behind
    [./private.wiki | private branches].)</li>

    <li>A reference to that artifact is saved in the <tt>modreq</tt>
    table, which backs the moderation feature.  This is what causes
    Fossil to leave out the Reply button when rendering that post's HTML
    in the forum's web interface.</li>
</ol>

When a moderator approves a post, Fossil deletes these references in the
<tt>private</tt> and <tt>modreq</tt> tables so that the contribution is
effectively written semi-permanently into the Fossil block chain. The
artifact will now sync to clones, if the clone is done by a user with
<b>Check-Out</b> capability (<tt>o</tt>).

When a forum user edits a moderator-approved artifact, what actually
happens under the hood is that Fossil writes another artifact to the
repository which refers to the original version as its parent, causing
Fossil UI to present the new version instead of the original. The
original version remains in the repository, just as with historical
checkins. The parent must remain in the repository for referential
integrity purposes.

When you "Delete" such content through Fossil UI, it's actually an edit
with blank content.  The only way to truly delete such artifacts is
through [./shunning.wiki | shunning].

When a post is made by a user with <b>WriteTrusted Forum</b> capability
(<tt>4</tt>), it is posted in the same way, just with the
<tt>private</tt> and <tt>modreq</tt> table insertions skipped.

When a moderator rejects a post, reply, or edit, that artifact is
unceremoniously removed from the tip of the block chain. This is safe
since such a post cannot have any replies, so there will be no other
artifacts referring to it.


<h2 id="mod-user">Using the Moderation Feature</h2>

All of the above is work performed under the hood by Fossil on behalf of
its users. There is little work left for the administrators and
moderators of the repository:

<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>