[development] Menu Tree Access Control?

[Josh Koenig]

All: Thanks so much for the links. The group thread that webchick
started is precisely the use-case that I'm looking for.

Ken/Larry,

This sounds like exactly the path I was on (though I was working on
one module rather than splitting it into two). My timeframe is
somewhat tight: need to have something beta-ready by end of month,
which means I need to prototype now.

However I have availability to put cycles in to help, and would like
to see this problem get solved "right" for the long haul. Is there any
chance of getting a CVS checkin of the code you're working  -- no
official release -- in the short-term? I can help test, submit
patches, etc.

cheers
-josh

On Sun, Apr 5, 2009 at 3:00 PM, Ken Rickard <agentrickard at gmail.com> wrote:
> I am the Palantir developer in question and have two modules just
> about to release that are relevant here.
>
> Release should be by end of month, if all goes well.
>
> 1) Menu Node API
> The menu/node API module keeps track of menu-node relationships for
> you, so that you can run JOINs from the {node} table to the
> {menu_links} table through the new {menu_node} table.
>
> This is a glue module that will allow for (among other things):
>
> -- Menu-based Views
> -- Node Access modules based on menu hierarchy,
>
> 2) Menu (Needs Name)
> The second module was called menu_access, and someone just took the
> namespace on d.o. It leverages the Menu Node API and rewrites
> node/%/edit using hook_menu_alter(). It then lets an administrator
> define menu 'sections' -- elements of the tree hierarchy that are used
> as ACLs.
>
> Individual users can then be assigned as "section editors".  A section
> editor has cascading rights down the menu hierarchy.
>
> This module is _deliberately_ not a Node Access module, since I have
> not yet figured out the necessary overhead for which menu parents
> would need to be stored in the {node_access} table as GIDs.  And since
> the client did not require View or Delete access control, Edit control
> was sufficient.
>
> I hope that any delay in releasing these won't force anyone to write
> duplicate code.  Larry and I will convene next week and see if we can
> get a firm launch date.
>
> - Ken Rickard
> agentrickard
>
>
>
> On Sat, Apr 4, 2009 at 11:59 AM, Earnie Boyd
> <earnie at users.sourceforge.net> wrote:
>> Quoting Simon Roberts <lyricnz at gmail.com>:
>>
>>> I've also been doing fine-grained book-page access, per-user and
>>> per-role, and ended up coding more than I would have liked.  (Writing
>>> ACLs on the fly, and twiddling with menu-entries during theming -
>>> uugh).
>>>
>>> No idea if this is useful, but I saw this new project pop up a few days
>>> ago
>>>
>>> http://drupal.org/project/book_page_access
>>>
>>
>> And then there is http://drupal.org/project/acl which give you an API.  The
>> page lists other modules using it.
>>
>> --
>> Earnie
>> -- http://r-feed.com/           -- http://for-my-kids.com/
>> -- http://www.4offer.biz/       -- http://give-me-an-offer.com/
>>
>>
>>
>
>
>
> --
> Ken Rickard
> agentrickard at gmail.com
> http://ken.therickards.com
>



-- 
--------------------
Josh Koenig, Partner & CTO
http://www.chapterthree.com