Assuming I understand your situation correctly, FileMaker is performing as it should. Here's why:
You open the "front end" file with a set of credentials that do not exist in "admin panel". You then attempt to open "admin panel" from "front end". FileMaker attempts to pass the credentials you used in "front end" to "admin panel". Since those credentials do not exist, it prompts for credentials. FileMaker then opens "admin panel".
As part of opening any file, FileMaker will check the Relationships Graph for any external joins. If they exist, and if they're called for by, say, a field being on a layout, a field that needs to be evaluated based on a field in the other file, or the like, then it will open the external file. In this case, the external file is already open.
Now, you tell it to close the file. FileMaker says, "Uh uh. Can't. I need that." So it merely hides the window instead.
Solution: You need credentials in the "front end" that permit your script to run. This can be accomplished using a "Re-Login" script prior to running the script. Or, alternatively, reconfigure your permissions to allow the appropriate actions to take place.
Mike, thank you for your prompt answer. You understood it perfectly.
That's what I figured as well. It must be normal behaviour, it is however a "catch 22" situation for me.
I'd hoped running the script with full access privileges would work around that. The standard user has import / export disabled and view only permissions to that table. And I want to keep it that way.
I guess I'll need to rearrange the flow a bit. First Re-Login then open the admin panel file.
Still need to think about a safe way back to the front end so it's not left in admin mode.
Well, it still remains weird.
Forget about opening another file from the current one.
This time the issue is: an already opened file with field references to a second file.
The Re-Login script step does not trickle down the credentials to the referenced file.
The account and privilege set for the referenced file remain the same as when the file was first opened.
I first log in with limited access, then even when I log into the main file as Full Access the referenced field permissions retain the old account.
The only way to do this is to kill the app and open it again with new credentials.
Is this normal? Or am I missing something?
Again, assuming I understand the situation correctly, yes, this is normal. Logging back into the parent file does not cause a relogin to the child file. You'd need to perform a relogin in the child file as well.
Hmm, that's a bit disappointing from FMI.. I'm sure they had their reasons for not cascading accounts to other files on re-login.
Running a Re-Login script in another file works, but this needs an own Custom Dialog for user / pass and passing them as parameters. Well that's not that big of a deal.
I'm not entirely sure how the security of this works. The parameters don't actually travel down the wire to the server? Only with PsOS, right?
After all if even if not using SSL the credentials are actually always sent encrypted.
Forgive me for being a bit paranoid here.
I can't tell you for certain about whether script parameters are passed encrypted. I would assume if the client / server connection is encrypted, script parameters would be as well. I would think they don't travel down the wire at all when executing a script within the same file; wouldn't be any need for them to. But that's an educated guess on my part.
Credentials aren't encrypted; they're hashed, even locally. They're never sent over the wire in plain text.