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.
------------------------------------------------------------------------------
