Ive revamped Nodelet Settings to use nodelet permissions In a sense this can be seen as a prototype of what I want to do with the approval system.

My proposal is this: We add a column to the nodegroup table to store either a flag or nodetype of the node mentioned. This flag/nodetype tells us if the entry is a user/group/evalable rule. The user/group scenario would be unchanged. The evalable rule would be evalled and then its return would determine what would happen. I propose that if it returns 0 it is a deny access rule and says the user is explicity NOT approved despite any further rules or group memberships. If it returns 1 it implies the user is explicitly approved and not to bother searching the rest of the list. If it returns undef it implies that the rule doesnt apply at all and to continue applying further rules or checking further membership.

The paralel here is that the "apply_order" is much like a group list, (forget about the fact that we are dealing with lists of things you can see based on membership, pretend the results are just 1/undef). The entries in the setting that start with \s*{ are code rules that are evalled, the other entries just return a list.

The advantages of using a flag are that we can have different types of "evalable" rule and still have a petty efficient system, the advantage of type is that it could be used with the PM inheritance system to say that anything inheriting from a particular nodetype has rule like behaviour. I could go either way.

The reason the flag/nodetype is necessary IMO is because we dont want to do a nodefetch on every node in the usergroup table to find out its type. I dont see much reason in forcing the caching of the full node of all the users in the various groups. Maybe im missing something and this cost is acceptable. It certainly would make the endeavour a lot easier to do as it wouldnt requiring changing the table structure or any of the code that interacts with the table (of which there is a fair amount.)

Please feed me criticism on any of this. Cheers.

'nuff said

Note that this name need to have associated with it various blurbs like "Add a new ..." and "Foo.." in the code, as well as some stuff configured in the Newest Nodes Setting's. So whatever name you think of has to be amenable to these needs.