On 10/8/05, Steve Dondley <sdondley@gmail.com> wrote:
I'm thinking about pitching in to help rewrite taxonomy_access module. That module has been plagued with problems from the start and it appears to be on the verge of going under. What were some of the basic mistakes this module made? What guidance would you offer to building a faster, sleeker solution.
I don't have any ideas on how to improve it under the hood codewise, but when I last evaluated it I had a few ideas about how the operation and configuration could work better. The configuration seemed a bit complicated and inflexible. Every vocabulary term was present on the form and they all took part in access control. Some ideas (some might be redundant or mutually exclusive) : * Being able to choose which vocabularies contributed to access control. ie some might not matter and just get in the way. * Instead of having only two access states (eg enabled or not) for each combination of term and access type, it is sometimes nice to have three states (eg allow, deny and no effect). That way some combinations can be set to no effect rather than an explicit allow or deny - that allows final decisions to fall through to other terms. ie instead of needing allows to be set for all terms on a node, you might need just one allow as long as you have no explicit denies on those terms. This is closer to how ACLs work on NT. * The ability to choose between default allow or default deny. * Maybe (still not sure about this one) the interface could work a little more like NT ACLs. eg instead of a big grid full of combinations, the admin could add access control rules to each role - similar to how user (eg name and email) rules are set up now. For instance for the anonymous role you could add a deny rule for terms x,y,z to the list of rules. If some of that doesn't make any sense - I could clarify what I meant :) Just my 2 cents -- Cheers Anton