Re: Discussion: Permissions Checking Enhancement

[David E Jones]

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