Make WordPress Core

Opened 8 years ago

Last modified 12 days ago

#5942 reopened feature request

Add Owner role

Reported by: tellyworth Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.1
Component: Role/Capability Keywords: needs-refresh ux-feedback
Focuses: administration Cc:


This patch adds a new 'owner' role. The owner is an administrator who cannot be demoted, deleted or edited by other administrators. Owner is a secondary role - the user is both an administrator and an owner.

In the current implementation there is only one owner at a time. The current owner can transfer ownership of the blog to another administrator on the Transfer Ownership tab (under Users). I implemented this as a plugin because some site owners won't want the feature there at all.

This is of most interest for MU, but it's also probably useful for some regular WordPress blogs with multiple users.

This would be particularly useful in conjunction with the user_role table from #5541, but it works fine with or without it.

Attachments (1)

owner-role-r6947.patch (9.5 KB) - added by tellyworth 8 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 @tellyworth8 years ago

Just a quick note in response to questions elsewhere.

This could be implemented by storing the owner's user_id in an option. My reasons for using a role instead are:

  1. In conjunction with the user_role table in #5540, it becomes very easy to find the owner of a blog, or all blogs owned by a specific user in an MU install. Just a simple lookup or join on the user_role table "WHERE role='owner'".
  1. Because it's a role it's easy to do a current_user_can() check.

comment:2 @ffemtcj8 years ago

  • Milestone changed from 2.5 to 2.6

comment:3 @ryan7 years ago

  • Component changed from General to Role/Capability
  • Owner anonymous deleted

comment:4 @Denis-de-Bernardy6 years ago

Why not consider that the admin user who has the admin_email option as his email is the owner, and make that option changeable only by the owner?

comment:5 @Denis-de-Bernardy6 years ago

  • Keywords needs-patch added; has-patch removed
  • Milestone changed from 2.9 to Future Release

comment:6 @Denis-de-Bernardy6 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

see #10201

comment:7 @jane4 years ago

  • Milestone set to Future Release
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Type changed from enhancement to feature request
  • Version set to 3.1

I would love this, for the reasons outlined by @tellyworth in original ticket.

comment:8 @nacin4 years ago

My thoughts after a discussion with Jane:

  • Having an'Owner role would be beneficial for two reasons. 1, it would establish a link between a single admin account and the admin_email, thus improving that UI/UX. 2, by locking down ownership transfer, this is nice for security and site theft.
  • The second part is primarily beneficial for multisites. It is also feasible only in multisite, unless you lock down plugin/theme installation (and probably upgrades) as well as the file editors to non-owners.
  • An Owner role probably shouldn't be a role. It'd be much easier to bolt it onto the capabilities system similar to super admins.
  • You could allow for an Owner to be specified in wp-config, which would then hide any UI for transferring ownership. Note that this wouldn't remove the requirement to disable file editors and installation, as you could easily inject a shell.
  • I would think that Owner would be a nice feature to have for single-site -- it sounds like it should be an optional, opt-in way to link an account to the admin_email, and once that happens, the admin_email field would just go away for that site. For multisite, it could be enforceable at the network level for new sites. It sounds like it would get more use at the multisite level (the feature kind of sounds like the admin bar in that regard).

comment:9 @johnjamesjacoby4 years ago

I think this makes a lot of sense, and sounds like it would mirror and then extend the way that the 'Key Master' role currently works in bbPress stand alone installations.

Is the idea that the current 'super admin' will act as a 'network owner' and the new 'owner' pseudo-role will act like a pinnable per-site owner? If that's not accurate, would we want to bake in having pinnable 'network owner' and 'global owner' role/caps, with global for multi-network installs, so there are ultimate uber users in complex installations in core?

comment:10 @chriscct712 months ago

  • Keywords dev-feedback added

This is an interesting idea, but the question might come up whether or not it should be a role. The idea of a user who cannot be deleted, or demoted could be useful for other users on the site. As such a capability would let it be used for that purpose.

comment:11 @DrewAPicture12 months ago

  • Milestone Future Release deleted
  • Resolution set to maybelater
  • Status changed from reopened to closed

I think this falls squarely in plugin territory though there does appear to be some core interest, even four years ago. However, with no significant activity in four years, marking as maybelater.

comment:12 @dd329 months ago

#30933 was marked as a duplicate.

comment:13 @greenzilla9 months ago

  • Resolution maybelater deleted
  • Status changed from closed to reopened

I submitted ticket #30933. I think a user set within wp-config or an owner role would be an excellent improvement. I had an admin role compromised through a phishing attack and they removed all admin roles. I suggest core instead of a plugin since a compromised admin could deactivate/delete plugins.

comment:14 @SergeyBiryukov9 months ago

  • Milestone set to Awaiting Review

comment:15 @slackbot12 days ago

This ticket was mentioned in Slack in #core by sergey. View the logs.

comment:16 @dshanske12 days ago

I think having the 'owner' has the benefit, as mentioned above, of establishing a relationship between the admin email and a user. It would allow the admin_email setting to be backward compatible, but still move forward to connecting the setting with a user, which is where it should be.

comment:17 @chriscct712 days ago

  • Focuses administration added
  • Keywords needs-refresh ux-feedback added; needs-patch dev-feedback removed
Note: See TracTickets for help on using tickets.