I have checked out the code in the hs module for og_subgroups.
There are two errors in the implemented logic, and given the design of og_subgroups (in relation to private groups), the basic design of the hs module could be improved.
I have included a patch that fixes the implementation as it stands, though for some sites it may create a large number of "dead" (read "
" links in the hs selects. Plus, given the current design of the og mask concept, it is mildly non-trivial to create a good hierarchy for HS.
| Comment | File | Size | Author |
|---|---|---|---|
| fix_hs_module.patch | 2 KB | christopherreay |
Comments
Comment #1
christopherreay commentedOops, forgot to describe the issue!
Umm.. So the
hierarchy_select modulehas its api, The three relevant parts are the:At the moment:
[define roots] and [define children]
do not return values for any item in the hierarchy which is "masked"
....using
og_subgroups_mask_group- i.e. is a private group to which the current user does not have accessIf the user uses the CTools or whatever embedded in GET context links to build node content, for which, selected, is a parent that has some private and masked node between it and its root, the interaction with the above code and [define lineage] creates a scenario where the interface allows the user to choose an accessible options that select module cannot validate, and thus the new node is saved with no parent [bastard nodes]
There are two solutions to this problem.
EITHER
the OG_subgroups HS module must return only valid paths between subgroups (i.e. every single subtree bounded by Private nodes must be presented to HS module as separate tree from its own root.
OR
The "private" nodes must be presented to HS module.
Patch:
The fix in this patch implements the second option, supplying every item in the tree to HS module, but replacing the title of the group node with
"<private>"as in the og_subgroup block, where the group node is "masked"Feedback Appreciated
Christopher