Revision as of 11:35, 25 January 2015

Dreamwidth controls which users may access administrative areas of the site by means of 'privileges', commonly called 'privs'. There's a run-down about how things are in the code, here.

A list of all available privileges and their basic definitions: http://www.dreamwidth.org/admin/priv/

An index of pages where you can do things with privs: http://www.dreamwidth.org/admin/ (substitute your own site name as necessary)

More detailed discussion for various privs follows below.

Administrative

admin:* : The meta-privilege to grant any privilege to self or any other account. (Accounts having this privilege must still grant themselves other privs one leg at a time like everyone else.)

This privilege is initially granted to the System account, by running the make_system.pl command; once this command is run, the system account may grant it to any other account.

Support

These are the privileges that are used by or around the support board, what they do, and how they work. (There are some other privs that can be useful for support-related tasks, but those will be explained elsewhere.) They are listed in order from "ones we're most willing to give out to anyone who's interested in volunteering" to "ones that are reserved for the most experienced support volunteers and/or support category coordinators".

For information on the support process itself, see Support process.

All of these privs can be "unarged", or support-wide, or "categorized", granted only for a specific support category. For instance, you might have supportviewscreened in all categories, but supporthelp only in Entries.

• supportviewscreened: This priv lets a user view Screened Responses on a request. Screened responses are responses that other users have submitted to the request that have not yet been verified. This priv is useful for seeing whether or not a request already has an answer submitted to it that has not been verified and approved, preventing you from re-answering a request that already has an approvable answer. It's still okay to submit a new screened response if you think that the existing responses don't adequately address the user's concern. You shouldn't critique the existing answers, though; just write your own.

• supportmakeinternal: This priv lets a user submit Internal Comments (ICs) on a request. Internal comments are a way of communicating important information to the person who'll be reviewing the request and approving an answer on it. If you notice something important, but not immediately obvious, about a user's account that affects the answer you gave, you can use an IC to explain why you answered the way you did. It isn't necessary to use an IC to justify your answer if there isn't anything unusual about it, and don't ever use an IC to critique existing answers on the request or explain why you chose to re-answer it.

• supportviewstocks: Each category can build up a repository of shared pre-written "stock" answers, that can cover a multitude of common requests. This priv allows a user to view, access, and utilize these pre-written answers. It will generally be granted to people who've demonstrated that they can properly diagnose the root cause of a problem and appropriately rewrite and/or tailor a pre-written answer to the user's unique situation and their own voice. (Because of the personal nature of DW support, stock answers will be less-frequently used, and many of them will be more in the nature of checklist for what each type of answer will require, rather than pre-scripted language.)

• supportmovetouch: This priv allows a user to shift a request from one category to another -- either back and forth between public categories, or into private categories. If you have supportmovetouch, you can move a request into a category that you can't actually see, so move with care, lest someone from staff need to fish it back out again. It also allows someone to take a request out of the queue (changing the status from "open" or "answered, still needs help" to "answered, awaiting close") or put a request back into the queue (changing the status from "answered, awaiting close" to "answered, still needs help") if a request doesn't need further response or an answered request needs further attention.

• supportviewinternal: This priv allows a user to read any internal comments (ICs) that have been left on a request. Because these can sometimes contain more sensitive information, it's reserved for people who've demonstrated both commitment to support and the ability to respect confidential information.

• supportchangesummary: This priv allows a user to change the displayed Summary on a support request. The new summary is visible to both the user and anyone else viewing the request, so this priv is reserved for people who've demonstrated the ability to provide accurate and clear information to users without confusion or complication.

• supporthelp: This priv allows a user to do all of the above, plus approve screened responses (their own or others') as answers or comments, plus make answers or comments without having to submit a screened response first. It will be reserved for people who've demonstrated a high commitment to customer service, an ability to properly diagnose problems (or properly lead the user through the initial diagnosis steps), and the wisdom to know when they don't know the answer and they should leave the request alone.

• supportclose: This priv allows a user to close requests that haven't been closed by the user, both quality-checking responses (and alerting a category coordinator if someone needs to be retrained on an issue or a procedure) and making sure that all answered requests have fully answered the user's question. It also involves knowing when a user has abandoned a request and the support team doesn't need to provide further followup, or being willing to investigate a user's journal to see if the situation has resolved itself. This priv is reserved for category coordinators and their administrative delegates.

• supportread: This is a special priv that allows users access to the nonpublic support categories. All of the above support privs apply to those categories as well, but users can't even see a private request unless they have supportread in that category (or were the user who filed the request). In general, since Dreamwidth uses private categories for a). sensitive information, b). specific business-related tasks, or c). staff contact, access to private categories will be limited.

To request support privs, comment to the dw_support_training entry for this purpose.

Abuse

Anti-Spam

Viewing spam reports, creating sysbans.

• siteadmin:spamreports -- Required.
• sysban:talk_ip_test ( to force IP addresses to see a captcha )

Also potentially relevant

• suspend::openid ( to suspend openid accounts )

FAQ

More detailed discussion in FAQ backend guide.