I need to both allow the user to log out (so another user can login) and handle session locking. I know the SessionLock.LockSession is used to do this sort of thing and session locking is on by default when a SF security project is created. What I'm confused about is what exactly happens. Here are some of the things I need to handle:



- session locks, user logs back in (this one is easy and already handled by LockSession)

- user logs off so another can log on (mostly used by testers), permission will likely be different.

- session locks, the user decides to close rather than unlock

- session locks, user has unsaved changes, decides to close

- session locks, another user logs on, original use has opened forms (maybe with pending edits), permissions might be different



So, suggestions on how to handle these cases?



Mainly, I'm wondering how permissions are handled with open form are shown when a different user unlocks the session, how to handle unsaved changes when a new user logs in or the user decides to exit first (of course, it might not be the user that was logged in that is exiting) and how to allow the application to close form a locked session.



Thanks!

Hi Greg.

I think this is nicely handled by the framework.

In my application's MainForm ToolStrip, I've created a "Login" button, with the following code:

F11 is the SF shortcut to your Login form.

So, the user can live after pressing "Login" and the login form will be waiting for the next.

That's it.

No problem. Permissions will be tested when new user logs in. Let's say there was an open form, which has its "ViewSecurityKey" set, if the new user hasn't got permission to view this form, a panel will be covering it keeping the user from viewing anything that was going on.

I guess an authorized user will need to login and close the application. If there are any forms this user is not allowed to see, he probably won't be able to close the application. An authorized user will need to login first.

If the user that logs in back is authorized to do so, he can then just close it.

Think I described this scenario already.

Guess you will get deeper explanations from the guys.

Have a nice weekend.

Cheers.

Thanks Ivan!   One other thing you can do to manually lock a session is this:

Thanks for the info guys!



So, I'm understanding what is done better. There are two things I'd like to be able to do:



1. when a user logs off, loop through the forms and possibly save changes. Would I need to expose some of the BO functionality at the form level, like the EditingState and the Save method? Also, I'd probably need to do this in an event related to session locking. Would it be BeforeSessionLocks (or what ever it is called)? And where is a suggested good place (in code) to put this event handler?



2. Add the Exit button to the login form when a session gets locked, so the app can just be closed. I know the button is there, but it must be hidden when session locking occurs. How can I get to be shown when the session is locked?



Thanks again and have a good weekend...it's snowing here

There are a lot of different ways you can handle your forms being closed and saving changes.  It could depend on how you are launching your forms.  We have a menu system wihtin our medical application that launches all forms, reports, etc.  So since we have a single point of launching, it makes it easy to add handlers or fill a collection of some kind.

In any case, one option is to loop through the forms collection in your MDI form.

Well, you can create a custom login form to do this.  But depending on your needs, this might not be the best place to close down your app.  Generally it is best to require the end-user to at least log back in first...but maybe not.  It just depends on your circumstances.

Here too   We got about 8-10 inches yesterday!

OK, I see that I can setup a form to save any/all BOs on the form with the BaseForm.Save method. And likewise I can undo any changes with the BaseForm.Undo method. Cool, that is handled.



Interacting with the login form is not obvious though. I see that there is a AllowAppExit property, which is tied to the Exit button's Visible property. And clicking the exit button simply sets a DialogResult of cancel. When I call LockSession, how would I enable AllowAppExit and also if the user cancels the form via a click to Exit, does LockSession close the app?





Nice! I'm nursing some blisters from some new snow boots I used to go snow shoeing yesterday, but it was glorious!

No.  If you create a custom login form you can prevent the Exit button be being disable.  Or...create a button of your own to close down the application.

I sorry, I'm just not following this.



I have a custom login form. When the login form is shown initially, the Exit is shown and this returns a result of Cancel to the caller (within Login.ShowLoginAndAuthUser), which then returns false, with sets the e.ShowMainForm to false, which causes the app to exit (some where in SF code). I'm pretty sure this is right. The Login.ShowLoginAndAuthUser code must configure the login form to show the exit button using the AllowAppExit property.



When LockSession is called, it must do whatever it does to lock the session, set AllowAppExit to false, then open the login form. If I did show the exit button, LockSession would likely ignore the cancel result (I'm guessing).



The problem I'm having it that in both cases I don't interact with the login form directly at ALL. And the login form doesn't directly cause the application to exit in the first case. And when the session is locked, I'm assuming the form is opened in dialog mode (ShowDialog), so any code I put in place after locking the session won't be run until after the login form is gone. I must be missing something pretty obvious here, but, well, I'm missing it

You have already answered half of the problem yourself.  You know when you are in a locked session versus the initial login.  If you create a custom login form you can program any logic into that you would like....including calling some shared method within your application or your main MDI form to shutdown the forms and save changes.  Better yet, create a shared propety that has a direct object reference to the main form and expose a method to call.

Set this reference to the class when the main form loads or instantiates:

Next, create a method within the main form to shut down your children forms as shown in a previous post:

Now, in the custom login form, you can access the shared property to close the forms and shutdown the app.  Just add a button to your login form if you would like and enable it only for a locked session.  In the click call the shared property and public method:

hehe...like I said, I was pretty sure I was missing something pretty obvious!



OK, I get it now



One final question: is there anything special I should do when closing the app? Is using the "End" statement in vb enough? Do I need to do anything within the SF framework? Do I need to call Application.Exit()? *



* once again demonstrating my lack of .NET understanding