Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | More tweaks to the forum.wiki doc |
---|---|
Downloads: | Tarball | ZIP archive | SQL archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: | 5d75504af03e0451a7dde0d6d1749b3c |
User & Date: | wyoung 2018-08-08 19:30:23 |
Context
2018-08-08
| ||
19:43 | More SSO discussion improvements in forum.wiki check-in: bc303c0e user: wyoung tags: trunk | |
19:30 | More tweaks to the forum.wiki doc check-in: 5d75504a user: wyoung tags: trunk | |
19:25 | Small tweak to the advice for "reader" category capability for forums check-in: ea67aade user: wyoung tags: trunk | |
Changes
Changes to www/forum.wiki.
78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 ... 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 ... 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 |
<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 permsissions for forums: * <b>Read</b>: The user may read forum posts * <b>Write</b>: The user may create new forum threads and reply to existing threads. New posts are held for moderation. * <b>Write Trusted</b>: Same as <b>Write</b>, but posts are inserted into the block chain immediately without being held for moderation. * <b>Moderate</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>Administer</b>: User can grant <b>Write Trusted</b> permission to another user, or revoke it. (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 ................................................................................ For a private repository, you probably won't want to give the <tt>anonymous</tt> user any forum access, but you may wish to give capability "2" to the <tt>reader</tt> user category. For either type of repository, you are likely to want to give at least the Write Trusted (4) capability to the <tt>developer</tt> user category. 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. <h3>Skin Setup</h3> If you create a new Fossil repository with version 2.7 or newer, its ................................................................................ software where you either end up with two separate user tables and permission sets, or you must go to significant effort to integrate the two login systems. You may instead choose to host your forums in a separate Fossil repository from your other assets. A good reason to do this is that you have a public project where very few of those participating in the forum have special permissions for assets managed by Fossil for the project itself, so you wish to segregate the two user sets. Fossil offers a way to split the difference: you can host your forum in a repository separate from your other Fossil-managed content yet still have single sign-on for that common set of users that will have logins on both repositories. Simply enable Fossil's login groups feature in Admin → Login-Group, which allows one Fossil repository to recognize users authorized on another repository. |
| > | | > > | | | |
78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 ... 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 ... 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 |
<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 a user: * <b>Read</b>: The user may read forum posts * <b>Write</b>: The user may create new forum threads and reply to existing threads. New posts are held for moderation. * <b>Write Trusted</b>: Same as <b>Write</b>, but posts are inserted into the block chain immediately without being held for moderation. * <b>Moderate</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>Administer</b>: User can grant <b>Write Trusted</b> capability to another user, or revoke it. (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 ................................................................................ For a private repository, you probably won't want to give the <tt>anonymous</tt> user any forum access, but you may wish to give capability "2" to the <tt>reader</tt> user category. For either type of repository, you are likely to want to give at least the Write Trusted (4) capability to the <tt>developer</tt> user category. If you did not give forum read 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. <h3>Skin Setup</h3> If you create a new Fossil repository with version 2.7 or newer, its ................................................................................ software where you either end up with two separate user tables and permission sets, or you must go to significant effort to integrate the two login systems. You may instead choose to host your forums in a separate Fossil repository from your other assets. A good reason to do this is that you have a public project where very few of those participating in the forum have special capability bits for assets managed by Fossil for the project itself, so you wish to segregate the two user sets. Fossil offers a way to split the difference: you can host your forum in a repository separate from your other Fossil-managed content yet still have single sign-on for that common set of users that will have logins on both repositories. Simply enable Fossil's login groups feature in Admin → Login-Group, which allows one Fossil repository to recognize users authorized on another repository. |