Unfortunately, Panel nodes don't have the conventional permissions strings. Instead of "edit panel content," etc., they have just:
- administer panel-nodes
- create panel-nodes
- edit own panel-nodes
The first one doesn't actually map neatly to "edit [type] content" in terms of what it allows a user to do.
Moreover, I think the content type is listed as panel rather than panel-node
Getting this to work will require either a special case in _outline_designer_tree_recurse, or changes to the Panel module. The former is probably easier to achieve in terms of releasing new versions, though we should probably ask merlinofchaos to consider revising the permission strings in panels_node.module.
If I have time, I'll try to come up with a fix for outline_designer.module tomorrow.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | outline_designer-275099-4.patch | 8.13 KB | kopo88 |
Comments
Comment #1
btopro commentedyeah, I just tried to stick to what I felt the Drupal convention should be. I'll submit an issue request to that project unless you already have. If they don't think it's worth fixing adding in a special case shouldn't be too difficult.
Comment #2
kopo88 commentedI haven't submitted an issue request for Panels, but I'm going to need this functionality today, so I'll probably come up with a fix for Outline Designer this evening.
However, just in terms of making the OD code cleaner, the permission string generators should moved out into helper functions -- otherwise there's tons of code duplication and opportunities for mistakes.
I'm thinking of something like
_outline_designer_permstring($operation, $type)where operation is one of {'create', 'edit', 'edit own'}.This will return the right string, and handle all special cases (including 'book pages' vs. '[type] content').
Comment #3
btopro commentedComment #4
kopo88 commentedHere's a fix. I wrote a new function,
_outline_designer_get_pstr($op, $type), and replaced all the relevant references to access control strings in outline_designer.module and ajax.php with calls to this function.If any incompatibilities with other modules' node types are discovered, you'll now be able to easily add special cases in just one location.
Also, it looks like the
==fix somehow didn't appear in your latest 5.x-1.3-2 release, so that's fixed in the patch, as well.(Note that I'm not using CVS, so the patch headers probably aren't in the right format, but the actual contents are correct.)
Comment #5
btopro commentedThere's a version 5.x-1.3-3 that didn't get posted as the main version for some reason... I'll check out the patch on monday.
Comment #6
btopro commentedlooks like she works, I'll commit to 1.5 as soon as possible. Nice catch
Comment #7
btopro commentedhttp://drupal.org/node/283062 -- should be up shortly (1.5)