After I use the SecurityDialog at run-time how do i refresh the current user's permissions? In case they were affected.

Either log out and log back in or lock the screen (session locking) and re-enter the user and password.

This gets me thinking. What if an administrator is changing the permission on a role(s)? Wouldn't the application need to be locked, so all users have to relogin, to get the new permissions? Does strataframe have a way to lock the application, and notify any logged on users that they must log out (or log them out)?

It works just like Windows...you will have to log out and log back in.  This is an industry standard and this is why we took this approach.

OK, I understand that if a user uses the security dialog to change some permissions, they will need to log out/in to see the changes (makes sense for dev/testing scenarios). I'm asking more about a production scenario, were the permissions of role are changed. In that case, any logged in users would also need to log out/in. E.g. If when userA, an admin goes in and messes with the permissions of some role(s), and say userB, userC and userD are all logged in when this is done, any one of which might be using the roles changed by userA.



Does SF have any way of forcing those (all) logged in user to get off? Or to notify them that need to log off?



I'm not sure I'd expect that it would, but SF is pretty massive, so before I go off and try to solve this, I'd just like to know if SF already has solved it! (though I'm pretty sure I'd just schedule some down time and kick SF out of the db, do the changes, let em back on)



Also, is there any way to schedule the changes? I.e. userA enters the changes during the day on monday, but can note that they wouldn't go into effect until that night at midnight. Again, not sure I'd expect SF to do this, just wondering if it does.

No, there isn't any mechanism for SF to notify users that they need to log off.  There are a couple of reasons for this. 

1) First off, the reason that people have to log off and back on is because the security system builds a local list of the person's aggregate permissions when they login.  This way, the client does not have to run a SQL query every time SF asks the user if a certain permission is granted; they're cached on the local machine.

2) The notification mechanism would require that the user query the server to see if they need to log off, which would be a performance impact; or the security system would require an application server to send a message to the clients, which just isn't feasible.