Closed JJediny closed 9 years ago
Updated initial text to make check boxes work
After looking at the existing MW groups, it's clear that their intention is not for authorization. The groups are joined by individual users and not managed by admin. Is this functionality useful? It seems like we could keep these user groups and add authorization groups.
Currently, only admins can edit NEPA Docs. I'm going to update the site so that viewing also requires admin creds and we can move forward from there.
Also note that MW currently has four authorization roles: admin, SU, editor, and developer.
We could use (and perhaps rename) these as an interim step to redeveloping the groups.
I'll leave the approach to you whatever is quick/straightforward but takes future extendability into account. Sounds like exploiting existing authorization roles and associating groups to those and assets to groups makes it the more practical for maintenance... In other words restricting editing of NEPA Documents to a group which inherits an authorization role to do so... and restrict the ability to create/join a group to the same auth role
Navigation updated so that NEPA resources are restricted to admin users.
What is most useful right now?
1) Using the existing roles so that we can assign users the ability to view/edit all NEPA resources. We can accomplish this in a few hours with existing authorization functionality.
2) Starting work on group authorization which will transform into class and object authorizations. This is going to happen eventually but will take significant development time.
NEPA Group memberships and permissions complete. Admins can create NEPA groups, add/remove users to those groups (i.e. manage memberships), and add/remove NEPA documents with readonly or edit permissions.
Phase 1 - Class Based Viewing Phase 2 - Object Based View/Edit Permissions