Hi, I have few suggestions on this.
1. IMO we need to merge all edit related actions to one section + Need to order the action bar with proper priority 2. In UI *Public to everyone *and *Public to internal users *do not showing the proper separation between their domains. we need to use intuitive wording including the permission that we are assigning be default. 3. IMO Once you add any role from the list, we need to remove added role from existing dropdown, otherwise user will think that they can add it again. 4. I think its good to provide some descriptive message to show how this permissions will effect on each role. (AFAIK we are providing hierarchical permission model for this, so we need to educate user on this) Just my two cents. :) Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Senior Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Mon, Oct 26, 2015 at 2:11 PM, Mushthaq Rumy <[email protected]> wrote: > Hi all, > > I'm going to implement a permission model for the GReg publisher which the > scenario is somewhat similar to the permission model in the management > console. > > There are some issues in the permission model of the management console. > > 1. The CRUD operation semantic is not well defined. > Eg: A role which has *write* permission might not have *read* > permission > > 2. A complex matrix grid of permission which causes user unfriendliness. > > I'm planning to fix these issues in the permission model for the GReg > publisher. The UI wireframe and the flow of the model will be as follows. > > 1. The user will be able to navigate to the permission screen by clicking > the *Permissions *tab on the top of the screen as shown below. > > [image: Inline image 2] > > 2. The user will be able to restrict the resource with *read only* > permission to all the internal users by checking the *Public to internal > users *option. > > [image: Inline image 1] > > 3. The user will be able to share the resource with *read only* > permission to all the public users by clicking the *Public to everyone * > option. > > [image: Inline image 2] > > 4. The user will be able to share the resource with other roles by > checking the *Share with other roles *option, selecting the role to share > and selecting the permission to give the selected role. > > [image: Inline image 3] > [image: Inline image 3] > > 5. The user will be able to remove the added permissions by clicking the *x > *link of a particular permission. > > Are there any improvements i can make to the above design. Appreciate your > suggestions. > > Thanks & Regards, > > -- > Mushthaq Rumy > *Software Engineer* > Mobile : +94 (0) 779 492140 <%2B94%20%280%29%20773%20451194> > Email : [email protected] > WSO2, Inc.; http://wso2.com/ > lean . enterprise . middleware. > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
