#47 Gradations of priviledge for UI
Closed: Fixed None Opened 13 years ago by rcritten.

The question is, what drives what is displayed for a given user in the UI? Do we want to query every single thing they can do and only show or use some sort of Low, Medium, High delegation to broadly define what a user may do?


In v1 there were 2 ways in which to get access to the administrative UI. You had to either be in the admins group which made you a full admin or be in the editors group. Members of the editors group were granted permissions via a delegation.

Looks like rolegroups is the right abstraction for this.

Since it looks like there is a (*)admin rolegrop for each entity, we can decide based on membership in that rolegroup whether to show that tab/facet or not.

Thus, if the user has membership in the enrollhost rolegroup, they will see the enrollhost facet.

Thus, if the user has membership in the certadmin rolegroup, they will see the certificate tab

The whoami plugin will return the set of rolegroups for the logged in user. We will use this to build the navigation structure.

For IPA v2 the plan is to detect is the user is a member of any role groups. If he is not only self service screen will be display for him. Otherwise we will display full UI. The rest of the screen granularity has been moved into the ticket #217

We have two grades as of now: admin, and self service. While the self-service view requires some additional work, the role based aspect of it is completed.

Metadata Update from @rcritten:
- Issue assigned to admiyo
- Issue set to the milestone: FreeIPA 2.0 - 2010/09

7 years ago

Login to comment on this ticket.

Metadata