[wp-trac] Re: [WordPress Trac] #2531: Functions for registering additional capabilities and getting a list of all capabilities

[WordPress Trac]

#2531: Functions for registering additional capabilities and getting a list of all
capabilities
-----------------------------+----------------------------------------------
 Reporter:  markjaquith      |       Owner:  jacobsantos            
     Type:  enhancement      |      Status:  new                    
 Priority:  normal           |   Milestone:  Future Release         
Component:  Role/Capability  |     Version:  2.0.1                  
 Severity:  normal           |    Keywords:  needs-patch 2nd-opinion
-----------------------------+----------------------------------------------
Changes (by Denis-de-Bernardy):

  * keywords:  has-patch 2nd-opinion => needs-patch 2nd-opinion


Comment:

 I can share some of my experiences with caps on a separate system. I had:

  - users
  - profiles
  - caps
  - user2profile
  - profile2cap
  - user2cap (for extra user caps if needed)

 so one more table than ryan's suggestion. one view for convenient querying
 then does the trick:

  - user_caps

 it worked fine, but, as point out above, it's a lot of tables... the view
 is potentially slow due to the cross join left join, but that turns out to
 be fine since it only ever gets queried against primary keys.

 Trying to abstract any more than that is bound to fail: You'd then need
 owner_id fields or their equivalent all over the place when per db row
 permissions need to be enforced (such as, post can only be edited by its
 author and editors). Sometimes, you need several owner_id fields for a
 single row (a post with multiple authors, or an order placed by a reseller
 for his customer, that can be viewed by the reseller's referrer). It's a
 big mess that is more easily enforced through different queries (or stored
 procedures, if the db is made aware of capabilities), than through some
 kind of abstracted owner2node field.

 If anything, the current system is a bit lacking when you need to query
 whether a user has a particular role or cap. But for those rare cases
 where it turns out to be necessary, you can always set up a separate
 system, using tables. It's what I do with my membership manager plugin. As
 a bonus, I can have members who are subscribers on blog A and contributors
 on blog B, some of who are editors on A and B, others who are moderators
 in forum C, etc.; each time independently.

 I end up liking the end result: WP manages the permissions for everyday
 tasks. It could have managed the access restriction as well. The main
 reason I opted for tables was for reporting purposes (who has a running
 membership X?), and to enforce the proper expiration dates when several
 products can lead to the same membership. Extracting the necessary data
 from serialized arrays would have been nuts...

 Anyway, suggesting either wontfix for this one, or the table solution
 outlined by Ryan (or my own if this gets delayed until Views are part of
 MySQL installs for all WP users).

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/2531#comment:20>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software