Admin permissions

[danielbachhuber]

We need to implement permissions for the admin. To start, agents should be able to create and access all tickets. Respondents should only be able to access the tickets they're cc'ed on, and create new tickets.

[tollmanz]

Author role needs ability to see a thread. Should be added as one of the quick links in the wp list table.

[tollmanz]

Contributor should be able to view threads. Should be added as one of the quick links in the wp list table.

[tollmanz]

After discussing with @danielbachhuber, we are proposing the following changes to user management:

• Authors and Contributors will only be able to view posts in which they are a "Respondent". Since this is a per post decision, a role or capability is not viable. This logic will be rolled into a "permissions" class that can be used for various functions.

New capabilities will be added to map to SF specific features:

• open_thread: will be used to determine which users can start a thread (super admin, admin, editor, author)
• close_thread: will be used to determine which users can close a thread (super admin, admin, editor, author)
• reopen_thread: will be used to determine which users can close a thread (super admin, admin, editor)
• comment_on_thread: will be used to determine which users can close a thread (super admin, admin, editor, author, contributor)

I have outlined roles are capabilities here: https://docs.google.com/spreadsheet/ccc?key=0ArP9xjlqzFoRdEhwbkhCQVMwMW41bF90MDUtYTJjOFE

[tollmanz]

First pass at adding these permissions: 71b56b8

[tollmanz]

Note that in a commit I indicated that Super Admin capabilities would be added in later. This comment was do to the fact that I needed to explore how Super Admin capabilities are managed. It appears that Super Admins have all capabilities and indeed have the capabilities added via the previous patch.

[tollmanz]

@danielbachhuber I have been digging into user permissions and I think we have 90% of what we need already in the plugin with regard to setting up user permissions. We will need to do through the plugin and add some current_user_can() conditional logic to apply the permissions.

The 10% that we do not have I think should be solved by filtering with map_meta_cap filter. Let's take one problem as an example: allowing a "Respondent" that is setup as a "Contributor" to be able to close a thread (i.e., get the "sf_close_thread" capability). On the map_meta_cap filter, we would compare the list of respondent email addresses with the current user's email address. If there is a match, the user would be given access to the ticket. I think that this is best done through map_meta_cap filter, but I'm still a little confused by it. Thoughts?

[tollmanz]

As a follow-up, I think this is similar to what is needed: http://www.ethitter.com/slides/wcto-roles-and-capabilities-map-meta-cap/#/step-26.

[tollmanz]

Note to self, change permissions values for readability (e.g., "sf_open_thread" becomes "open_sf_thread").

[danielbachhuber]

I did some renaming but I also did some failboating that I'm not going to commit. Probably going to dive into this tomorrow morning.

We also need to consider whether a respondent should be able to add or remove ccs, change the subject, or change the status / assignments when creating or editing a thread.

[tollmanz]

Primary work that I think needs to be done is making sure that individual calls to current_user_can map meta capabilities to primitive capabilities.

For instance, the following function call:

current_user_can( 'open_sf_thread', 35 );

needs to return true for users with "open_sf_threads" and "open_others_sf_threads" capabilities. This should be handled via the map_meta_cap filter.

The piece of the puzzle that I am still uncertain about is how to give Respondents that are CCs on a thread capabilities that they don't have. For instance, if the function call above is issued for a Contributor who is a CC on a thread, I am not sure if we need to temporarily give that user capabilities or what. I need to investigate this further.