I'm not entirely sure what your workflow is (independent of the coding involved). Does this capture it?
1) You have user A logged into the database.
2) User A has limited privileges (no record creation allowed).
3) User A needs to create a record, so user contacts user B for authorization to create a record.
4) User B comes along and clicks a button / activates a script.
5) User B enters credentials to allow record entry.
6) User A enters new record.
7) User B indicates that new record entry is to be terminated.
8) User A logs back in, terminating new record entry.
Is that about right?
In a nutshell yes, it is in a medical environment.
1. A nurse/technician is logged in and will navigate through the solution to the point where a clinical member of staff will need to check the details and authorise it. (The Confirm button is hidden by a 'Requires Authorisation' button at this point)
2. Nurse hands iPad to Clinician who punches in their username and password.
3. A dialog box pops up and requests the nurse password again to re-login, and the Confirm button is now visible to go back to main screen.
Since posting I have switched from using a Dialog box to gather the Clinicians username and password to a popover window which suits the iPad better.
Having thought about this some more, I am toying with the idea of having a generic login to the solution and having a 'Login' layout as the landing page. That way I can collect the username and password and run the re-login script step and store the username and password in a Global variable. Not sure on the security of this approach though.
Would this be a typical scenario? Say, for example, a nurse asks a doctor to approve something, hands them an iPad with FM Go on it and they (the nurse) are logged in with their user account. The doctor needs to log in with their credentials to approve, but then be able to hand the device back without leaving it logged in under their account?
If so, you may be able to use a second file with a view to the same record that opens, then:
• performs a re-login script step to capture the new authentication in the second file,
• do what you need to do (digital signature?)
• re-login in the second file to a lower set of credentials (to log the doctor out) and close that window
• return to first window/file where the nurse is still logged in.
Would that work?
I'm glad you mentioned security.
Mike D's scenario is just one where this kind of workflow opens up all kinds of security problems. My suggestion would be to abandon the whole relogin process altogether, because there are too many ways it can be bypassed. (Just hit "cancel" on the relogin screen, and guess what? The nurse is still logged in with the clinician's privileges.)
Mike D's workflow should work fine. You could even just log into the second file using the clinician's credentials. The clinician can just create the record at that point via the external file (perhaps using a script that runs with full privileges), then log out. No relogin of the nurse at all, and no saving of credentials (which gives me the heebie jeebies).
Thanks to you both for the suggestions.
I had managed to avoid the nurse being left logged in as the clinician by using a loop and a custom dialog box to take the credentials, but again it meant I was caching credentials, even if it was only for a few script steps.
My other concern with using either custom dialog box or the dedicated login box was that it felt out of place in the middle of the Filemaker Go app, and I have no way of controlling which keyboard shows up (I wanted to use passwords for this of 6 digit PIN numbers for ease of entry).
I agree that using a second file with access to the record and a layout showing the record with a confirm or not choice looks like the neatest and most secure option, so I will look at this further.