Nima Mazloumi on 06/04/07 01:33 AM:
"I agree. The problem is, that status changes take place in an external system. I could make it a requirement that OACS is informed via web services about those changes."
Sure, this is all true... and you could solve the -external- issue. But by "status change" I really just meant the following actions:
- Adding a user to the system (which would somehow accept info about the user's status and then you set permissions accordingly)
- user's external state change, where somehow this change is reported to the openacs instance, which responds by altering permissions
with the ultimate result being that:
- all changes are (somehow) communicated to the -permission system-
- no additional queries are needed in the openacs code beyond checking the -permission system-, and
- therefore already-written code will already work for free, because it does check the -permission system- already.
The permission system is very robust, flexible, easy to use, nice api; overall it's great. I'd suggest using it!
Additionally, you will probably want to store the status in a table but only for the purpose of keeping together what could be a -set of- permission settings meant to implement -one- status. That way, it will be easy to undo changes; you can have API that lets you say "Freddie Freeloader's status has changed from Student-in-physics-classnumber-1234 to Teachers-assistant-for-physics-classnumber-1234" causing potentially many revocations and grants on many objects, as well as removals and adds to groups which already have appropriate permissions on appropriate objects.
