117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
to properly support SMTP email in this complex world we've built.
As well, this design choice means you do not need to do duplicate
configuration, such as to point Fossil at your server's TLS
certificate private key in order to support users behind mail
servers that require STARTTLS encryption.
<h2>Setting up aFossil Forum</h2>
<h3>Permissions</h3>
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
|
|
|
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
to properly support SMTP email in this complex world we've built.
As well, this design choice means you do not need to do duplicate
configuration, such as to point Fossil at your server's TLS
certificate private key in order to support users behind mail
servers that require STARTTLS encryption.
<h2>Setting up a Fossil Forum</h2>
<h3>Permissions</h3>
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
|
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
|
this is that you have a public project where very few of those
participating in the forum have special capability bits for project
assets managed by Fossil, so you wish to segregate the two user sets.
Yet, what of the users who will have logins on both repositories? Some
users will be trusted with access to the project's main Fossil
repository, and these users will probably also participate in the
project's Fossil-hosted forum.
Fossil has a feature to solve this problem that is probably less well
known than it should be, which has been in the software since April of
2011: Admin → Login-Group, which allows one Fossil repository to
recognize users authorized on another Fossil repository.
<h3>Email Notification</h3>
See [./emaildesign.md | the email notification design document] for now.
More administration-oriented documentation TODO.
|
|
|
<
|
|
|
|
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
|
this is that you have a public project where very few of those
participating in the forum have special capability bits for project
assets managed by Fossil, so you wish to segregate the two user sets.
Yet, what of the users who will have logins on both repositories? Some
users will be trusted with access to the project's main Fossil
repository, and these users will probably also participate in the
project's Fossil-hosted forum. Fossil has a feature to solve this
problem which is probably less well known than it should be, and which
has been a feature of Fossil since April of 2011: Admin →
Login-Group. This allows one Fossil repository to recognize users
authorized on a different Fossil repository.
<h3>Email Notification</h3>
See [./emaildesign.md | the email notification design document] for now.
More administration-oriented documentation TODO.
|