Privileges

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.

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. It's a good idea to grant admin:* to the account you'll be doing the majority of your development/testing with to save you the trouble of having to log in and out of the system account.

If you want to grant an account the ability to grant only one priv, you add the name of that priv as the argument. For instance, if you want an account to be able to grant other accounts the supportread priv, and only the supportread priv, grant that account the priv admin:supportread.

You do not need to grant individual args to admin to an account that has admin:*: admin:* implies admin:supportread, etc.

Having admin:* doesn't automatically grant you all other privs. For an account that has admin:* to use the finduser console command, it still needs to explicitly be granted the finduser priv.

• allowopenproxy: Mostly obsolete/legacy holdover from LJ. During the height of LJ spam problems, the site blocked a number of IPs as open web proxies. This priv let an admin mark one of those proxies as "do not block" (in case an actual LJ user used that proxy). DW doesn't use it.

• canview: This priv governs whether you can override visibility levels and see data that may be considered sensitive. Accounts can be granted canview:*, which permits them to view all data, or canview with an argument, which restricts them to only the areas governed by that argument. If you have canview:*, you can view the entire contents of any journal (including locked and private entries) by adding ?viewall=1 to the end of the journal URL, or view locked entries (along with screened comments on any entry) by adding ?viewall=1 to the end of the entry URL. Arguments to canview are:

canview:entryprops: Allows you to use /admin/entryprops to look up metadata on a specific entry. (Subject, poster, journal, security level, date/time posted, date/time specified by user, number of comments, number of times the entry was edited, how the entry was posted, what options were set on the entry, etc.)

canview:sessions: Allows you to view the login sessions page of another user on /manage/logins.

canview:styles: Allows you to view non-public styles and layouts a user has created.

canview:suspended: Allows you to view public entries in a suspended or deleted journal (by adding ?viewall=1 to the end of the journal URL or entry URL). Does not override entry security: someone with this priv can't see locked entries.

canview:userlog: Allows you to look up userlog data about the user at /admin/userlog. (See note under historyview on the difference between userlog and statushistory.)

canview:userprops: Allows you to look up the userprops for a user at /admin/userprops.

You do not need to grant individual args to canview to an account that has canview:*: canview:* implies canview:suspended, etc.

• fileedit: Enables access to /admin/fileedit to edit file inclusions. Argument: The specific file inclusion that you want to enable someone to edit. (Mostly only used for support-currentproblems, which produces the "Known Issues" list on /support.) Arguments that fileedit will accept:

fileedit:accountcodes: not currently used

fileedit:common-passwords: a list of passwords the site will not allow you to use for your account

fileedit:reserved-usernames: a (regular expression) list of all variations that can't be registered as an account, in order to prevent 'official-looking' journals and to reserve subdomains for future use

fileedit:support-currentproblems: the document that generates the Known Issues list for /support

fileedit:support-links: a list that will be shown on /support with links to the most common questions (not currently used)

fileedit:tlds: a list of top level domains considered valid for the purpose of email addresses

fileedit:validationreminder: the text that will be automatically pre-filled into a support answer if the user has not confirmed their email address

You do not need to grant individual args to fileedit to an account that has fileedit:*: fileedit:* implies fileedit:support-currentproblems, etc.

• historyview: Enables access to view logged actions about the account at /admin/statushistory. Yes, we have two user account logging systems (/admin/statushistory and /admin/userlog). Yes, what gets logged to which is somewhat arbitrary. Generally speaking, if it's an action taken by the user (deleting an entry, deleting an icon, changing a password, etc) it gets logged to userlog, and if it's an admin action (console command performed on the account) or a system action (payment applied), it gets logged to statushistory. It's not always a perfect divide, though. It's usually a good idea to check both if you need to check one.

• moodthememanager: Obsolete; was used to manage public mood themes. (These days it's done with a code push.)

• payments: Grants access to the payment admin system at /admin/pay. Allows looking up by account or by order number. Allows you to apply and/or remove paid time. Allows you to look up logged payment data and payment details, although in a development environment, that's not really relevant.

• schemadoc: Obsolete; was used to view the database schema documentation (since moved to this wiki).

• siteadmin: Enables a hodgepodge of site admin pages (via argument) that aren't quite sensitive enough to hang off canview but still shouldn't be publicly available. Mostly debugging data. Like canview and fileedit, you can enable single pages via argument, or you can grant someone siteadmin:* to grant access to all of them. A bunch of them are really only useful in production. (Some of them aren't really even used in production, until such a point as they're really, really needed.) Available arguments are:

siteadmin:commentview: Grants access to /admin/recent_comments, which generates a list of links to the most recent comments an account has made across all journals. (Does not override entry security or grant access to the actual data: it's literally just a page full of linked URLs.)

siteadmin:importhistory: Grants access to a user's import history at /admin/importer/history.

siteadmin:largefeedsize: A weird one: feed accounts that have been granted this priv can exceed the size limit on how large a feed we'll read.

siteadmin:memcacheclear: Grants access to flush memcache data for a user at /admin/memcache_clear.

siteadmin:memcacheview: Grants access to current memcache conditions and/or specific memcache data at /admin/memcache.

siteadmin:mysqlstatus: Grants access to the current MySQL status at /admin/mysql_status.

siteadmin:rename: Grants access to /admin/rename, to look up and manage renames.

siteadmin:sendmail: Grants access to /admin/sendmail, to send emails from various site addresses (support, abuse, etc).

siteadmin:spamreports: Grants access to /admin/spamreports to view and act on reports of comment spam or spam entries in communities.

siteadmin:theschwartz: Grants access to /admin/theschwartz to view the TheSchwartz queue and errors and to /admin/importer/queue/ to view the current importer queue.

siteadmin:themes: Grants access to /admin/themes to pick featured themes and view/manage theme data.

You do not need to grant individual args to siteadmin to an account that has siteadmin:*: siteadmin:* implies siteadmin:commentivew, etc.

• sysban: Allows access to /admin/sysban and allows you to view and set sysbans. Arguments: the various forms of sysbans that can be set. Also enables the sysban admin console command to set them via console.

• translate: Allows access to /admin/translate and allows you to edit translation strings (site copy). Mostly not used on DW -- most site copy changes go through code changes -- except occasionally to fix some awkward phrasing or to tweak messaging to be more user-friendly.

Admin Console Command Privs

These privs enable the ability to use commands in the Admin console. Each console command has an associated priv, and you can't use the command without your account having the priv. Most of the console commands have the priv needed to run them listed in their description.

• changejournaltype: Enables the change_journal_type console command to convert accounts from personal to community journals and vice versa.

• communityxfer: Enables the change_community_admin console command to grant a new admin to a community.

• deletetalk: Enables the comment admin console command to delete, screen, or freeze comments or comment threads in an account.

• finduser: Enables the finduser admin console command to look up accounts by email address or look up email addresses by account.

• reset_email: Enables the reset_email admin console command to change an account's email address and remove other addresses from the account.

• reset_password: Enables the reset_password admin console command to generate a password change link to the confirmed email address on record.

• suspend: Enables the suspend admin console command to suspend accounts or individual entries. (Also allows you to use /admin/logout_user to end someone's current login session.)

• syn_edit: Enables the syn_edit console command to change a feed's source URL and the syn_merge console command to merge two feeds. Also lets you use /admin/feeds/merge (the GUI frontend on syn_merge) and /admin/feeds/duplicate (fuzzy matching that tries to identify multiple feeds with the same source).

Support

These are the privileges that are used by or around the support board, what they do, and how they work. 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.

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 )
• finduser (for spamadmins to find other spam accounts connected to a known spammer)

FAQ

More detailed discussion in FAQ backend guide. There are three relevant privs:

• faqedit: permits editing existing FAQs.

• faqadd: permits creation of new FAQs.

• faqcat: permits creation of new FAQ categories.