Handling Many Nodes (grant access by Taxonomy)

You talk about wanting to break the nodes up by taxonomy term, I think you can do that, but using another method that isn't uc_node_access.

Have you looked at using Taxonomy Access to restrict a taxonomy term by role, then have your purchase grant a role instead of individual node access? Then you can use uc_role instead of uc_node_access as a product feature to give the customer a role, that then would open up one or more taxonomy terms for their access.

This method would break down if you need to offer many different products to grant access to many taxonomy terms, because you would have to make a role for each one of the groups, which wouldn't be ideal, but it would work. But without knowing more about your situation, maybe something like this would work.

Good luck,
Jeremy Zerr
http://www.zerrtech.com

If creating the roles would be too much, then something like tac_lite would be better to integrate with uc_node_access because of the ability to control per user access to terms. But on a side note, tac_lite doesn't seem like an actively developed module. Feel free to take a shot at it, I think it would be a good addition.

An alternative way to implement this would be to select taxonomy term(s) when configuring the product feature and ACL+Content Access would be used to grant the user access to each of the nodes matching that term(s). So the uc_node_access feature would just allow a way to select individual nodes in bulk using taxonomy terms.

Benefits would be no dependence on another access control module and it would be quite a bit easier to code up than integrating something like tac_lite.

Downsides would be that no future nodes tagged with that term would be granted access to prior purchasers and if you needed to take access away from a user, you would have to individually go remove them from the access control on all the nodes. This really doesn't sound like a good option to me, but depending on your coding experience, it could be created relatively easy and maybe the downsides wouldn't apply to you very often. Like maybe in your situation, you aren't adding any nodes to terms after you put the product up for sale, or you are OK if customers that bought the product in the past don't get new content. Also, if customers are always purchasing permanent access, then neither downside would apply.

Firstly, I know this is Ubercart Node Access, but it would be really useful to be able to grant individual users access to taxonomy terms, also core's access control is by node but is flexible enough that modules like TAC Lite and Forum Access can work by taxonomy.

With this in mind, here's a patch that provides a backend for TAC Lite. Unfortunately I had to hack uc_node_access itself a bit to get it to do what I needed; for one thing uc_node_access is given the product node as the access node, which means the conditional actions code is pretty-much useless.

The point of this patch, therefore, is to:

1. highlight ways uc_node_access is inflexible;
2. highlight ways it could be improved for the next version (for Drupal 7, I expect);

We could just fork this module to make uc_tac_access but I'd rather not, since there would be a lot of duplicated work between the two.

I just tested the patch from #6, it does work great. Thanks for that contribution.

I really wonder if people would like to potentially use both methods, ACL+Content Access for single node and TAC Lite for taxonomy terms, on the same site. Right now, you have to choose one or the other.

A better architecture for uc_node_access could allow the type of access control to be chosen in the Product Feature configuration, or have the module create a different product feature per access type.

I guess at the very least, you can use a taxonomy term that only contains a single node to do by-node access like ACL+Content Access, but then again, that could get ugly if you have a lot of single nodes you want to offer.

Either way, I think this patch to allow taxonomy-based node access is a great improvement to the module.

Jeremy Zerr
http://www.zerrtech.com

subscribe