Subsections


3.3 Users and Stories

Scoop has a permission and group system that allows you to customize which users can and cannot do what on your site.

3.3.1 Accounts

Account creation is automated and easy. It requires a user to provide a working email address, so Scoop can send them their first password; it also requires you to configure Scoop to be able to successfully send email with a valid From: address (covered in section 3.2).

If Scoop's email address is invalid, it will tell a new user trying to create an account that it's the user's email address that is invalid.

Beside the username in all stories and comments, as well as on the User Info page, an ``Edit User'' link will let you edit that user's User Info, as well as change their username and group, and add notes about that user that only administrators can see, such as keeping a record of abuses so the account can have its permissions reduced appropriately if necessary.

It's generally not a good idea to delete a user unless the account was just created and hadn't really done anything, because there is so much stuff tied to the userid and to that stuff (i.e., a user has comments, those comments have replies). Accounts which are created and post nothing but abusive comments and stories are generally the only accounts that should be deleted.

If somebody goes on an unfair rating rampage, their ratings can be reversed. To revoke their rating abilities at the same time, you have to create a more restricted group that is missing that permission, then put that group's name in the site control `rating_wipe_group', in the Security category.


3.3.2 Groups

For a small site, you will generally only need three groups: Superuser, Users, and Anonymous. Nearly all registered users will be in the group Users, you, as the administrator, will be in the Superuser group, and anybody not logged in will be in the Anonymous group.

For a larger site, the groups Admin and Editor come in handy. Generally speaking, somebody in the Admin group should have administrative access to the site so they can fix things that break - such as blocks, boxes, and so on. Somebody in the Editor group should have permission to change other people's stories, so they can fix typos, kick a story into or out of the edit queue, and so on.

For still larger sites, or sites with more specialized needs, other groups can be used and created at will, such as a Subscribers group if the site uses a subscription model, or a more limited group for users who have abused their privileges.


3.3.3 Permissions

The group a user is placed in determines what they are allowed to do on the site; what each group is allowed to do depends on the permissions given in the Groups Admin Tool (A.12).

Most of the permissions are fairly self-explanatory, such as comment_post, which determines whether or not a user is allowed to post a comment. All permissions are described in appendix A.12, along with warnings and recommendations for their use.

More than half of the permissions are for administrative stuff. All but one determine whether or not the user can perform an action; the one exception is super_mojo, which basically means that regardless of comment ratings, users in that group are always considered trusted.

The Superuser should have all permissions checked at all times.

Warning: if a group has permission to edit users and groups, members of that group can give themselves and others superuser privileges. Just because it's a website, don't think somebody with superuser privileges can't hose your system; Scoop's box system can run any command on your system--including starting a daemon, or fetching the daemon (or trojan!) first, then starting it--and present the output to a person viewing the page in any way the box creator wants.

Permissions are checked both when an action is attempted and when building the page; somebody without the comment_post permission, for example, simply will not see the ``Reply to this'' and ``Post a comment'' links anywhere.

If you ever need to add a new permission, the master list is stored in the variable ``perms''. When you add a new perm it will default to being unselected for all groups. If for any reason you delete a perm from that list, the perm will still be set for all users that formerly had it, so make sure you've removed the permission from the groups first.

There are also section permissions, allowing you to have read-only or admin-only sections, as well as allowing certain groups to automatically post and bypass the queue. Those settings can be useful in several situations, including a ``Site News'' style section, in which normal users cannot post stories but the site administrator can automatically post to the section. These are available in the Sections Admin Tool (A.9). Using those permissions, an admin-only section, for example, can use either ``Hide'', where Scoop pretends that the section doesn't exist for that user, or ``Deny'', where Scoop admits that the section exists and tells the user he doesn't have permission to see it.


3.3.4 Publishing Stories

Scoop uses a democratic model of publishing by default; that is, unlike most weblogs which have a limited number of people choosing what to post, any registered user can vote on what stories to publish and where. Which users can submit stories and vote is controlled by their group permissions (see section 3.3).

If you have enabled the `edit queue' (see section 4.1.1) and the user has chosen to use it, he can change his story according to `editorial' comments other users offer to help improve it to the point where it can be moved on to the voting queue.

When the user is satisfied or a time limit is reached, the story is moved from the edit queue to the voting queue, and can then be voted on. If the edit queue isn't active, all stories go immediately to the voting queue. Other users then cast their vote; either +1 (post), -1 (drop), or 0 (abstain). The votes are added up using the methods described in section 4.1.2, and when the story reaches one of the thresholds, the story is either posted or dropped. All of the limits can be configured through the Site Controls Admin Tool, in the Stories category.

If there are not enough people to vote a story up, the Superuser can force a story to be published--this is common in brand new sites. By clicking the `edit' link in the story then setting the dropdown box just under the title to ``Always Display'' a story can be published on the front page regardless of votes.

If you don't want to use Scoop's story voting mechanism but just let yourself or maybe a few people post stories at will, you can take away normal users' ability to post stories or vote using the Groups Admin Tool, then use the Sections Admin Tool to give your group the ability to auto-post stories to the front page or the section page, whichever you prefer.


janra
2004-03-26