Documentation

Some tech docs placed in README. Will great, if anyone more expirienced with English will write docs more appropriate for users, not only for programmers.

Unfortunately I don't touch this project long time :\ And don't know what is the more need: cleanup module for 4.4 (many sites still use this version) or goes to future and remake module for CVS HEAD and 4.5?

:) Ops, sorry, I mistake with term_access module, which was wrotten for Drupal 4.4. The taxonomy_access is not my eparchy :)

Alex,

There are two modules already out for 4.5 that do node permissions-- this one, by taxonomy, and the other one, per-node and by roles.

Both use a deny-before-allow scheme, and to be set up, they need to perform queries that literally kill my site, since it's building up massive arrays of what node IDs are viewable by what user IDs.

A simple module that allowed someone to choose a single vocabulary that said that users in THESE ROLES are UNABLE to see nodes with THIS TAXONOMY TERM(S), and did so by checking small tables of disallowed nodes (rather than huge tables of allowed nodes) would be extremely valuable, and fill a gap in the current permissions module releases.

Would it be possible to get some documentation? - at the time or writing there is no INSTALL file, no adequate description of what the module does and does not do and thus no reason to use it :)

Well, I'll write a little more documentation, but it does exactly what it says, it allows you to control access to categories based on user role. I'll update the README with a bit more technical description and add an INSTALL file as well.

Both use a deny-before-allow scheme, and to be set up, they need to perform queries that literally kill my site, since it's building up massive arrays of what node IDs are viewable by what user IDs.

A simple module that allowed someone to choose a single vocabulary that said that users in THESE ROLES are UNABLE to see nodes with THIS TAXONOMY TERM(S), and did so by checking small tables of disallowed nodes (rather than huge tables of allowed nodes) would be extremely valuable, and fill a gap in the current permissions module releases.

This is an architectural question that is beyond the scope of either of these modules. I'm not familiar with the other module, but I'm pretty sure they're using the node_access hooks like this module does. The node_access stuff works as a whitelist, deny-before-allow, whatever you want to call it. We're simply hooking into these with the _node_grants hooks. If you want to change that, or have any performance problems with this method you'll need to talk to the core team, as node_access is in the core and we can't change how it works without changes in the core. I haven't done any kind of performance analysis but if a blacklist would make it perform noticably better I'm sure the core guys would listen.

Not fixed.

There's still no documentation at all on how to use the interface or what the options mean.

1) What is the purpose of 'Default'?

2) Why, when you untick 'Default', does the config page come back with it checked again?

3) Why is there no method of enabling the display of categories to anonymous_user under any circumstances?

Telling us what it does under the hood in *no* way assists users to operate the module. I know it's obvious to you - but from where I'm standing this thing simply doesn't work :-)

Two things here.

One, "Default" is what users see regardless of role. Anonymous users don't really have a role, so they just see the default. Anonymous users aren't a role or group, they are basically what you get when you have no roles or groups, so they just see the default permissions.

Two, the whole "Default" thing may be changing significantly and it'll possibly be removed so there's no reason to exstensively document the feature. There are some patches pending that will simplify the module so that it will be less confusing. Hopefully the new patched version will make more sense to you, however anonymous users will still see the default permissions, since they have no role.

Also, unticking "Default" works fine in the CVS version from what I can tell. When you uncheck something and it doesn't work, maybe it's a bug :) It's not supposed to work that way, so documenting it would be counter productive. Like I said, some changes to the "Default" feature are coming, so just hang tight.

Okay the rewrite has been in for a while, and I think that cleared up most of the confusion.