UIs implement features and Roles encapsulate features pertinent to a role. Implement the UI in terms of permitted features and assign feature sets to a given role.
Paul ----- Original Message ----- From: "ilikeflex" <[email protected]> To: <[email protected]> Sent: Tuesday, January 20, 2009 6:09 PM Subject: [flexcoders] Re: Roles Based UI Hi It make sense the way you have implemented. Then you need to store the mapping between the permissions and role. correct???? and what do you do when a new role is added. Thanks ilikeflex --- In [email protected], "Yves Riel" <r...@...> wrote: > > 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. > ________________________________ > > From: [email protected] [mailto:[email protected]] On Behalf Of ilikeflex > Sent: Tuesday, January 20, 2009 12:00 PM > To: [email protected] > Subject: [flexcoders] Re: Roles Based UI > > > > Hi > > Do you mean to say that i should do something like this > <mx:Button id="btndelete" visiblie"User.hasAccess("btndelete")/> > > In the above i am passing the id of the component. > > Then this means that i have to make some mapping between the > component and Role. > > I think this will be more difficult to manage. > > Let me know as you are already implementing it. If you could some > psuedo code then it will be great. > > Thanks > ilikeflex > > --- In [email protected] <mailto:flexcoders% 40yahoogroups.com> , "Gregor Kiddie" <gkiddie@> > wrote: > > > > As someone who is currently re-working their Role Based Access > Control mechanism, point 2 is the wrong way around. > > > > It leaks the roles into the rest of the client and stops all your > business logic being in one place. Incidentally, this is how we > currently do it, and I can show how it's a pain when new roles are > added. > > > > The better solution is to bind the visibility (enabled, etc, > however you deal with not having the correct authorization) of the > UIComponent to a hasAccess( componentKey : String ) method on the > User class. > > > > This has benefits of meaning that all the code for deciding on > access is in one place (and makes it very easy to alter / add / > remove roles and components), and by binding it, if the > authentication changes for any reason, the view can be updated > quickly and cleanly. > > > > > > > > A pitfall to watch out for is hiding pieces of UI which has > unexpected behaviour. For example, not showing a piece of the form if > the user doesn't have the auth to change that data, if your backend > deletes any data it isn't sent by the client, it is easy to turn > a "not authorised" into a "delete lots of data". So make sure your > client behaviour fits the use cases defined by your back end. > > > > > > > > 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/ <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.helpdesk@ > > > > ________________________________ > > > > From: [email protected] <mailto:flexcoders% 40yahoogroups.com> > [mailto:[email protected] <mailto:flexcoders% 40yahoogroups.com> ] On Behalf Of Dimitrios Gianninas > > Sent: 20 January 2009 14:33 > > To: [email protected] <mailto:flexcoders% 40yahoogroups.com> > > Subject: RE: [flexcoders] Roles Based UI > > > > > > > > Pretty simple: > > > > > > > > 1) Once you app is loaded, call your server to load the user info > > > > 2) Assuming you have a User class with a method isUserInRole( > role:String ); ... then use this on various Buttons/fields/views to > show/hide based on if the user has a particuliar role or not > > > > > > > > Dimitrios Gianninas > > > > RIA Developer Team Lead > > > > Optimal Payments Inc. > > > > > > > > > > > > ________________________________ > > > > From: [email protected] <mailto:flexcoders% 40yahoogroups.com> > [mailto:[email protected] <mailto:flexcoders% 40yahoogroups.com> ] On Behalf Of ilikeflex > > Sent: Monday, January 19, 2009 1:18 AM > > To: [email protected] <mailto:flexcoders% 40yahoogroups.com> > > Subject: [flexcoders] Roles Based UI > > > > Hi > > > > I am developing role based GUI. Can anybody please point to best > > practices or any flex article which can help to achieve this. > > > > Thanks > > ilikeflx > > > > AVIS IMPORTANT > > > > WARNING > > > > Ce message électronique et ses pièces jointes peuvent contenir des > renseignements confidentiels, exclusifs ou légalement privilégiés > destinés au seul usage du destinataire visé. L'expéditeur original ne > renonce à aucun privilège ou à aucun autre droit si le présent > message a été transmis involontairement ou s'il est retransmis sans > son autorisation. Si vous n'êtes pas le destinataire visé du présent > message ou si vous l'avez reçu par erreur, veuillez cesser > immédiatement de le lire et le supprimer, ainsi que toutes ses pièces > jointes, de votre système. La lecture, la distribution, la copie ou > tout autre usage du présent message ou de ses pièces jointes par des > personnes autres que le destinataire visé ne sont pas autorisés et > pourraient être illégaux. Si vous avez reçu ce courrier électronique > par erreur, veuillez en aviser l'expéditeur. > > > > This electronic message and its attachments may contain > confidential, proprietary or legally privileged information, which is > solely for the use of the intended recipient. No privilege or other > rights are waived by any unintended transmission or unauthorized > retransmission of this message. If you are not the intended recipient > of this message, or if you have received it in error, you should > immediately stop reading this message and delete it and all > attachments from your system. The reading, distribution, copying or > other use of this message or its attachments by unintended recipients > is unauthorized and may be unlawful. If you have received this e- mail > in error, please notify the sender. > > > ------------------------------------ -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Alternative FAQ location: https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links
