Expose interface to normal users...

Glad you like it. I agree with your granular access to end users model. One unfortunate side-effect of moving things to a more drupal compliant way in the D6 version is that it became an admin module (D5 version can be granted to roles). That said, D7 has already started to give me some new ways of looking at Drupal as an interface / platform. I'll be working on rewriting the Outline Designer for Drupal 7 this summer (it's kind of the critical component for us upgrading anything). The UI tweaks and feature set will be pretty substantial improvements based on how I'm seeing people working with it.

It may even go as far as a name space change so that it's more identifiable as to what functionality it will add. We'll see, it's still a bit up in the air but I have done some mock ups. I need to understand the new popups functionality in core for modals in order to fully utilize it.

As for the 2nd point, the current module will integrate with system permissions. If someone doesn't have the ability to create a page then they can't create a page via outline designer. Same with delete and edit permissions. OD isn't a way around drupal's current permissions system, that might not be super apparent but it is taking those settings into account when you go to access the ajax commands.

you might want to check out the draggable views project as it has some of the functionality you're talking about. As for the deep levels of element inclusion / indentation I'm not going to extend the outline designer beyond the node level. We've kicked around this idea in the past and it just gets too granular to be practical. The chaos that we live in without it can often be liberating when it comes to content generation and people don't feel as though they need to generate content just to fill regions. We're also coming from a course building / workflow background so that's where my head is on it.

I'll probably be blogging about the project more this summer once I get deeper into it then just diagrams and what not -- https://elearning.psu.edu/

Changing status as this is in my active queue of usability improvements for the module. Hopefully I'll be posting an update to the module that includes this in the next week, been putting a lot of UX improvements into it and simplifying the installation / requirements.

still leaving this as postponed. It didn't make it into the 1.1 release but I'd accept a patch and it's planned for the future. OR, a recipe could be posted as to how to do it with draggable views module as it allows for this type of stuff. in a lightweight fashion.

Please see issue #869106: Give permission to group administrators to rearrange books created in their group Kyle Mathews has "fixed" this limitation via Organic Groups. All the code is there to make this work for people in organic groups (who are group admins as opposed to site admins or example). Give that a try if you're interested in this feature.

Please review this functionality in version 1.2 via organic groups. If this is in the right direction then making it available to "normal" users via a secondary permission shouldn't be too difficult (patches for this functionality will be given high priority)

See this module / issue, this request is being pushed forward #1016248: outline designer integration

That module also works very well with outline designer given the code snippet on that page so hopefully we'll have the ability for users with a certain permission (like outline content the user can edit, or maybe just if they have access to "add content to books"

A few things on this...

1. This functionality is coming in version 1.3
2. It will be coming as part of a sub-module called Outline Child Pages so you will have to turn it on separately (that way current sites that don't want the option don't have to change anything)
3. The permission schema is as follows (please let me know if anyone sees a problem with this)
--- The current node MUST have child pages on it
--- If the current user has 'administer book outlines' OR (if og integration is turned on) they are the group admin, then they can outline the page
--- If they are non admin BUT have the following three permissions then they can use outline designer: 'add content to books', 'outline own pages', AND have the ability to update / edit the node via a node_access call.

If they pass all that they will be given the ability to use outline designer without needing the admin book outlines. This is important because it allows for users to use the outline designer on JUST the content they have ownership within a book. So, if they created a book outline, they'll be able to use outline designer on that node by navigating to it and clicking 'outline child pages'.

If they don't have access to edit the book node, they'll only see the 'outline child pages' for the nodes that they do have the ability to edit in the book structure. Outline Designer respects core permission structures so if they can edit and outline a node but not one of the children under it, attempting to commit actions via outline designer will give them a message saying invalid permissions, but just on those nodes they don't have access to.

Example:
1

• 2(has access)
  • 3
  • 4(has access)
• 5

Going to node 2 will give them an outline designer with 3 and 4 in it. Committing actions on node 4 will perform the actions requested but any action that affects node 3 will be blocked (like edit, delete, rename add child). Clicking view would take them to node 3 and if they can see it then they can, if not they get access denied. Clicking duplicate will duplicate the node in question as long as they can view node 3. If they can't view node 3 the duplicate function will be blocked as well. They won't have access to do anything (or outline) at node 1 or 5 (but if 5 had other children with children which they had access to they could).

This all will flow very well with #1033962: Customization of the Context menu which will allow you to say what actions each user can see in their context menu. A potential use-case could see you giving a user access to all nodes down one branch of a book outline and then setting their context menu to only have the ability to view, edit, and rename nodes. This would effectively give them the ability to perform the traditional admin/content/book/[nid] functionality but with the added benefit of ajax drag and drop (not to mention them not being able to mess with other books!)

this will be released in 1.3 in the outline child pages submodule

I have a work around solution to the OP's 2nd issue above. In my case, I have used the modules role, rules, and context to provide fine grain permissions.

1 - I created a new role called "admin nodes" and gave it the permission to administer nodes (you can use whatever permissions you want, of course).

2 - I created a context called cannot_admin and included a bunch of paths where I know I do not want the end user having any kind of node administration rights.

3 - I created another context called can_admin with paths where I know that I do want the user to be able to have node administration rights.

4 - I created a rule "when content is going to be viewed" > Condition: compare two users / acting user -- viewed content author > Action: Add user role: admin nodes

5 - I created a rule "when content is going to be viewed" > Condition: compare two users / acting user -- viewed content author --NEGATE > Action: Remove user role: admin nodes

6 - I created a rule "Context "can_admin" is active" > Action: Add user role: admin nodes

7 - I created a rule "Context "cannot_admin" is active" > Action: Remove user role: admin nodes

If you have a simple site setup, you could skip the context module and just use steps 1, 4, and 5. My site is a bit complex and I allow admin options to end users on pages built with views, so I needed to add the context module features to get the granularity I needed for these permissions. This is a pretty nifty trick, it can be used for any permissions and avoids hacking modules. HTH