Add permissions to queues

Definitely the 'data' field, that's why it's there. It also used to keep the equivalent of 'nodeueue_types' in it :)

That's a good start. I made some additions in the attached patch, but I'm not sure what to do with the 'view' permission :)

One serious problem that the patch does not fix is that currently if you go to admin/structure/entityqueue there is no access control at all (even anonymous users can go there and add new queues).

Perhaps entityqueue_access should not be used as the access callback from hook_entity_info, or maybe it just needs to be adjusted.

Closer. Remaining issue is that if you don't have administer perms, but you do have perm for a specific queue, you can't get to admin/strucutre/entityqueue because entityqueue_access gets called with no params and returns false.

Excellent and tested. Since this fixes a security problem, can we get this into the current branch while the new branch is being worked on?

Sure, the patch looks good, and if you guys need it, why not :) Committed, pushed and marked as 'to be ported' to the 7.x-1.x-ctools branch.

http://drupalcode.org/sandbox/amateescu/1429904.git/commit/bcffac6

Here is the first attempt at porting this to D7.

Make the list of operations user "admin/structure/entityqueue" respond to the access permissions and fix issue in the entity bundles parameter in previous patch.

Works for editing the individual queues, but none of the queues show up at /admin/structure/entityqueue, even those that you have permission to edit.

Also, permission names should use queue machine_names, and not the human readable names which are subject to change.

Updated patch to fix issues highlighted.

status change.

Issue on queue specific check fixed.

Slight confusion with wording configure and edit... fixed issue on edit sub queue page

wrong patch, sorry.

Previous patch had an issue with the permission names (had an extra space at the end of the edit perm) and an inconsistency in the naming of the permissions and the user_access call in the access check. Updated patch attached.

Previous patch has a issue in the logic when determining the access to edit the entityqueues at admin/structure/entityqueue

Mainly a cleanup of the previous patch:

• updates the order of parameters in the comment block to match entityqueue_subqueue_access()
• changes $entity to $queue to make more sense based on what is being passed into it
• removed the last parameter $entity_type from entityqueue_subqueue_access(), it isn't used in the body of the function or in any of the access callbacks, and the comment doesn't give a very good idea of what would be expected there in any future implementation.
• removes the need to pass in 'load_current' for the $user parameter, and uses a similar pattern to node_access() and defaults to the current user if one isn't passed in.

This patch doesn't apply anymore since I merged 7.x-1.x-ctools back into 7.x-1.x. I guess a reroll and a quick sanity check over the codebase is in order :)

Attached is an updated patch for the 7.x-1.x branch. Due to the merge it looks like the previously committed patch for this issue is broken, because entityqueues used to be entities and now the subqueues are entities but the queues themselves are not, so calling entity_label() on the queues results in an empty string. Also going to the /admin/people/permissions page results in a fatal error:

PHP Fatal error: Call to undefined function entityqueue_load_multiple() in /Users/jonathan/Code/DrupalContrib/entityqueue/entityqueue.module

I also was testing this more in depth by granting a user the most limited permissions, and I think there is some confusion around the 'configure %queue queue' permission. To me it sounds like that should grant access to the "Configure" link for that queue. Even with that permission, the user gets access denied on that page, and it looks like that page is a "given" from the ctools export ui. I haven't dug into the ctools internals yet to figure out how to control/grant access to that page. For the other operations I tried modifying the logic to correctly hide any operations the user doesn't have access to.

I just noticed that the "Manage fields" page went missing when configuring an Entityqueue. This patch is the same as the last one except the bundle admin path has been updated in hook_entity_info() to fix this.

I made a few improvements to the code and removed the 'configure entityqueue' permission as it only duplicated 'administer entityqueue'. Can you please check if everything works as expected?

Testing patch in #26, I'm getting the following error when trying to configure entityqueue (in /admin/structure/entityqueue/list/[queue_name]/edit):

Recoverable fatal error: Argument 2 passed to entityqueue_access() must be an instance of EntityQueue, string given in entityqueue_access() (line 380 of [...]/entityqueue/entityqueue.module).

EDIT:
Looks like entityqueue_access() is missing $entity_type parameter?

function entityqueue_access($op, EntityQueue $queue = NULL, $account = NULL) {

Should be:

function entityqueue_access($op, $entity_type, EntityQueue $queue = NULL, $account = NULL) {

?

Oops, my bad. This one should be better. Thanks for testing!

So if we have a role that we want to be able to edit items only within a certain queue we would have to give them "Administer entityqueue" to see /admin/structure/entityqueue and "Edit $queue queue items" to add items. If I only give them "Edit $queue queue items" then I can go directly to /admin/structure/entityqueue/list/$queue/subqueues/$subqueue/edit but when saving the form they are returned to /admin/structure/entityqueue where they get "Access denied".

My only concern is that "Administer entityqueue" to me sounds like an admin-only permission, which I picture as allowing access to module level settings. It seems that "Administer all queues" is the more admin-only permission though. Perhaps if "Administer entityqueue" was labeled "Access entityqueue list"?

I'm getting 403 access denied when trying to add items to queue using the autocomplete field. Log message says that following path gives access denied: entityreference/autocomplete/single/eq_node/entityqueue_subqueue/testqueue/11/testing

This happens for admin user that has all entityqueue related permissions.

@jojonaloha, Ok, how about we switch to nodequeue-like permissions:

Administer entityqueue (not used anywhere at the moment, I think)
Manipulate queues (gives access to /admin/structure/entityqueue)
Manipulate all queues (gives access to do anything on any queue)
Manipulate [queue_name] queue (gives access per single queue)

@paulihuhtiniemi, I'm not sure how that's possible, we're just using a regular entity reference field.. but I also don't have too much time to investigate right now :(

@paulihuhtiniemi, I just tested locally and got a 403 as well. I'll work on this a little later today.

@amateescu, I must admit I like the simplicity of those permissions. Unless anybody objects I'll probably use those in my next patch.

@paulihuhtiniemi, I figured out the issue was due to my confusion over entityqueue_access() in #22.

Before that patch it was an implementation of the entity_access() access callback. I've modified it to make the more clear. Also, since the EntityQueue's themselves used to be entities, this function used to take the EntityQueue or a string machine name, but now that they aren't entities, this should take EntitySubqueue entities. I've made a menu callback for all the places where a EntityQueue is an argument, entityqueue_queue_access(), which just creates a stub entity and calls entity_access(), since in our case our menu access permissions on a bundle (aka EntityQueue) level.

The actual permissions in this patch are:

• Administer entityqueue: Administer entityqueue configuration and create, update and delete all queues.
• Manipulate queues: Access the entityqueues list.
• Manipulate all queues: Access to update all queues.
• For multiple queue handlers:
  • Add %queue subqueues: Access to create new subqueue to the %queue queue.
  • Delete %queue subqueues: Access to delete subqueues of the %queue queue.
• Manipulate %queue queue: Access to update the %queue queue.

I decided to make the create/delete EntityQueue permission "Administer entityqueue", as that matches with the Nodequeue style permissions. The "Delete %queue subqueues"permissions doesn't really do much yet since there is no subqueue delete form. I'll be creating an issue for that at some point.

Attached is a re-roll of the previous patch, also fixes an issue brought up by coder review.

Ok, looked over this again and I think it's good enough for now. We can always start with an alpha release to gather more feedback :)

Committed to 7.x-1.x.

I'm getting a 403 access forbidden error when trying to add a file to my entity queue. This is on version 7.x-1.5. Any thoughts?

Thanks