Fossil

Check-in [26424763]
Login

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

Overview
Comment:More forum.wiki tweaks
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 26424763c76bcd72a4aaaa54965cd7f379a76f4468ee4d3c840cf2a0c4850a69
User & Date: wyoung 2018-08-13 00:59:23.407
Context
2018-08-13
01:11
Typo fix ... (check-in: c3d9c8e0 user: wyoung tags: trunk)
00:59
More forum.wiki tweaks ... (check-in: 26424763 user: wyoung tags: trunk)
00:31
Assorted improvements to the forum.wiki document, mainly to the new moderation material. ... (check-in: c1be5508 user: wyoung tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to www/forum.wiki.
︙︙
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

checkins. The parent must remain in the repository for referential
integrity purposes.

When you "Delete" a moderator-approved post or reply through Fossil UI,
it's actually an edit with blank replacement 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 an update, that artifact is unceremoniously
removed from the tip of the block chain. This is safe because Fossil
prevents the creation of any replies to posts and replies that require
moderator approval, so there will be no other artifacts referring to it.

Rejecting an edit is even safer, since the original post remains behind,
maintaining referential integrity.


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

Having described all of the work that Fossil performs under the hood by
Fossil 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








|
|
|



<
|
>
|
|




|
|
|








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

checkins. The parent must remain in the repository for referential
integrity purposes.

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

When a user with <b>WriteTrusted Forum</b> capability (<tt>4</tt>)
updates the forum, it happens in the same way except that Fossil skips
the <tt>private</tt> and <tt>modreq</tt> table insertions.

When a moderator rejects an update, that artifact is unceremoniously
removed from the tip of the block chain. This is safe because Fossil

prevents replies to a reply or post awaiting moderator approval, so
referential integrity cannot be harmed.  Rejecting an edit is even
safer, since the original post remains behind, so that replies continue
to refer to that original post.


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