Yeah my example doesn't actually include roles as they are only a convenience mechanism for assigning groups of activities. But we have the dichotomy of the third party controlling the assignment of activities (the third party is not our user group btw and there are legal aspects to which activities a user is assigned), and our users controlling configuration (which interacts with the assigned activities), so we have to handle both in a sensible way.
As I said though this is way beyond the OP's original question. 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 <blocked::http://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:19 To: [email protected] Subject: Re: [flexcoders] Re: Roles Based UI 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 <mailto:[email protected]> To: [email protected] <mailto:[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 <blocked::http://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 <mailto:[email protected]> To: [email protected] <mailto:[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 <blocked::http://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. ________________________________
