Hello, first of all: thanks for this REALLY cool module! I just installed it and started to play with it.

One first notion: for me it is not clear from the readme what the difference is between using taxonomy and menu for a hierarchy. For the menu its quite logical using the menu structure. But using taxonomy, if someone is editor of a parent term, does this mean that he can edit all nodes that have that term (or a child term)?


I have a quite interesting use-case:
- two content types: pages and news
- a school has different sections (menu based pages) but also news per section (taxonomy based news).
- some pages are the main page of a section, here the section news is listed. User "John" is editor of a section (menu based) but can also add "news" to that section (taxonomy based).

Right now what I'm thinking of is to let Workbench handle the menu hierarchy (creating pages) and write some code myself for the news with taxonomy thing. So basically I will add a taxonomy field to the user entity and use a form alter for the news nodetype to limit the selection of a node to the terms that this user has.


Am I right that Workbench is not suitable for this? You think this is a good solution?

Greetings Wappie

Comments

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Yes, if assigned to a parent taxonomy term, a user can edit all nodes tagged with the parent and its children.

Your use-case is complex, but could be supported. The main issue right now is that default forms are not supported. That is, Workbench Access creates its own form element. That simply means that assignments won't happen *automatically* due to menu and taxonomy selection.

As it stands now, you cannot use both menu and taxonomy at the same time -- and I don't expect that to be supported, though if you were to try a patch, it might be interesting.

One other option, since workbench access uses varchar storage (and not integer) is that you could create a new hierarchy type that combines menu and taxonomy. In that case, the access_id keys would be a combination of the mlid and tid. Something like:

access_scheme: menu-taxonomy
access_id: m12-t10 (i.e. menu id 12, term id 10)

If you could describe that hierarchy using the API, then it should just work.

There are, however, some technical limitations in the API right now that would need to be fixed. See:

#1101638: Default menu form support
#1187424: Default taxonomy form support
#1187000: Add roles as an access scheme

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Closed (works as designed)
jeremiahtre.in’s picture

jeremiahtre.in commented

I agree. It could work. Though I know this is not affiliated with Organic Groups, inspiration can be taken from og + og_menu in how they handle what menus groups are allowed to post to.

Our office could see what we can drum up as far as patches go.

jeremiahtre.in’s picture

jeremiahtre.in commented
Issue summary: View changes

Updated issue summary.