Permissions
RedPen registers three permissions, assignable to user groups at Settings → Users → User Groups, or to an individual user.
| Permission | Handle | Grants |
|---|---|---|
| Review content against the style guide | redpen:review |
See the review panel on the entry edit screen, run a check, and dismiss findings. |
| Run and view site-wide audits | redpen:audit |
Start an audit, read the report screens, and use the dashboard widget. Pro. |
| Manage style profiles | redpen:manageProfiles |
Create, edit and delete profiles, and change which rules are on and at what severity. |
How the control panel navigation follows
RedPen’s subnav is built from what the current user can do. A writer with only redpen:review sees the Rules reference — a read-only list of what is being enforced — and nothing else. Audits and profiles appear only with their permissions, and settings only for admins with allowAdminChanges.
A sensible starting split
- Writers —
redpen:review. They see findings on what they are writing and can dismiss the ones that are wrong. - Editors —
redpen:reviewandredpen:audit. They can also look at the whole site and decide where the problems are. - Whoever owns the style guide — all three. Usually one or two people; the profile is a shared document and it should not change by accident.
Profiles and project config
Because profiles live in project config, editing them also requires allowAdminChanges to be on for that environment. In a normal setup that means profiles are edited in development, committed, and deployed — and redpen:manageProfiles in production grants nothing on its own. That is usually what you want: a style guide that can be changed silently in production is not much of a guide.