I agree that proxy objects are great. I am wondering though if we want to give permissions per object type if we should not provide an easier method than using the query-writer approach by "just" making object_types objects.
I am now faced with the situation that I need to give permission to create various object types through an external interface. The only requirement is that the users can create, write and delete (for the sake of discussion) "tasks, projects,files,comments". Write and delete is a piece of cake, though it implies to either be stuck with a lot of entries into the permission table or to group them into proxy objects / roles in the code.
But what should I do with create? Here I need the proxy object, because I cannot give create permissions on a not yet created object. We could argue to say that "if you have create permissions on the context_id then you are allowed to create the object". But is this right? And wouldn't I still have to check if I am allowed to have write permission on the object_type?
This being said, it can all be done with the existing permission system and making object_types objects has nothing to do with it. But I am still unsure how "create" should behave 😊.
Now to something more interesting:
Assuming object_types are objects (or I use rel_segments), if I have read access to an object_type (rel_segment) I have access to the object of that type if I have access to the context_id. Meaning: If I have read access on tasks in general, I am able to view a task if I have read access on the project.
I will ponder about this a little bit more while working out how to map an external permission system (meaning remote, not in OpenACS) to the generic way of permissions in OpenACS so I do not have to touch every part of OpenACS to get those external permissions working and do not have to query the external permissions on every page but can "cache" them in the OpenACS permission system.