Hmmm. That is an idea. I could actually synch up the existing data myself before I give the client the next build. Then I suppose I could add some code to my Users form to update the RBS data with the user data that has been added or edited. It is unlikely that they will add new roles, but just in case they do, I could add code to update the roles in RBS. Do you think that would work? The only snag I can see is that the PK's have to match.

Ehhh....that could be tough.  Not saying it is impossible, but you will have to "sync" up the SFSUsers and your users tables so that RBS authenticates off of the SFSUsers versus your users.  What I would do is just write a conversion program that is run the first time the app is executed with the RBS that converts your existing users and roles into the RBS users tables and sets their permissions.  That is going to be easier than tryin to make two different applications work together.

Ok, Trent. Now you really asked for it

I already have a table in my existing application to store user names and another for their roles. Can I continue to use my tables and still hook into RBS just for the purposes of saving the current users login id?

Yeah - I figured that out right after I posted that reply

Just open up the Activation client and deactivate your current license.  Then go back in and re-activate your license and you will be able to pick both the framework and RBS licenses.

OK - I hate to be stupid but I just purchased the RBS module. Now how do I activtivate the license?

No - eventually I am going to purchase your role based security module because it is going to be cheaper for my client than having me write one from scratch

Basically he is telling you that since you have your own security to write your own logic that the RBS already has built in.  The SecurityBasics is totally useless of you are using RBS.  But what Greg was referring to is that we have a CurrentUserChanged shared event that can be handled and is raised when the logged in user is changed.  When this happens, the CurrentUser information along with all of their permissions, etc. are updated.  This ensures that you can always and reliably use the CurrentUser PK, user name, permissions, etc. and it is all event driven.  We have tapped into this event for a number of different purposes in our medical application which makes updating the environemtn based on the current users permissions much easier.  Also, we have a user stamp column on every table in our system so we can see which user created every record in our entire application.  There are a lot of benefits, but Greg was just trying to explain how the SF RBS works so you could write your own since you are already going down this road.

Sort of. Thanks for your input.

Marcia,



Well, you could just take a play out of the SF playbook and in your login code, raise a CurrentUserChanged event. Then handle this event to update whatever you need to.



As to were to save this off, you'd probably want to save it way down in a base/library class, that every other class is already referencing anyway (this should probably be were the other security code is also). SF uses static class/method to do this, so it is easy to access from anywhere: SecurityBasics.CurrentUser. This works very well, so if I had to roll my own security, I'd likely follow this sort of design. Does that make sense/help?