Boris Mann wrote:

On 27-Mar-06, at 1:55 PM, Chris Johnson wrote:

...

I'm writing a module which requires that the data displayed be specified both by user name (no problem, works out of the box) and by a group that the user is in. I currently have 286 such groups, and the number will only grow larger. This is not a role, but rather a permission to see certain rows of a database table.

I can't help but think that this has been done before in Drupal. Any suggestions or pointers as to where best to find existing code that does this, or otherwise how to implement it?

I'm thinking about a problem set which looks similar -- potentially large numbers of "groups", or perhaps "groupings" is a better word. Thinking about the issue, it sounds a bit like taxonomy, and from there, a style of taxonomy access. Yes, users aren't nodes...but there have been many demands for a way to make it so, and some sort of relation fits in here too.

I am finding that we often find things which are conceptually similar in Drupal and thus for many Drupal developers and users, the inclination is to use or extend slightly that same concept, e.g. Boris' suggestion of how this is like grouping users in a taxonomy. Another suggestion I received for this centered on the similarities to organic groups (OG). One challenge in my particular instance is that the number of such groupings is large and only grows. Neither the taxonomy nor the OG model quite work for my situation directly. My use case is this: User A is in Group 3, and User B is in Group 9. They both navigate to the same URL, e.g. plist/entity. Both users see a list of entities in a table, but the specific rows in the displayed table are different, based on their groups. That is, the SQL "where" clause contains a phrase like "group_id = %d" or similar. If I can develop a generic solution that others can use, I'd be happy to do that. Since my module is specific to my application, that would probably mean developing an API. :-) ..chris

Moshe Weitzman wrote:

...

If I can develop a generic solution that others can use, I'd be happy to do that. Since my module is specific to my application, that would probably mean developing an API. :-)

see acl.module in na_arbitrator.module. it is bleeding edge, but probably a good basis. i plan to convert og to use it as a node_access backend. I want to actively support acl.module and am targeting getting a robust, well-tested and well-used version of it and the arbitrator (or arbiter if you prefer =) as a candidate for the 4.8 codebase. I think these are important tools for Drupal's future.