You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@hlmksw.com> on 2008/06/04 18:58:44 UTC
Discussion: Permissions Checking Enhancement
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
Re: Discussion: Permissions Checking Enhancement
Posted by Jacques Le Roux <ja...@les7arts.com>.
So refering to defintions in http://docs.ofbiz.org/display/OFBTECH/OFBiz+security this would be between the component menu level and
the screen level (which use "<if-has-permission" and "<if-service-permission" tags), that's it ?
It would be great to be able to hide menus as Bruno suggested (having a parameter in menu-item like David sugested for screens
def). It could be then named the menu level permission (we should then rename the component menu level to component level or even
application level)
In a 1st and generic approach we could use 2 user categories : experts and novices. By default the expert mode would be used (all
shown OOTB) but users could change this in their preferences to novice mode. So this would need to define what novice could and
should not see in all OFBiz (and should be updated later, being visible by default).
Later contributors could defines specific categories and they could be added to users's preferences choice. Could not roles be used
for that or is it really orthogonal ? (customer service can't see some accounting screens, but are able to view some other etc.).
My 2 cts
Jacques
From: "Bruno Busco" <br...@gmail.com>
> 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 <da...@hotwaxmedia.com>
>
>>
>> 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 <ad...@yahoo.com>
>>>
>>> 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 <br...@gmail.com> wrote:
>>>>
>>>> From: Bruno Busco <br...@gmail.com>
>>>>> 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 <ad...@hlmksw.com>
>>>>>
>>>>> 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 <ad...@hlmksw.com>:
>>>>>>>
>>>>>>> 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
>>>>>>>>>
>>>>>>>> <ad...@hlmksw.com>:
>>>>>
>>>>>>
>>>>>>>>> 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 <
>>>>>
>>>>>> sumit.pandit@hotwaxmedia.com>
>>>>>>>>>>> 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" <br...@gmail.com>
>>>>>
>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>> <ad...@hlmksw.com>:
>>>>>
>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>
Re: Discussion: Permissions Checking Enhancement
Posted by Bruno Busco <br...@gmail.com>.
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 <da...@hotwaxmedia.com>
>
> 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 <ad...@yahoo.com>
>>
>> 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 <br...@gmail.com> wrote:
>>>
>>> From: Bruno Busco <br...@gmail.com>
>>>> 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 <ad...@hlmksw.com>
>>>>
>>>> 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 <ad...@hlmksw.com>:
>>>>>>
>>>>>> 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
>>>>>>>>
>>>>>>> <ad...@hlmksw.com>:
>>>>
>>>>>
>>>>>>>> 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 <
>>>>
>>>>> sumit.pandit@hotwaxmedia.com>
>>>>>>>>>> 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" <br...@gmail.com>
>>>>
>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>> <ad...@hlmksw.com>:
>>>>
>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>
>>>
>>>
>>>
>>>
>
Re: Discussion: Permissions Checking Enhancement
Posted by David E Jones <da...@hotwaxmedia.com>.
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 <ad...@yahoo.com>
>
>> 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 <br...@gmail.com> wrote:
>>
>>> From: Bruno Busco <br...@gmail.com>
>>> 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 <ad...@hlmksw.com>
>>>
>>>> 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 <ad...@hlmksw.com>:
>>>>>
>>>>> 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
>>> <ad...@hlmksw.com>:
>>>>>>>
>>>>>>> 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 <
>>>>>>>>> sumit.pandit@hotwaxmedia.com>
>>>>>>>>> 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" <br...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>> <ad...@hlmksw.com>:
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>
>>
>>
>>
>>
Re: Discussion: Permissions Checking Enhancement
Posted by Bruno Busco <br...@gmail.com>.
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 <ad...@yahoo.com>
> 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 <br...@gmail.com> wrote:
>
> > From: Bruno Busco <br...@gmail.com>
> > 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 <ad...@hlmksw.com>
> >
> > > 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 <ad...@hlmksw.com>:
> > >>
> > >> 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
> > <ad...@hlmksw.com>:
> > >>>>
> > >>>> 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 <
> > >>>>>> sumit.pandit@hotwaxmedia.com>
> > >>>>>> 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" <br...@gmail.com>
> > >>>>>>>>
> > >>>>>>>> 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
> > <ad...@hlmksw.com>:
> > >>>>>>>>>
> > >>>>>>>>> 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
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>
>
>
>
>
Re: Discussion: Permissions Checking Enhancement
Posted by Adrian Crum <ad...@yahoo.com>.
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 <br...@gmail.com> wrote:
> From: Bruno Busco <br...@gmail.com>
> 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 <ad...@hlmksw.com>
>
> > 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 <ad...@hlmksw.com>:
> >>
> >> 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
> <ad...@hlmksw.com>:
> >>>>
> >>>> 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 <
> >>>>>> sumit.pandit@hotwaxmedia.com>
> >>>>>> 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" <br...@gmail.com>
> >>>>>>>>
> >>>>>>>> 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
> <ad...@hlmksw.com>:
> >>>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>
Re: Discussion: Permissions Checking Enhancement
Posted by Bruno Busco <br...@gmail.com>.
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 <ad...@hlmksw.com>
> 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 <ad...@hlmksw.com>:
>>
>> 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 <ad...@hlmksw.com>:
>>>>
>>>> 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 <
>>>>>> sumit.pandit@hotwaxmedia.com>
>>>>>> 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" <br...@gmail.com>
>>>>>>>>
>>>>>>>> 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 <ad...@hlmksw.com>:
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
Re: Discussion: Permissions Checking Enhancement
Posted by Adrian Crum <ad...@hlmksw.com>.
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 <ad...@hlmksw.com>:
>
>> 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 <ad...@hlmksw.com>:
>>>
>>> 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 <
>>>>> sumit.pandit@hotwaxmedia.com>
>>>>> 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" <br...@gmail.com>
>>>>>>>
>>>>>>> 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 <ad...@hlmksw.com>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>
Re: Discussion: Permissions Checking Enhancement
Posted by Bruno Busco <br...@gmail.com>.
Thank you,
it make sense; so a CREATE permission check will be sufficient for the
CREATE button rendering.
-Bruno
2008/6/6 Adrian Crum <ad...@hlmksw.com>:
> 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 <ad...@hlmksw.com>:
>>
>> 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 <
>>>> sumit.pandit@hotwaxmedia.com>
>>>> 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" <br...@gmail.com>
>>>>>>
>>>>>> 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 <ad...@hlmksw.com>:
>>>>>>>
>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>
Re: Discussion: Permissions Checking Enhancement
Posted by Adrian Crum <ad...@hlmksw.com>.
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 <ad...@hlmksw.com>:
>
>> 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 <
>>> sumit.pandit@hotwaxmedia.com>
>>> 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" <br...@gmail.com>
>>>>>
>>>>> 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 <ad...@hlmksw.com>:
>>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>
Re: Discussion: Permissions Checking Enhancement
Posted by Bruno Busco <br...@gmail.com>.
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 <ad...@hlmksw.com>:
> 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 <
>> sumit.pandit@hotwaxmedia.com>
>> 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" <br...@gmail.com>
>>>>
>>>> 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 <ad...@hlmksw.com>:
>>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>
Re: Discussion: Permissions Checking Enhancement
Posted by Adrian Crum <ad...@hlmksw.com>.
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 <su...@hotwaxmedia.com>
> 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" <br...@gmail.com>
>>>
>>>> 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 <ad...@hlmksw.com>:
>>>>
>>>>> 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
>>>>>
>>>>>
>
Re: Discussion: Permissions Checking Enhancement
Posted by Ashish Vijaywargiya <vi...@gmail.com>.
+1
Adrian I liked your idea.
On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit <su...@hotwaxmedia.com>
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" <br...@gmail.com>
>>
>>> 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 <ad...@hlmksw.com>:
>>>
>>>> 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
>>>>
>>>>
>>>
>
Re: Discussion: Permissions Checking Enhancement
Posted by Sumit Pandit <su...@hotwaxmedia.com>.
+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" <br...@gmail.com>
>> 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 <ad...@hlmksw.com>:
>>> 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
>>>
>>
Re: Discussion: Permissions Checking Enhancement
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes this sounds good to me too
Jacques
From: "Bruno Busco" <br...@gmail.com>
> 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 <ad...@hlmksw.com>:
>
>> 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
>>
>
Re: Discussion: Permissions Checking Enhancement
Posted by Bruno Busco <br...@gmail.com>.
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 <ad...@hlmksw.com>:
> 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
>