This is something I’ve actually been thinking about tackling for a while, but with other projects looming it’s been pushed to the back burner —

One solution, which mirrors what Boris suggested: create multi-author nodes — the original author could specify additional authors (or readers, as they desired) when they created the node. If autocomplete (like in freetagging) was enabled for the additional author fields, this would scale just fine — type in the first few letters of a user, and you’re good to go — no drop down list necessary. The more robust (but, for the end user, potentially more confusing option) involves letting the original node creator select users or roles. The potential access levels could be: add editors/edit content/read content.

http://www.hiveminds.co.uk/node/899

This is partial because though I have worked out the database schema there is still a question of usability. Trying to get an all encompassing list of rights per role that does not turn into a GUI that confuses the user. The second problem is trying to make sense of the rights per module, finding a common ground that developers can use in any situation. Access control on a module package like e-commerce is very hard to simplify to a CRUD model. While a contact.module has very simple needs and CRUD may be too much.

Think about how to do it in Flickr: JUST as hard — make a private group and invite the N people you want to have access.

Merlinofchaos’ na-arbitrator is likely the basis on which you would build something like this. You would want a 4.7-based type ahead widget for selecting users, and then choose a read/write/etc. access level.

Carl – agreed. This is going to take some effort on the UI, not just in code. There are some examples to be learned from though.

Bill – I’m using Simple Access, and it rocks for small-ish groups that are known in advance and managed by an admin. Since it’s tied to Roles, it just can’t scale, and users can’t create their own. I actually talked about Simple Access about half-way through this post

I’ve been thinking about this over the last few days, and it could make a good Summer of Code project. Is this something you want to develop in house, or do you think it would be useful to write up a spec as a proposed project?

If it doesn’t conflict with any development you are doing/planning, I’d be glad to write up the spec.

Whether it winds up being done in house (or in several houses) I think a solid spec would help. If nothing else, than to serve as a design doc.

I just set up a wiki page for the doc. If there’s a better or more appropriate home for it, I’ll take that page down.

When I’ve got a better idea of what’s involved, I’ll flesh out the proposal – it could be that I’m not understanding the problem enough yet, so I’ll work on that first

http://drupal.org/project/nodeaccess