David, I like this idea. So we should add a screen property to specify a permission. The same permission should be checked to render the menu item that takes to that screen (sub-screen). Is this what you mean?
This could be done even without the "getAllPermissions" service proposed, am I right? -Bruno 2008/12/3 David E Jones <[EMAIL PROTECTED]> > > One option for this (or at least part of it), and one that I think has been > discussed before, would be to introduce a convention for naming permissions > (or more to the point, "ID-ing" permissions) based on screen names and > locations. A few aspects of this: > > 1. We could configure specific screens to always require the > screen-specific permission, or to require either a general permission > (probably specified in the screen def) or the screen-specific permission > > 2. this would be a view-only permission for rendering the screen > > 3. doing it for each screen defined would allow for permissions on > sub-screens and such as well > > -David > > > > On Nov 30, 2008, at 12:32 AM, Bruno Busco wrote: > > I need to simplify the UI has I described. >> To do this I think the Map should contain ALL user permissions, not >> restricted to a single application. >> Could we think to specific permissions to hide the TabBar options? >> >> I understand that OFBiz UI is designed to have ALL there because at least >> everybody sees that a feature is available but this creates a problem when >> deplying to end user. >> I understand also that the perfect UI is the one that reproduces the very >> specific users workflow and so it must be written ad hoc. >> But having an 80% fitting UI with only permissions setting (user >> profiling) >> could be a good result. >> >> This IMO is another key factor for spreading OFBiz and having more people >> using it. >> >> I would like to hear other idea about this and, possibly, some user >> profiling pattern ideas. >> For sure the Portlet system will help in this direction but could we think >> to a UI profiling through permission too? >> >> -Bruno >> >> 2008/11/30 Adrian Crum <[EMAIL PROTECTED]> >> >> Bruno, >>> >>> I never got around to implementing that idea. I would still like to work >>> on >>> it though. >>> >>> -Adrian >>> >>> >>> --- On Sat, 11/29/08, Bruno Busco <[EMAIL PROTECTED]> wrote: >>> >>> From: Bruno Busco <[EMAIL PROTECTED]> >>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>> To: dev@ofbiz.apache.org >>>> Date: Saturday, November 29, 2008, 10:30 AM >>>> Hi Adrian, >>>> I am thinking to something similar to what you proposed in >>>> this thread. >>>> What I would like to do is to simplify the UI to users who >>>> should not >>>> perform some operations. >>>> >>>> For instance, in the catalog application, when looking to >>>> the EditProduct >>>> screen, I would like that the following tabmenus: >>>> Geos, IDs, Keywords, Associations, Manufacturing, Costs, >>>> Attributes, >>>> Agreements, Accounts, Maintenance, Meters, Workefforts >>>> >>>> should not be visible to standard users while they should >>>> be visible to >>>> admin. >>>> >>>> I am thinking to implement several permissions (may be some >>>> are already >>>> there) and to check for them in the menu items. >>>> What do you think? >>>> Did you implement something about it? >>>> >>>> Thank you, >>>> -Bruno >>>> >>>> 2008/6/6 Adrian Crum <[EMAIL PROTECTED]> >>>> >>>> Correct. >>>>> >>>>> >>>>> Bruno Busco wrote: >>>>> >>>>> Thank you, >>>>>> it make sense; so a CREATE permission check will >>>>>> >>>>> be sufficient for the >>>> >>>>> CREATE button rendering. >>>>>> -Bruno >>>>>> >>>>>> 2008/6/6 Adrian Crum <[EMAIL PROTECTED]>: >>>>>> >>>>>> The pattern used so far is that the ADMIN >>>>>> >>>>> permission is checked first, >>>> >>>>> then >>>>>>> the other permissions. So if a user has the >>>>>>> >>>>>> ADMIN permission, they don't >>>> >>>>> need the additional permissions. >>>>>>> >>>>>>> I'll probably have all of the permissions >>>>>>> >>>>>> Map elements set to true if the >>>> >>>>> user has the ADMIN permission. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> Bruno Busco wrote: >>>>>>> >>>>>>> Adrian, >>>>>>> >>>>>>>> may be a newbie question but... >>>>>>>> ...in the example you give what will >>>>>>>> >>>>>>> happen if a user has the ADMIN >>>> >>>>> permission but not the CREATE one? >>>>>>>> Will the Create New button be rendered? >>>>>>>> >>>>>>>> In other words who is responsible for the >>>>>>>> >>>>>>> permission hierarchy ? >>>> >>>>> In order to display the CREATE button, >>>>>>>> >>>>>>> should a user be given with the >>>> >>>>> CREATE permission explicitly or the ADMIN >>>>>>>> >>>>>>> is sufficient? >>>> >>>>> >>>>>>>> Thank you >>>>>>>> -Bruno >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2008/6/6 Adrian Crum >>>>>>>> >>>>>>> <[EMAIL PROTECTED]>: >>>> >>>>> >>>>>>>> I'll work on it this weekend. >>>>>>>> >>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> Ashish Vijaywargiya wrote: >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> Adrian I liked your idea. >>>>>>>>>> >>>>>>>>>> On Thu, Jun 5, 2008 at 12:46 AM, >>>>>>>>>> >>>>>>>>> Sumit Pandit < >>>> >>>>> [EMAIL PROTECTED]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>>> Sumit Pandit >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Jun 5, 2008, at 3:04 AM, >>>>>>>>>>> >>>>>>>>>> Jacques Le Roux wrote: >>>> >>>>> >>>>>>>>>>> Yes this sounds good to me >>>>>>>>>>> >>>>>>>>>> too >>>> >>>>> >>>>>>>>>>> Jacques >>>>>>>>>>> >>>>>>>>>>> From: "Bruno >>>>>>>>>>>> >>>>>>>>>>> Busco" <[EMAIL PROTECTED]> >>>> >>>>> >>>>>>>>>>>> Wonderfull !!!! >>>>>>>>>>>> >>>>>>>>>>>> Looking forward to having >>>>>>>>>>>> >>>>>>>>>>> it !!! ;-) >>>> >>>>> This will let me also >>>>>>>>>>>>> >>>>>>>>>>>> define a more granular permissions to >>>> >>>>> simplify >>>>>>>>>>>>> the >>>>>>>>>>>>> interface for >>>>>>>>>>>>> >>>>>>>>>>>> not-so-skilled users. >>>> >>>>> -Bruno >>>>>>>>>>>>> 2008/6/4 Adrian Crum >>>>>>>>>>>>> >>>>>>>>>>>> <[EMAIL PROTECTED]>: >>>> >>>>> >>>>>>>>>>>>> In the screen >>>>>>>>>>>>> >>>>>>>>>>>> widgets, you can check permissions with the >>>> >>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> <if-has-permission> or <if-service-permission> >>>> elements. That's >>>> >>>>> fine >>>>>>>>>>>>>> if >>>>>>>>>>>>>> you >>>>>>>>>>>>>> only need to check >>>>>>>>>>>>>> >>>>>>>>>>>>> a single permission to control access to the >>>> >>>>> entire >>>>>>>>>>>>>> screen. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Things get >>>>>>>>>>>>>> >>>>>>>>>>>>> complicated when a screen's elements are controlled by >>>> >>>>> more >>>>>>>>>>>>>> than >>>>>>>>>>>>>> one permission. >>>>>>>>>>>>>> >>>>>>>>>>>>> Let's say you have a typical Edit Item screen. The >>>> >>>>> screen >>>>>>>>>>>>>> should be viewable >>>>>>>>>>>>>> >>>>>>>>>>>>> only to users who have the VIEW permission. >>>> >>>>> Users >>>>>>>>>>>>>> who >>>>>>>>>>>>>> have the UPDATE >>>>>>>>>>>>>> >>>>>>>>>>>>> permission can edit the item. Users who have the >>>> >>>>> CREATE >>>>>>>>>>>>>> permission see a >>>>>>>>>>>>>> >>>>>>>>>>>>> "New Item" button. Users who have DELETE >>>> >>>>> permission >>>>>>>>>>>>>> see >>>>>>>>>>>>>> a >>>>>>>>>>>>>> "Delete >>>>>>>>>>>>>> >>>>>>>>>>>>> Item" button. Users who have the ADMIN permission have >>>> >>>>> unrestricted >>>>>>>>>>>>>> access to the >>>>>>>>>>>>>> >>>>>>>>>>>>> screen. Wow. Five permission elements (and five >>>> >>>>> service >>>>>>>>>>>>>> calls) >>>>>>>>>>>>>> are needed to >>>>>>>>>>>>>> >>>>>>>>>>>>> control one screen. >>>> >>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here's my >>>>>>>>>>>>>> >>>>>>>>>>>>> idea: have a permission service that returns ALL of the >>>> >>>>> user's >>>>>>>>>>>>>> permissions in a >>>>>>>>>>>>>> >>>>>>>>>>>>> Map. You call the service with the permission to >>>> >>>>> check >>>>>>>>>>>>>> - >>>>>>>>>>>>>> >>>>>>>>>>>>>> "ACCOUNTING" for example. The service returns a >>>> Map containing all >>>> >>>>> of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> user's >>>>>>>>>>>>>> >>>>>>>>>>>>> ACCOUNTING permissions stored as Boolean objects. Let's >>>> say >>>> >>>>> the >>>>>>>>>>>>>> returned Map is >>>>>>>>>>>>>> >>>>>>>>>>>>> called permissionsMap and the user has >>>> >>>>> ACCOUNTING_VIEW >>>>>>>>>>>>>> and >>>>>>>>>>>>>> ACCOUNTING_UPDATE >>>>>>>>>>>>>> >>>>>>>>>>>>> permissions, then the Map would contain these >>>> >>>>> elements: >>>>>>>>>>>>>> >>>>>>>>>>>>>> CREATE=false >>>>>>>>>>>>>> UPDATE=true >>>>>>>>>>>>>> DELETE=false >>>>>>>>>>>>>> VIEW=true >>>>>>>>>>>>>> ADMIN=false >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the service >>>>>>>>>>>>>> >>>>>>>>>>>>> call is put in the screen's <actions> element, >>>> then >>>> >>>>> the >>>>>>>>>>>>>> Map >>>>>>>>>>>>>> elements could be >>>>>>>>>>>>>> >>>>>>>>>>>>> used to control the display of screen widget >>>> >>>>> sections, >>>>>>>>>>>>>> menu items, and >>>>>>>>>>>>>> >>>>>>>>>>>>> form fields. >>>> >>>>> >>>>>>>>>>>>>> Freemarker code >>>>>>>>>>>>>> >>>>>>>>>>>>> would be simpler too: >>>> >>>>> >>>>>>>>>>>>>> <#if >>>>>>>>>>>>>> >>>>>>>>>>>>> permissionsMap.CREATE> >>>> >>>>> <!-- Render a >>>>>>>>>>>>>> >>>>>>>>>>>>> Create New button --> >>>> >>>>> </#if> >>>>>>>>>>>>>> <#if >>>>>>>>>>>>>> >>>>>>>>>>>>> permissionsMap.DELETE> >>>> >>>>> <!-- Render a >>>>>>>>>>>>>> >>>>>>>>>>>>> Delete button --> >>>> >>>>> </#if> >>>>>>>>>>>>>> >>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> >>> >>> >>> >>> >
