No, please, keep this on line. I have been following it closely because I will be designing and implementing a permissions system in the next couple months. I am finding the discussion very helpful.
Tracy Spratt Lariat Services Flex development bandwidth available ________________________________ From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Paul Andrews Sent: Wednesday, January 21, 2009 5:08 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: Roles Based UI Yes, though it's a refreshing change for a flexcoders thread to go beyond the problems of the mechanics of writing an application and include the wider issues. I sometimes think that given the convoluted use of flex we sometimes see, a broader view is sometimes beneficial. Paul ----- Original Message ----- From: Gregor Kiddie <mailto:gkid...@inpses.co.uk> To: flexcoders@yahoogroups.com <mailto:flexcoders@yahoogroups.com> Sent: Wednesday, January 21, 2009 9:57 AM Subject: RE: [flexcoders] Re: Roles Based UI I think this is a good candidate for taking offline huh ;) 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 <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 is.helpd...@inps.co.uk ________________________________ From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Paul Andrews Sent: 21 January 2009 09:53 To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: Roles Based UI Gregor, I just wanted to say that while I do believe that for role based applications (something beyond 'user' and 'admin') the approach I outlined is a good way to go, I fully understand that implementation of roles is down to a lot of considerations and not everyone has the time (or inclination) to separate roles from capabilities. In my case the client needed a sophisticated system that allowed administrators to assign and change roles and even grant/remove individual capabilities all within a security system controlling the scope for changes. These capabilities were held as part of the user data and the application did not take account of roles (except as a means of assigning capabilities). The developers did not assign or even define roles (except for the initial minimal roles). I'm not being a dictator - few clients want or need the sophistication that we built for that system. It was a great system (if I say so myself!). Paul ----- Original Message ----- From: Paul Andrews <mailto:p...@ipauland.com> To: flexcoders@yahoogroups.com <mailto:flexcoders@yahoogroups.com> Sent: Wednesday, January 21, 2009 9:18 AM 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:gkid...@inpses.co.uk> To: flexcoders@yahoogroups.com <mailto:flexcoders@yahoogroups.com> 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 is.helpd...@inps.co.uk ________________________________ From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Paul Andrews Sent: 21 January 2009 09:03 To: flexcoders@yahoogroups.com 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:gkid...@inpses.co.uk> To: flexcoders@yahoogroups.com <mailto:flexcoders@yahoogroups.com> 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 is.helpd...@inps.co.uk ________________________________ From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Yves Riel Sent: 20 January 2009 17:34 To: flexcoders@yahoogroups.com 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. ________________________________
