Customization of the Context menu

I like the idea but would it possibly be better to make the ability to access different context menus in outline designer a permission based structure instead of a global add/remove? In the future I'd like to add a hook system so that other modules could add contextual functionality to the outline designer context menu.

I could see an admin wanting all functionality while giving a copy editor just the ability to edit / view material without being able to add new. While OD does respect permissions of the system it doesn't remove buttons from the context menu (it'll just throw an error).

Again, love the idea, thoughts on making it permission based instead of a global setting?

I like idea of a matrix, that makes sense and I understand why you're saying it should happen outside of the permissions page. We can't map permissions directly to items because of the complexity of what it opens up. You'd need to do an on the fly node_access call for each operation every time you loaded a node and clicked the edit button. If you made assumptions otherwise, you'd be removing any other modules that mod permissions like og, TAC, node access and node permission by role. So I think the hit wouldn't be worth it. Throw up the operations and block people from performing them on the grid you're talking about. If there's 9 nodes you have the ability to do all those operations to and 1 you can't then it's better to just say 'access denied' in the pop up message returned then do the call every time.

Matrix it up if you like, love the idea and I think this would be a great addition. As a heads up, I have the following two features on my list of things to do over the next month or so to add to this project:

• Come up with a way of duplicating from one branch to another
o duplicate to another branch you have permissions on the duplicate menu item
• Iterative duplicate
o Duplicate branch X, N number of times, iteratively based on a convention
• Fields: number of duplicates, convention (A,B,C, 1,2,3, I,II,III)

That said, I'll probably roll another version with this patch and others in a month.

Awesome! I'm right in the middle of something but I'll have to try this out soon. In reading through what you've put forth makes sense. A few thoughts...

* If the admin module is installed you could look and see what that role is considered and check all those boxes by default
* Why not set all to see everything by default? This way people who install / upgrade to this project will be saying "by default I want the same functionality but let's make some changes"
* It seems like it would be possible to give a role NO permission to use the context menu (in which case they could just drag and drop reorder items and change titles)

Ultimately a goal of this project is to allow end users to use the outline designer in varying degrees. Right now my thinking is that if you created a book and you have the "create new books" as well as "add content to books" that the combination of those two permissions should be enough to say "you're responsible enough to use the outline designer on content that you created / own". I think that you're patch fits in with that vision very well. If others could test / add thoughts on this topic that'd be great so we can build some consensus on the project setting up for this direction.

Cool. Ok, I just misunderstood your descriptions in the patch. I'll chuck it on and see how it works on a fresh install. Definitely looking forward to it. It might be a good idea just to have all the roles there on the matrix with all set to do everything by default, then a help message saying only those with permission 'administer book outlines' will be able to utilize these settings. Only reason for this change is that in the future I plan on changing things a bit permission wise like I said for the show interface to non-admins / people without the administer book outlines. This way when that change happens it won't completely fudge the checkbox maxtrix (and I'm hoping to add this functionality to 1.3 anyway).

the included outline designer OG module in 1.2 allows for the editing of books by group admins / creators without accessing the admin/content/book page. the goal is to add the ability to edit your own books (not all hence no admin book outlines permission) that you create or have access to edit. This way users could make their own books and leverage the power of the outline designer without being able to royally screw up all / other books. Check out http://drupal.org/node/1016248 as it starts to go in this direction too.

good call, I'll work this into 1.3, thanks for all your work on this!

getting the following warning which is making the table / matrix render incorrectly -- warning: Parameter 1 to theme_outline_designer_context_menu_items_matrix() expected to be a reference, value given in /var/www/html/includes/theme.inc on line 656.

Know what could cause this?

this warning also gets thrown if you don't check anything; warning: array_filter() expects parameter 1 to be array, null given in /var/www/html/sites/all/modules/outline_designer/outline_designer.module on line 414. set the variable to array if the values don't get checked

fixed both issues; remove the by reference call to the form object (it's unnecessary) so the function call should read:

function theme_outline_designer_context_menu_items_matrix($form) {

To fix the other array issue with no checkboxes being unchecked in function _outline_designer_settings_submit add the following line to the function

function _outline_designer_settings_submit($form, &$form_state) {
  $items_unchecked = array();

Haven't gotten to test the patch for respecting the settings based on role as my dev system hasn't gotten into roles much but looks good so far!

cool; and I'm going to start playing with the permission side tomorrow to make sure it's ok (though from a quick glance it is). Then I'll start working on the 1.3 release and hopefully can get it out by the end of the week (day if nothing comes up tomorrow). Next in my queue is #1016248: outline designer integration but I've already got you're current fix in. If you notice anything else I'll roll a new patch on my working copy but atm I think it's pretty good.

is this in the scripts file the only new var instantiated? var contextMenuItems = new Array(); Sorry, applied a bunch of different patches so if you could do a diff from between your two patches that'd really help me on this one.

No worries, you're adding a great new feature to the project!

perfect, thank you! I apply most patches by hand cause I'm a control freak :p

hmm.. found a biggy...

Based on the way things are structured (an array of what shouldn't be there) it's very difficult to do array merges correctly. Especially when authenticated user is an allowable choice because EVERYONE is ALWAYS an authenticated user as well as another role. Hmm... still working through it but it's a bit tricky. Essentially whatever the lowest level of perms is in the roles someone has is what shows (for non user 1 obviously since that skips the test in your patch).

so, authenticated users will presumably always have less permissions then people with roles, hence auth user's array always "wins"

Array
(
    [2] => Array
        (
            [nid] => Array
                (
                    [unchecked] => 1
                )
 
            [add_content] => Array
                (
                    [unchecked] => 1
                )
 
            [delete] => Array
                (
                    [unchecked] => 1
                )
 
            [duplicate] => Array
                (
                    [unchecked] => 1
                )
 
            [change_type] => Array
                (
                    [unchecked] => 1
                )
 
        )
 
    [4] => Array
        (
            [nid] => Array
                (
                    [unchecked] => 1
                )
 
            [change_type] => Array
                (
                    [unchecked] => 1
                )
 
        )
 
)

That's the output of the array matrix for the 2 roles I have, the one with the least stuff is the auth user, the other is an admin role

nm, it's working, logical goof on my part with some other patch. Looks great, working it into 1.3 as we speak

for your patch in case you're working off your version right now that's modified here's the logical issue that the current patch ran into:

if($saved_unchecked_items[$rid] != null) {

When you do the grid if ALL checkboxes are selected then it doesn't save the array. This is a problem because if you select everything you're basically saying that if they have that role they can use the outline designer normally. So...

user = authenticated user and admin (where admin has ALL checkboxes marked)

It will give them the menu of an auth user because the null value is ignored when really it should automatically invalidate the permission process cause if a role isn't set (as per the default behavior) they should see everything. I'm adding a flag that if a role isn't in the matrix that we assume all permissions to view context menu items.