woocommerce Case study
Quick Price Editor Role
Pricing on a gold and watch catalog changes constantly and cannot wait for whoever holds the admin account. The staff who need to change prices are not the staff who should be able to edit product descriptions, images, categories or stock rules. WordPress has no role that draws that line.
The business problem
WordPress capabilities are coarse. Granting edit_products to let someone update a price also grants the ability to rewrite titles, change categories, alter attributes and unpublish items. The Shop Manager role is far too broad, and the alternative in practice was sharing an administrator login, which is worse than either.
What I delivered
- A restricted role whose product access is narrowed to the price fields reachable from quick edit.
- Removal of the broader product editing surfaces for that role, so the full product editor is not a way around the restriction.
- Enforcement on the save path rather than only in the interface, because hiding a field is a presentation choice and not a permission.
- A role that remains a normal WordPress role, so it can be assigned, revoked and audited with the tools already in use.
Technical approach
- The capability check happens where the write happens. Anything that only hides a control in the admin is a suggestion, not a boundary.
- Quick edit was chosen as the surface deliberately: it is the narrowest editing path WooCommerce already provides, so the role can be described in one sentence to the person receiving it.
- The role grants rather than revokes. Starting from nothing and adding the one capability needed is auditable in a way that starting from Shop Manager and subtracting is not.
Result and evidence
Price updates were delegated without handing over the catalog. The practical outcome is that the administrator credential stopped being shared for a routine daily task, which is the actual security improvement here.
Commercial value
Shared admin logins are how small commerce teams end up with no accountability at all. Replacing one with a role that does exactly one thing costs very little and removes a standing risk.
Readable implementation brief
implementation_brief {
project: "Quick Price Editor Role"
goal: "delegate price changes without delegating the catalog"
surface: "WooCommerce quick edit, price fields only"
model: "grant from zero, not subtract from Shop Manager"
enforcement: "capability checked on save, not just on render"
blocked: "full product editor, taxonomy, media, publish state"
replaced: "a shared administrator login used for daily pricing"
}What this project shows
The principle is ordinary least privilege; the engineering judgement is choosing quick edit as the boundary, because a permission model nobody can explain is one nobody will follow.
Enforcing on save rather than on render is the difference between a real restriction and a cosmetic one. That distinction is worth being pedantic about.