The user capabilities should sit and be changeable by anyone who has the
"userCapability("editCapability") or userCapability("editRole")". Doesn't
matter if it's a third party or not.
Roles should map to capabilities. The application is controlled by
capabilities, not roles. By assigning a role (or roles) to a user, the
administrator grants capabilties to a given user.
So, your application is driven by capabilities and any (authourised) person can
decide what role grants what capability.
If you do this you can add and remove new roles, without having to change your
application.
Naturally, there's a bit more work to do with it and security and scope
considerations to address.
Paul
----- Original Message -----
From: Gregor Kiddie
To: [email protected]
Sent: Wednesday, January 21, 2009 9:07 AM
Subject: RE: [flexcoders] Re: Roles Based UI
Not if the user capabilities are set by a third party, which is the situation
I dealing with.
I suspect our situation is drastically more complicated than the Ops though!
Gk.
Gregor Kiddie
Senior Developer
INPS
Tel: 01382 564343
Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ
Registered Number: 1788577
Registered in the UK
Visit our Internet Web site at www.inps.co.uk
The information in this internet email is confidential and is intended solely
for the addressee. Access, copying or re-use of information in it by anyone
else is not authorised. Any views or opinions presented are solely those of the
author and do not necessarily represent those of INPS or any of its affiliates.
If you are not the intended recipient please contact [email protected]
------------------------------------------------------------------------------
From: [email protected] [mailto:[email protected]] On
Behalf Of Paul Andrews
Sent: 21 January 2009 09:03
To: [email protected]
Subject: Re: [flexcoders] Re: Roles Based UI
I think <mx:Button id="deleteItem"
visible="{UserModel.getUserCapability(ItemTasks.DELETE)}" /> would be better.
There should be no need for code such as "if ( _activities.include(
_taskMapping[ task ] ) && configuration.taskAllowed( task ) ) {" . The user
capabilities should be assigned by the role - once only.
Paul
----- Original Message -----
From: Gregor Kiddie
To: [email protected]
Sent: Wednesday, January 21, 2009 8:41 AM
Subject: RE: [flexcoders] Re: Roles Based UI
hasPermission(.) is better than hasRole(.), but the reason we are moving
towards the component mapping approach is that hasPermission(.) could end up
returning something anomalous if your business logic gets complicated (which is
where we lie). If it is as simple as ( some activity == true ) then
hasPermission(.) works, but if the internal business logic gets expanded past
role based access to include, for example system configuration (or even whether
the user has paid for a particular feature), hasPermission(someActivity) may
end up returning false, even if they DO have that activity.
Not to mention again, by assigning activities to each of the components
involved, you've exposed your authentication system to the rest of the
application, which makes it harder to replace / swap.
Corporate restrictions prevents me from posting any real code, but
something like
<mx:Button id="deleteItem"
enabled="{UserModel.getUser(userKey).hasAccess(ItemTasks.DELETE)}" />
In User.as
public function hasAccess( task : String ) {
if ( _activities.include( _taskMapping[ task ] ) &&
configuration.taskAllowed( task ) ) {
return true;
}
return false;
}
P.S. Ignore some of the more funky quirks in my code. There are a few
hangovers there. And I do believe we are mainly arguing semantics at this point
;)
Gk.
Gregor Kiddie
Senior Developer
INPS
Tel: 01382 564343
Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ
Registered Number: 1788577
Registered in the UK
Visit our Internet Web site at www.inps.co.uk
The information in this internet email is confidential and is intended
solely for the addressee. Access, copying or re-use of information in it by
anyone else is not authorised. Any views or opinions presented are solely those
of the author and do not necessarily represent those of INPS or any of its
affiliates. If you are not the intended recipient please contact
[email protected]
----------------------------------------------------------------------------
From: [email protected] [mailto:[email protected]] On
Behalf Of Yves Riel
Sent: 20 January 2009 17:34
To: [email protected]
Subject: RE: [flexcoders] Re: Roles Based UI
In our case, we use a similar scheme except that we have roles and
permissions. It is the permission that defines the access to the component. If
the user, in his role, has the permission set to true, then the user gain
access to the component. It is very flexible as you can create many roles will
similar or different permissions. At the end, you do not tie up the UI to a
specific role but to a permission.
E.g.
<mx:Button id="btndelete1" enabled="User.hasPermission('CanDelete')" />
<mx:Button id="btndelete2" enabled="User.hasPermission('CanDelete')" />
<mx:Button id="btnAdd" enabled="User.hasPermission('CanAdd')" />
etc...
You can see here that two buttons can be displayed using the same
permission.
----------------------------------------------------------------------------
