|
4ed14b1…
|
wyoung
|
1 |
<title>Fossil Forums</title> |
|
4ed14b1…
|
wyoung
|
2 |
|
|
4ed14b1…
|
wyoung
|
3 |
<h2>Introduction</h2> |
|
4ed14b1…
|
wyoung
|
4 |
|
|
44ab80e…
|
drh
|
5 |
Fossil includes a built-in discussion forum, designed to substitute |
|
44ab80e…
|
drh
|
6 |
for a mailing list. Email notification is available to receive posts, |
|
44ab80e…
|
drh
|
7 |
but the web-based UI must be used to enter new posts. Advantages of |
|
44ab80e…
|
drh
|
8 |
the forum include: |
|
44ab80e…
|
drh
|
9 |
|
|
44ab80e…
|
drh
|
10 |
* <b>Easy to Administer:</b> If you have already set up a |
|
44ab80e…
|
drh
|
11 |
[./server/|Fossil server] with [./alerts.md|email alerts] |
|
44ab80e…
|
drh
|
12 |
then turning on the forum feature |
|
44ab80e…
|
drh
|
13 |
is just a matter of flipping some permission bits. There is |
|
44ab80e…
|
drh
|
14 |
no new software to install and configure, and the same logins |
|
44ab80e…
|
drh
|
15 |
and passwords work. |
|
44ab80e…
|
drh
|
16 |
|
|
c2b38f0…
|
stephan
|
17 |
* <b>Consistent Display:</b> Forum posts can be in [/md_rules|Markdown], |
|
5d3ba8a…
|
drh
|
18 |
[/wiki_rules|Fossil Wiki], or plain text. Whichever format is used, the result is |
|
5d3ba8a…
|
drh
|
19 |
displayed consistently across all platforms and operating systems and |
|
5d3ba8a…
|
drh
|
20 |
between mobile devices and desktops. |
|
44ab80e…
|
drh
|
21 |
|
|
44ab80e…
|
drh
|
22 |
* <b>Editable:</b> Forum posts can be amended after they are sent, |
|
44ab80e…
|
drh
|
23 |
to fix typos or provide updates. The original posts are preserved |
|
44ab80e…
|
drh
|
24 |
as part of the historical record, but only the amended posts are |
|
44ab80e…
|
drh
|
25 |
displayed by default. |
|
44ab80e…
|
drh
|
26 |
|
|
44ab80e…
|
drh
|
27 |
* <b>Built-in Full-Text Search:</b> Forum posts can be included in |
|
44ab80e…
|
drh
|
28 |
the index used by the built-in Fossil search logic. |
|
44ab80e…
|
drh
|
29 |
|
|
44ab80e…
|
drh
|
30 |
* <b>Off-Line Access:</b> Because forum posts are synced along with |
|
5d3ba8a…
|
drh
|
31 |
all other artifacts, you can search the forum, or add new posts, or |
|
5d3ba8a…
|
drh
|
32 |
edit existing posts, all while off-line. |
|
44ab80e…
|
drh
|
33 |
|
|
44ab80e…
|
drh
|
34 |
* <b>Automatically Cross-Referenced To Other Fossil Artifacts:</b> Because forum |
|
44ab80e…
|
drh
|
35 |
posts are normal Fossil artifacts, you can link from them to |
|
44ab80e…
|
drh
|
36 |
other Fossil artifacts (check-ins, wiki, tickets) and from those other |
|
44ab80e…
|
drh
|
37 |
artifacts to forum posts. The reverse links are recognized and |
|
44ab80e…
|
drh
|
38 |
displayed automatically on the receiver. |
|
635d2f6…
|
wyoung
|
39 |
|
|
5d3ba8a…
|
drh
|
40 |
* <b>Malefactor Resistant:</b> Because Fossil accepts forum posts |
|
5d3ba8a…
|
drh
|
41 |
only via the web UI, it is more resistent to spam. Passers-by |
|
5d3ba8a…
|
drh
|
42 |
can post to the forum anonymously (subject to moderation), without |
|
5d3ba8a…
|
drh
|
43 |
the hassle of a sign-up process. |
|
5d3ba8a…
|
drh
|
44 |
|
|
5d3ba8a…
|
drh
|
45 |
* <b>Distributed and Tamper-Proof:</b> Posts are stored in the Fossil |
|
5d3ba8a…
|
drh
|
46 |
repository using the same [./fileformat.wiki | DAG/Merkle-tree design] |
|
5d3ba8a…
|
drh
|
47 |
that Fossil uses to store your check-ins, wiki documents, etc. |
|
5d3ba8a…
|
drh
|
48 |
Forum posts sync to cloned repositories. |
|
44ab80e…
|
drh
|
49 |
|
|
44ab80e…
|
drh
|
50 |
<h2>Example Installations</h2> |
|
44ab80e…
|
drh
|
51 |
|
|
44ab80e…
|
drh
|
52 |
Both the [forum:/forum|Fossil project itself] and the |
|
44ab80e…
|
drh
|
53 |
[https://sqlite.org/forum/forum|SQLite project] use the Fossil forum in place |
|
44ab80e…
|
drh
|
54 |
of mailing lists. The forum has worked well on both projects. The ability |
|
44ab80e…
|
drh
|
55 |
to post anonymously provides a low-resistance path for people to report |
|
44ab80e…
|
drh
|
56 |
problems, resulting in more problems being reported and fixed. |
|
44ab80e…
|
drh
|
57 |
The ability to moderate and amend forum posts means that the |
|
44ab80e…
|
drh
|
58 |
forums contain better information. And backups and archives |
|
44ab80e…
|
drh
|
59 |
are as easy as running "clone". |
|
44ab80e…
|
drh
|
60 |
|
|
44ab80e…
|
drh
|
61 |
Both Fossil and SQLite keep their forums as separate repositories. |
|
44ab80e…
|
drh
|
62 |
But there is no requirement to do this. A forum can be coresident in |
|
44ab80e…
|
drh
|
63 |
the same repository with the source code. |
|
03c298d…
|
wyoung
|
64 |
|
|
03c298d…
|
wyoung
|
65 |
<h2 id="setup">Setting up a Fossil Forum</h2> |
|
03c298d…
|
wyoung
|
66 |
|
|
03c298d…
|
wyoung
|
67 |
<h3 id="caps">Capabilities</h3> |
|
f85bc32…
|
wyoung
|
68 |
|
|
f85bc32…
|
wyoung
|
69 |
By default, no Fossil user has permission to use the forums except for |
|
f85bc32…
|
wyoung
|
70 |
users with Setup and Admin capabilities, which get these as part of the |
|
f85bc32…
|
wyoung
|
71 |
large package of other capabilities they get. |
|
f85bc32…
|
wyoung
|
72 |
|
|
f85bc32…
|
wyoung
|
73 |
For public Fossil repositories that wish to accept new users without |
|
f85bc32…
|
wyoung
|
74 |
involving a human, go into Admin → Access and enable the "Allow |
|
2490bfb…
|
wyoung
|
75 |
users to register themselves" setting. You may also wish to give users |
|
779ddef…
|
wyoung
|
76 |
in [./caps/#ucat | the <tt>anonymous</tt> user category] the |
|
779ddef…
|
wyoung
|
77 |
<b>[./caps/ref.html#2 | RdForum]</b> and |
|
779ddef…
|
wyoung
|
78 |
<b>[./caps/ref.html#3 | WrForum]</b> |
|
779ddef…
|
wyoung
|
79 |
capabilities: this allows people to post without creating an account |
|
f85bc32…
|
wyoung
|
80 |
simply by solving [./antibot.wiki | a simple CAPTCHA]. |
|
f85bc32…
|
wyoung
|
81 |
|
|
ea67aad…
|
wyoung
|
82 |
For a private repository, you probably won't want to give the |
|
2490bfb…
|
wyoung
|
83 |
<tt>anonymous</tt> user any forum access, but you may wish to give the |
|
779ddef…
|
wyoung
|
84 |
<b>RdForum</b> capability to users in the <tt>reader</tt> category. |
|
f85bc32…
|
wyoung
|
85 |
|
|
f85bc32…
|
wyoung
|
86 |
For either type of repository, you are likely to want to give at least |
|
779ddef…
|
wyoung
|
87 |
the <b>[./caps/ref.html#4 | WrTForum]</b> capability to users in the <tt>developer</tt> |
|
779ddef…
|
wyoung
|
88 |
category. If you did not give the <b>RdForum</b> capability to |
|
5d75504…
|
wyoung
|
89 |
<tt>anonymous</tt> above, you should give <tt>developer</tt> that |
|
779ddef…
|
wyoung
|
90 |
capability here if you choose to give it <b>WrForum</b> or |
|
779ddef…
|
wyoung
|
91 |
<b>WrTForum</b> capability. |
|
d6e5754…
|
wyoung
|
92 |
|
|
2ef70be…
|
wyoung
|
93 |
If you want to use the email alert feature, by default only those |
|
d6e5754…
|
wyoung
|
94 |
users in the Setup and Admin user categories can make use of it. Grant |
|
779ddef…
|
wyoung
|
95 |
the <b>[./caps/ref.html#7 | EmailAlert]</b> capability to give others access to this feature. |
|
2ef70be…
|
wyoung
|
96 |
Alternately, you can handle alert signups outside of Fossil, with |
|
d6e5754…
|
wyoung
|
97 |
a Setup or Admin users manually signing users up via Admin → |
|
d6e5754…
|
wyoung
|
98 |
Notification. You'll want to grant this capability to the |
|
d6e5754…
|
wyoung
|
99 |
<tt>nobody</tt> user category if you want anyone to sign up without any |
|
d6e5754…
|
wyoung
|
100 |
restrictions. Give it to <tt>anonymous</tt> instead if you want the |
|
d6e5754…
|
wyoung
|
101 |
user to solve a simple CAPTCHA before signing up. Or, give it to |
|
d6e5754…
|
wyoung
|
102 |
<tt>reader</tt> or <tt>developer</tt> if you want only users with Fossil |
|
d6e5754…
|
wyoung
|
103 |
logins to have this ability. (That's assuming you give one or both of |
|
d6e5754…
|
wyoung
|
104 |
these capabilities to every user on your Fossil repository.) |
|
f85bc32…
|
wyoung
|
105 |
|
|
f85bc32…
|
wyoung
|
106 |
By following this advice, you should not need to tediously add |
|
5d75504…
|
wyoung
|
107 |
capabilities to individual accounts except in atypical cases, such as |
|
779ddef…
|
wyoung
|
108 |
to grant the <b>[./caps/ref.html#5 | ModForum]</b> capability to an uncommonly |
|
f85bc32…
|
wyoung
|
109 |
highly-trusted user. |
|
f85bc32…
|
wyoung
|
110 |
|
|
f85bc32…
|
wyoung
|
111 |
|
|
6b27520…
|
wyoung
|
112 |
<h3 id="skin">Skin Setup</h3> |
|
3ec8f0a…
|
wyoung
|
113 |
|
|
3ec8f0a…
|
wyoung
|
114 |
If you create a new Fossil repository with version 2.7 or newer, its |
|
3ec8f0a…
|
wyoung
|
115 |
default skin is already set up correctly for typical forum |
|
3ec8f0a…
|
wyoung
|
116 |
configurations. |
|
3ec8f0a…
|
wyoung
|
117 |
|
|
04d4bde…
|
wyoung
|
118 |
If you have an existing repository, you have two choices if you want its |
|
04d4bde…
|
wyoung
|
119 |
skin to be upgraded to support forums: |
|
04d4bde…
|
wyoung
|
120 |
|
|
34a3bc1…
|
wyoung
|
121 |
<ol> |
|
34a3bc1…
|
wyoung
|
122 |
<li>Go into Admin → Skins and switch from your current skin to |
|
34a3bc1…
|
wyoung
|
123 |
one of the stock skins. If you were on a stock skin, just switch away |
|
34a3bc1…
|
wyoung
|
124 |
from your current one to the actual stock skin, since they will be |
|
34a3bc1…
|
wyoung
|
125 |
different after the upgrade.</li> |
|
34a3bc1…
|
wyoung
|
126 |
|
|
34a3bc1…
|
wyoung
|
127 |
<li>If you have local customization that you do not want to throw |
|
34a3bc1…
|
wyoung
|
128 |
away, you can use the diff feature of Fossil's skin editor to show how |
|
34a3bc1…
|
wyoung
|
129 |
the skins differ.</li> |
|
34a3bc1…
|
wyoung
|
130 |
</ol> |
|
04d4bde…
|
wyoung
|
131 |
|
|
04d4bde…
|
wyoung
|
132 |
The remainder of this section summarizes the differences you're expected |
|
04d4bde…
|
wyoung
|
133 |
to see when taking option #2. |
|
04d4bde…
|
wyoung
|
134 |
|
|
04d4bde…
|
wyoung
|
135 |
The first thing is that you'll need to add something like the following |
|
04d4bde…
|
wyoung
|
136 |
to the Header part of the skin to create the navbar link: |
|
3ec8f0a…
|
wyoung
|
137 |
|
|
3ec8f0a…
|
wyoung
|
138 |
<verbatim> |
|
6c9755b…
|
wyoung
|
139 |
if {[anycap 23456] || [anoncap 2] || [anoncap 3]} { |
|
6c9755b…
|
wyoung
|
140 |
menulink /forum Forum |
|
6c9755b…
|
wyoung
|
141 |
} |
|
3ec8f0a…
|
wyoung
|
142 |
</verbatim> |
|
3ec8f0a…
|
wyoung
|
143 |
|
|
779ddef…
|
wyoung
|
144 |
These rules say that any logged-in user with any [./caps/ref.html#2 | |
|
779ddef…
|
wyoung
|
145 |
forum-related capability] or an anonymous user <b>RdForum</b> or |
|
779ddef…
|
wyoung
|
146 |
<b>WrForum</b> capability will see the "Forum" navbar |
|
3ec8f0a…
|
wyoung
|
147 |
link, which just takes you to <tt>/forum</tt>. |
|
3ec8f0a…
|
wyoung
|
148 |
|
|
3ec8f0a…
|
wyoung
|
149 |
The exact code you need here varies depending on which skin you're |
|
3ec8f0a…
|
wyoung
|
150 |
using. Follow the style you see for the other navbar links. |
|
3ec8f0a…
|
wyoung
|
151 |
|
|
0194fb6…
|
wyoung
|
152 |
The new forum feature also brings many new CSS styles to the table. If |
|
0194fb6…
|
wyoung
|
153 |
you're using the stock skin or something sufficiently close, the changes |
|
0194fb6…
|
wyoung
|
154 |
may work with your existing skin as-is. Otherwise, you might need to |
|
0194fb6…
|
wyoung
|
155 |
adjust some things, such as the background color used for the selected |
|
0194fb6…
|
wyoung
|
156 |
forum post: |
|
0194fb6…
|
wyoung
|
157 |
|
|
0194fb6…
|
wyoung
|
158 |
<verbatim> |
|
6c9755b…
|
wyoung
|
159 |
div.forumSel { |
|
6c9755b…
|
wyoung
|
160 |
background-color: rgba(0, 0, 0, 0.05); |
|
6c9755b…
|
wyoung
|
161 |
} |
|
0194fb6…
|
wyoung
|
162 |
</verbatim> |
|
0194fb6…
|
wyoung
|
163 |
|
|
0194fb6…
|
wyoung
|
164 |
That overrides the default — a hard-coded light cyan — with a 95% |
|
0194fb6…
|
wyoung
|
165 |
transparent black overlay instead, which simply darkens your skin's |
|
0194fb6…
|
wyoung
|
166 |
normal background color underneath the selected post. That should work |
|
0194fb6…
|
wyoung
|
167 |
with almost any background color except for very dark background colors. |
|
0194fb6…
|
wyoung
|
168 |
For dark skins, an inverse of the above trick will work better: |
|
0194fb6…
|
wyoung
|
169 |
|
|
0194fb6…
|
wyoung
|
170 |
<verbatim> |
|
6c9755b…
|
wyoung
|
171 |
div.forumSel { |
|
6c9755b…
|
wyoung
|
172 |
background-color: rgba(255, 255, 255, 0.05); |
|
6c9755b…
|
wyoung
|
173 |
} |
|
0194fb6…
|
wyoung
|
174 |
</verbatim> |
|
0194fb6…
|
wyoung
|
175 |
|
|
0194fb6…
|
wyoung
|
176 |
That overlays the background with 5% white to lighten it slightly. |
|
04d4bde…
|
wyoung
|
177 |
|
|
04d4bde…
|
wyoung
|
178 |
Another new forum-related CSS style you might want to reflect into your |
|
04d4bde…
|
wyoung
|
179 |
existing skin is: |
|
04d4bde…
|
wyoung
|
180 |
|
|
04d4bde…
|
wyoung
|
181 |
<verbatim> |
|
6c9755b…
|
wyoung
|
182 |
div.forumPosts a:visited { |
|
6c9755b…
|
wyoung
|
183 |
color: #6A7F94; |
|
6c9755b…
|
wyoung
|
184 |
} |
|
04d4bde…
|
wyoung
|
185 |
</verbatim> |
|
04d4bde…
|
wyoung
|
186 |
|
|
04d4bde…
|
wyoung
|
187 |
This changes the clicked-hyperlink color for the forum post links on the |
|
34a3bc1…
|
wyoung
|
188 |
main <tt>/forum</tt> page only, which allows your browser's history |
|
34a3bc1…
|
wyoung
|
189 |
mechanism to show which threads a user has read and which not. The link |
|
34a3bc1…
|
wyoung
|
190 |
color will change back to the normal link color — indicating "unread" — |
|
34a3bc1…
|
wyoung
|
191 |
when a reply is added to an existing thread because that changes where |
|
34a3bc1…
|
wyoung
|
192 |
the link from the <tt>/forum</tt> page points, taking you to the newest |
|
34a3bc1…
|
wyoung
|
193 |
post in the thread. |
|
04d4bde…
|
wyoung
|
194 |
|
|
04d4bde…
|
wyoung
|
195 |
The color given above is suitable for the stock skin. |
|
04d4bde…
|
wyoung
|
196 |
|
|
34a3bc1…
|
wyoung
|
197 |
Beware that when changing this example, there are some |
|
34a3bc1…
|
wyoung
|
198 |
[https://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-css-vistited/ |
|
34a3bc1…
|
wyoung
|
199 |
| stringent restrictions] in modern browsers to prevent snoopy web sites |
|
34a3bc1…
|
wyoung
|
200 |
from brute-forcing your browsing history. (See the link for the method, |
|
34a3bc1…
|
wyoung
|
201 |
which explains the restrictions.) |
|
03c298d…
|
wyoung
|
202 |
|
|
cc5d2e1…
|
wyoung
|
203 |
|
|
03c298d…
|
wyoung
|
204 |
<h3 id="search">Enable Forum Search</h3> |
|
cc5d2e1…
|
wyoung
|
205 |
|
|
cc5d2e1…
|
wyoung
|
206 |
One of the underlying assumptions of the forum feature is that you will |
|
cc5d2e1…
|
wyoung
|
207 |
want to be able to search the forum archives, so the <tt>/forum</tt> |
|
cc5d2e1…
|
wyoung
|
208 |
page always includes a search box. Since that depends on search being |
|
cc5d2e1…
|
wyoung
|
209 |
enabled on the Fossil repository, Fossil warns that search is disabled |
|
cc5d2e1…
|
wyoung
|
210 |
until you go into Admin → Search and enable the "Search Forum" |
|
cc5d2e1…
|
wyoung
|
211 |
setting. |
|
cc5d2e1…
|
wyoung
|
212 |
|
|
cc5d2e1…
|
wyoung
|
213 |
You may want to enable some of the other Fossil search features while |
|
cc5d2e1…
|
wyoung
|
214 |
you're in there. All of this does come at some CPU and I/O cost, which |
|
cc5d2e1…
|
wyoung
|
215 |
is why it's disabled by default. |
|
cc5d2e1…
|
wyoung
|
216 |
|
|
3ec8f0a…
|
wyoung
|
217 |
|
|
03c298d…
|
wyoung
|
218 |
<h3 id="sso">Single Sign-On</h3> |
|
4ed14b1…
|
wyoung
|
219 |
|
|
4ed14b1…
|
wyoung
|
220 |
If you choose to host your discussion forums within the same repository |
|
dd0a2dd…
|
wyoung
|
221 |
as your project's other Fossil-managed content, you inherently have a |
|
dd0a2dd…
|
wyoung
|
222 |
single sign-on system. Contrast third-party mailing list and forum |
|
dd0a2dd…
|
wyoung
|
223 |
software where you either end up with two separate user tables and |
|
dd0a2dd…
|
wyoung
|
224 |
permission sets, or you must go to significant effort to integrate the |
|
dd0a2dd…
|
wyoung
|
225 |
two login systems. |
|
dd0a2dd…
|
wyoung
|
226 |
|
|
bc303c0…
|
wyoung
|
227 |
You may instead choose to host your forums in a Fossil repository |
|
bc303c0…
|
wyoung
|
228 |
separate from your project's main Fossil repository. A good reason to do |
|
bc303c0…
|
wyoung
|
229 |
this is that you have a public project where very few of those |
|
bc303c0…
|
wyoung
|
230 |
participating in the forum have special capability bits for project |
|
bc303c0…
|
wyoung
|
231 |
assets managed by Fossil, so you wish to segregate the two user sets. |
|
bc303c0…
|
wyoung
|
232 |
|
|
bc303c0…
|
wyoung
|
233 |
Yet, what of the users who will have logins on both repositories? Some |
|
bc303c0…
|
wyoung
|
234 |
users will be trusted with access to the project's main Fossil |
|
bc303c0…
|
wyoung
|
235 |
repository, and these users will probably also participate in the |
|
60c586d…
|
wyoung
|
236 |
project's Fossil-hosted forum. Fossil has a feature to solve this |
|
779ddef…
|
wyoung
|
237 |
problem: [./caps/login-groups.md | login groups]. |
|
2ef70be…
|
wyoung
|
238 |
|
|
2ef70be…
|
wyoung
|
239 |
|
|
2ef70be…
|
wyoung
|
240 |
<h3 id="alerts">Email Alerts (a.k.a. Notifications)</h3> |
|
2ef70be…
|
wyoung
|
241 |
|
|
2ef70be…
|
wyoung
|
242 |
Internet email service has become rather complicated since its initial |
|
2ef70be…
|
wyoung
|
243 |
simple and insecure implementation decades ago. Fossil's role in all of |
|
2ef70be…
|
wyoung
|
244 |
this is rather small at the moment, but the details of the integration |
|
2ef70be…
|
wyoung
|
245 |
are complex enough to justify [./alerts.md | a separate document]. |
|
2ef70be…
|
wyoung
|
246 |
|
|
ba35b5f…
|
wyoung
|
247 |
(The other reason that document is separate is that Fossil's email |
|
ba35b5f…
|
wyoung
|
248 |
alerts system also gets used by features of Fossil other than the |
|
ba35b5f…
|
wyoung
|
249 |
forum.) |
|
2ef70be…
|
wyoung
|
250 |
|
|
2ef70be…
|
wyoung
|
251 |
|
|
2ef70be…
|
wyoung
|
252 |
<h2 id="access">Accessing the Forum</h2> |
|
2ef70be…
|
wyoung
|
253 |
|
|
2ef70be…
|
wyoung
|
254 |
There are many paths to a repository's Fossil forum: |
|
2ef70be…
|
wyoung
|
255 |
|
|
2ef70be…
|
wyoung
|
256 |
<ul> |
|
2ef70be…
|
wyoung
|
257 |
<li> |
|
779ddef…
|
wyoung
|
258 |
If you're using the default Fossil skin as shipped with Fossil |
|
779ddef…
|
wyoung
|
259 |
2.7+ or one [#skin | updated] to support it, there |
|
779ddef…
|
wyoung
|
260 |
is a Forum button in the navbar which appears for users able to |
|
779ddef…
|
wyoung
|
261 |
access the forum. With the default skin, that button will only |
|
779ddef…
|
wyoung
|
262 |
appear if the user's browser window is at least |
|
779ddef…
|
wyoung
|
263 |
1200 pixels wide. The |
|
2ef70be…
|
wyoung
|
264 |
Fossil admin can adjust this limit in the skin's CSS section, down |
|
779ddef…
|
wyoung
|
265 |
near the bottom in the definition of the `wideonly` style. |
|
2ef70be…
|
wyoung
|
266 |
</li> |
|
2ef70be…
|
wyoung
|
267 |
|
|
2ef70be…
|
wyoung
|
268 |
<li>The other stock skins have this button in them as of 2.7 as well, |
|
2ef70be…
|
wyoung
|
269 |
without the screen width restriction, since the navbar in those skins |
|
2ef70be…
|
wyoung
|
270 |
wraps on narrow screens more gracefully than the default skin |
|
2ef70be…
|
wyoung
|
271 |
does.</li> |
|
2ef70be…
|
wyoung
|
272 |
|
|
2ef70be…
|
wyoung
|
273 |
<li>Users who set up their Fossil repository under prior versions and |
|
2ef70be…
|
wyoung
|
274 |
who now have local skin changes they don't want to overwrite by |
|
2ef70be…
|
wyoung
|
275 |
reverting to the stock 2.7 version of the skin they chose to start |
|
2ef70be…
|
wyoung
|
276 |
with can easily [#skin | edit their skin] to include these links.</li> |
|
2ef70be…
|
wyoung
|
277 |
|
|
2ef70be…
|
wyoung
|
278 |
<li>A "Forum" link appears in the drop-down panel when you click the |
|
0794315…
|
wyoung
|
279 |
default skin's hamburger menu (☰) while logged in as any user |
|
0794315…
|
wyoung
|
280 |
with one or more of the [#caps | user capabilities listed above].</li> |
|
2ef70be…
|
wyoung
|
281 |
|
|
0794315…
|
wyoung
|
282 |
<li>That same link also appears on the repository's <tt>/sitemap</tt> |
|
0794315…
|
wyoung
|
283 |
page, since it provides the content for the hamburger menu's |
|
0794315…
|
wyoung
|
284 |
panel.</li> |
|
2ef70be…
|
wyoung
|
285 |
</ul> |
|
812dd52…
|
wyoung
|
286 |
|
|
812dd52…
|
wyoung
|
287 |
|
|
812dd52…
|
wyoung
|
288 |
<h2 id="moderation">How Moderation Works</h2> |
|
812dd52…
|
wyoung
|
289 |
|
|
c1be550…
|
wyoung
|
290 |
In this section, we're going to call all of the following a "forum |
|
c1be550…
|
wyoung
|
291 |
update:" |
|
c1be550…
|
wyoung
|
292 |
|
|
c1be550…
|
wyoung
|
293 |
* create a new post |
|
c1be550…
|
wyoung
|
294 |
* reply to an existing post |
|
c1be550…
|
wyoung
|
295 |
* edit a post or reply |
|
c1be550…
|
wyoung
|
296 |
|
|
779ddef…
|
wyoung
|
297 |
When a person with the normal <b>WrForum</b> capability |
|
c1be550…
|
wyoung
|
298 |
updates the forum, Fossil saves the update in its block chain, but this |
|
c1be550…
|
wyoung
|
299 |
update is impermanent because of two other table updates made at the |
|
c1be550…
|
wyoung
|
300 |
same time: |
|
812dd52…
|
wyoung
|
301 |
|
|
812dd52…
|
wyoung
|
302 |
<ol> |
|
c1be550…
|
wyoung
|
303 |
<li>Fossil saves the update artifact's ID in its <tt>private</tt> |
|
c1be550…
|
wyoung
|
304 |
table, preventing Fossil from sending such artifacts to any of the |
|
812dd52…
|
wyoung
|
305 |
repository's clones. (This is the same mechanism behind |
|
812dd52…
|
wyoung
|
306 |
[./private.wiki | private branches].)</li> |
|
812dd52…
|
wyoung
|
307 |
|
|
c1be550…
|
wyoung
|
308 |
<li>Fossil also adds a reference to that artifact in the |
|
c1be550…
|
wyoung
|
309 |
<tt>modreq</tt> table, which backs the moderation feature. This is |
|
c1be550…
|
wyoung
|
310 |
what causes Fossil to leave out the Reply button when rendering that |
|
c1be550…
|
wyoung
|
311 |
post's HTML in the forum's web interface.</li> |
|
812dd52…
|
wyoung
|
312 |
</ol> |
|
812dd52…
|
wyoung
|
313 |
|
|
c1be550…
|
wyoung
|
314 |
When a moderator approves an update, Fossil deletes these table entries, |
|
779ddef…
|
wyoung
|
315 |
making the update [./shunning.wiki | semi-permanent]. This changes how Fossil renders the |
|
c1be550…
|
wyoung
|
316 |
HTML for that update. It also means the artifact will now sync to |
|
779ddef…
|
wyoung
|
317 |
users with <b>[./caps/ref.html#g | Clone]</b> capability. |
|
812dd52…
|
wyoung
|
318 |
|
|
812dd52…
|
wyoung
|
319 |
When a forum user edits a moderator-approved artifact, what actually |
|
812dd52…
|
wyoung
|
320 |
happens under the hood is that Fossil writes another artifact to the |
|
812dd52…
|
wyoung
|
321 |
repository which refers to the original version as its parent, causing |
|
812dd52…
|
wyoung
|
322 |
Fossil UI to present the new version instead of the original. The |
|
812dd52…
|
wyoung
|
323 |
original version remains in the repository, just as with historical |
|
812dd52…
|
wyoung
|
324 |
checkins. The parent must remain in the repository for referential |
|
812dd52…
|
wyoung
|
325 |
integrity purposes. |
|
812dd52…
|
wyoung
|
326 |
|
|
c1be550…
|
wyoung
|
327 |
When you "Delete" a moderator-approved post or reply through Fossil UI, |
|
c1be550…
|
wyoung
|
328 |
it's actually an edit with blank replacement content. The only way to |
|
c1be550…
|
wyoung
|
329 |
truly delete such artifacts is through [./shunning.wiki | shunning]. |
|
c1be550…
|
wyoung
|
330 |
|
|
779ddef…
|
wyoung
|
331 |
When a user with <b>WrTForum</b> capability |
|
2642476…
|
wyoung
|
332 |
updates the forum, it happens in the same way except that Fossil skips |
|
2642476…
|
wyoung
|
333 |
the <tt>private</tt> and <tt>modreq</tt> table insertions. |
|
c1be550…
|
wyoung
|
334 |
|
|
c1be550…
|
wyoung
|
335 |
When a moderator rejects an update, that artifact is unceremoniously |
|
c1be550…
|
wyoung
|
336 |
removed from the tip of the block chain. This is safe because Fossil |
|
2642476…
|
wyoung
|
337 |
prevents replies to a reply or post awaiting moderator approval, so |
|
2642476…
|
wyoung
|
338 |
referential integrity cannot be harmed. Rejecting an edit is even |
|
2642476…
|
wyoung
|
339 |
safer, since the original post remains behind, so that replies continue |
|
2642476…
|
wyoung
|
340 |
to refer to that original post. |
|
812dd52…
|
wyoung
|
341 |
|
|
812dd52…
|
wyoung
|
342 |
|
|
812dd52…
|
wyoung
|
343 |
<h2 id="mod-user">Using the Moderation Feature</h2> |
|
812dd52…
|
wyoung
|
344 |
|
|
2642476…
|
wyoung
|
345 |
Having described all of the work that Fossil performs under the hood on |
|
2642476…
|
wyoung
|
346 |
behalf of its users, we can now give the short list of work left for the |
|
2642476…
|
wyoung
|
347 |
repository's administrators and moderators: |
|
812dd52…
|
wyoung
|
348 |
|
|
812dd52…
|
wyoung
|
349 |
<ol> |
|
779ddef…
|
wyoung
|
350 |
<li>Add the <b>[./caps/ref.html#5 | ModForum]</b> capability to any of |
|
812dd52…
|
wyoung
|
351 |
your users who should have this ability. You don't need to do this |
|
779ddef…
|
wyoung
|
352 |
for any user with <b>[./caps/ref.html#s | Setup]</b> or |
|
779ddef…
|
wyoung
|
353 |
<b>[./caps/ref.html#a | Admin]</b> capability; it's |
|
143f1db…
|
wyoung
|
354 |
[/artifact/b16221ffb736caa2?ln=1246-1257 | already included].</li> |
|
31631b7…
|
wyoung
|
355 |
|
|
31631b7…
|
wyoung
|
356 |
<li>When someone updates the forum, an entry will appear in the |
|
31631b7…
|
wyoung
|
357 |
timeline if the type filter is set to "Forum" or "Any Type". If that |
|
779ddef…
|
wyoung
|
358 |
user has only the <b>WrForum</b> capability, any |
|
779ddef…
|
wyoung
|
359 |
other user with the <b>ModForum</b> capability |
|
31631b7…
|
wyoung
|
360 |
will see a conditional link appear at the top of the main forum |
|
31631b7…
|
wyoung
|
361 |
page: "Moderation Requests". Clicking this takes the moderator to |
|
31631b7…
|
wyoung
|
362 |
the <tt>/modreq</tt> page. A moderator may wish to keep the main |
|
31631b7…
|
wyoung
|
363 |
forum page open in a browser tab, reloading it occasionally to see |
|
31631b7…
|
wyoung
|
364 |
when the "Moderation Requests" link reappears.</li> |
|
31631b7…
|
wyoung
|
365 |
|
|
31631b7…
|
wyoung
|
366 |
<li>A moderator viewing an update pending moderation sees two |
|
31631b7…
|
wyoung
|
367 |
buttons at the bottom, "Approve" and "Reject" in place of the |
|
31631b7…
|
wyoung
|
368 |
"Delete" button that the post's creator sees. Beware that both |
|
31631b7…
|
wyoung
|
369 |
actions are durable and have no undo. Be careful!</li> |
|
812dd52…
|
wyoung
|
370 |
</ol> |
|
c2b38f0…
|
stephan
|
371 |
|
|
c2b38f0…
|
stephan
|
372 |
<h2 id="close-post">Closing Forum Posts</h2> |
|
c2b38f0…
|
stephan
|
373 |
|
|
c2b38f0…
|
stephan
|
374 |
As of version 2.23, the forum interface supports the notion of |
|
c2b38f0…
|
stephan
|
375 |
"closing" posts. By default, only users with the [./caps/index.md|'s' |
|
c2b38f0…
|
stephan
|
376 |
and 'a' capabilities] may close or re-open posts, or reply to closed |
|
c64f28d…
|
drh
|
377 |
posts. If the [/help/forum-close-policy|forum-close-policy |
|
c2b38f0…
|
stephan
|
378 |
configuration option] is enabled then users with |
|
c2b38f0…
|
stephan
|
379 |
[./caps/index.md|forum-moderator permissions] may also perform those |
|
c2b38f0…
|
stephan
|
380 |
actions. |
|
c2b38f0…
|
stephan
|
381 |
|
|
c2b38f0…
|
stephan
|
382 |
Closing a post has the following implications: |
|
c2b38f0…
|
stephan
|
383 |
|
|
c2b38f0…
|
stephan
|
384 |
* Only authorized users may edit or respond to such posts, recursively |
|
c2b38f0…
|
stephan
|
385 |
through all responses of that post. |
|
c2b38f0…
|
stephan
|
386 |
* Only authorized users may re-open a closed post. |
|
c2b38f0…
|
stephan
|
387 |
|
|
c2b38f0…
|
stephan
|
388 |
A forum thread may be closed at any given point in the conversation, |
|
c2b38f0…
|
stephan
|
389 |
not just the starting point of the thread, and affects that specific |
|
c2b38f0…
|
stephan
|
390 |
post and all existing responses to it. |
|
c2b38f0…
|
stephan
|
391 |
|
|
c2b38f0…
|
stephan
|
392 |
Note that closing a post is effectively an "advisory lock" and may be |
|
c2b38f0…
|
stephan
|
393 |
bypassed. Any user, admin or otherwise, who can push changes to a |
|
c2b38f0…
|
stephan
|
394 |
repository may bypass closure of a post by setting the appropriate |
|
c2b38f0…
|
stephan
|
395 |
artifact tags on a local copy and pushing those changes to a remote |
|
c2b38f0…
|
stephan
|
396 |
copy of the forum. |
|
c2b38f0…
|
stephan
|
397 |
|
|
420d6e7…
|
stephan
|
398 |
The option to close a post, permissions permitting, appears as a |
|
420d6e7…
|
stephan
|
399 |
"Close" button on the currently-selected post. If the selected post is |
|
420d6e7…
|
stephan
|
400 |
alread closed, a "Re-open" button will be shown instead. In order to |
|
420d6e7…
|
stephan
|
401 |
re-open a post, <em>the closed post itself</em> must be |
|
420d6e7…
|
stephan
|
402 |
selected. Selecting a response to that post, which is implicitly |
|
420d6e7…
|
stephan
|
403 |
closed by the closure of its parent, will <em>not</em> offer a re-open |
|
420d6e7…
|
stephan
|
404 |
option. |
|
c2b38f0…
|
stephan
|
405 |
|
|
c2b38f0…
|
stephan
|
406 |
Though forum users are permitted to delete their own posts, they are |
|
c2b38f0…
|
stephan
|
407 |
not permitted, without appropriate permissions, to close their own |
|
c2b38f0…
|
stephan
|
408 |
posts. This is intentional, as closing one's own post can be used to |
|
420d6e7…
|
stephan
|
409 |
antagonize other forum users. For example, by posting something |
|
285430a…
|
drh
|
410 |
trollish or highly controversial in nature and closing the post to |
|
c2b38f0…
|
stephan
|
411 |
further responses. |