Morbus Iff <morbus@disobey.com> Tue, 15 Mar 2005 18:35:03
* To ensure that the right community defined terms are added to the right folksonomy (thus ensuring multiple folksonomies on one site could remain independent, much like normal taxos [normal taxos use the unique tid so knowing the vid isn't important]), the vid is included in the node form:
edit[taxonomy][vid][2] (note: "vid" will change to "community")
I solved this with a field name of edit[folksonomy][2 where 2 is the vocab for this edit field and then converting the comma delimited string to an array of tids during nodeapi('update') creating new tids as necessary. I had a corresponding folksonomy_form_all() which paralleled taxonomy_form_all and created as many fields as there were folksonomy vocabs defined for this node type.
Thus, you'd be able to create tiers of folksy users: all users can create nodes but group A can create new terms and group B can't. The downside of this is that the next "obvious" step would be to have a new permission PER community-created taxonomy: group A can create new terms in 'Folksonomy Tags', group B can create new terms in both 'Folksonomy Tags' and 'Another Example'. I can certainly see that being useful:
I definitely thought that anyone with edit rights for the node would have add term rights to the vocabs. Maybe it does need the additional control you're talking about. So given that we're developing very similar code in parallel, how do we work closer together? This isn't a problem while we're all experimenting and still trying to clarify the approach. There's another recent post in this forum where I've pointed to game plans. -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/