The user permissions should be detected based on the roles. This means that all the things that user can affect should be retrieved and stored somewhere in the session, probably in a cookie. Requesting this per operation is probably too costly. Each screen should consult with this list and UI elements should be enabled/disabled based on those permissions.
User should not be allowed to click add button and fill the form only to figure out that he does not have permissions to add an object. The button should be just not active for him the first place.
This have been one of the core requirements for UI from the beginning.
http://www.freeipa.org/page/V2BPRD item [14.2]
I think we want to get this in before V2.
This is a requirement for going live. Since it uses leverages never-before-used DirSrv functionality, we consider it high risk, and want a good amount of time to shake it out.
The see ldap2 method can_write() for an example of Get Effective Rights (GER). You will probably need something much more generic.
My though was to have a hidden method (hidden to the CLI anyway) that you could run against an object to find out what it can do.
Remember that entry rights (add, delete) may be different from attribute rights (read, write, search, etc). So it is very possible that someone can add records but not edit the results.
attachment freeipa-admiyo-freeipa-0072-rights-check.patch
Fixed with aff2816
Metadata Update from @dpal: - Issue assigned to admiyo - Issue set to the milestone: FreeIPA 2.0 - 2010/10
Login to comment on this ticket.