Status CurrentGroups doesn't work from outside db

[raingirl]

I have one database that is set up for user access and has portals, etc. to all my other files. Let's call this file Portal. I originally had all related files set up for no layout access through password grouping. Upon realizing that in order to script reports to run from my user database Portal, I needed to allow users access to layouts in each of the files even if they don't see that they are accessing the layout.

So, for security I scripted the Status Current Groups to default to a security layout and lock the status area. I added this as a opener to each database and it works great if you open each related file individually.

Something like this was set as the opening script in each related file:

If Status (CurrentGroups)="Portal"

Go To Layout - Security Layout

Toggle Status Hide, Lock

End If

However, here's the glitch. From my main user file Portal, I have it default to the password that gives the user access to all other files. It will open each related file with the user password, but will not perform the openers.

I know that the group in each related file for the Portal is set up correctly.

Why does it not perform openers when defaulting to that password from an external file???

Any insight would be greatly appreciated!

[Chuck]

Scripts that are set to run when the file is "opened" only run when the file is opened from the desktop by double-clicking, from the menu by choosing "File->Open" or by using the "Open" script step. File can be opened in other ways. For instance, if a file has a relationship to another file, and that relationship needs to be accessed (for instance, by displaying a portal on the screen), then the file is opened without the running of any opener scripts. Similar behavior happens if the file needs to be accessed with a Perform Script [External] step.

The solution is to create an opener script that has a set of "Open" steps in it. The password used to open the first file will be used to open the succeeding files, and the scripts you've written will be run. Alternatively, you can perform the opener file manually by using Perform Script [External].

Chuck

[raingirl]

I tried that and it works. However, the user can go up to the hidden windows and then close that file. Then they go to a section of the user database that happens to reopen that file automatically, they can get access again. I need to completely dummy proof this security system. I imagine I am going to have to go back to restricting layout access through passwords.

Thanks for the info though. I won't explore this angle any further.

[Fitch]

If you hide all your layouts from the layout list, except for your Security Layout, it makes it pretty tough for the user to get anywhere. Doesn't really matter then if the status area is locked or not.

[raingirl]

I wish I could do that but these other related files are administrative databases at our school and so other people need to access these layouts. I have created a user file for all others to view info about students, teachers etc. so I am trying to limit their access without changing the structure of the existing files. I think I am going back to password layout restriction. This concept of data separation has opened so many doors to allow the general public at our school to have access to the information and reports that I allow. Unfortunately, it means that every time I add a report to this user file through scripting, I have to go into the passwords for that related database and give access to that particular layout. How annoying for development! These files are networked for many people and I can't wait to see how people will love me kicking them out for these types of things:(

[ernst]

Hi Marcelle,

If you follow Fitch's suggestion AND control access to the layouts via buttons and scripts you can restrict the access to certain layouts anyway you want

[-Queue-]

Why not set each file's On Close script to go to your security layout? Then, if they're opened incorrectly (which they need not be, if you use PatternCount( DatabaseNames, "filename" ) to test that each is open before transferring to a layout that requires filename to be open, and if one is not open, informing the user to log-off and then back on correctly), their default layout will be the security one. In each of your On Open scripts navigate to the correct layout, and your users will only have to see the security layout when they have closed files erroneously. You may need to open your solution single-user and close it once to force the correct action when on the server multi-user.

[Ugo DI LUCA]

Why not also add a "Close Window" button. Rather than closing the window, set this button to HIDE it.

[-Queue-]

If his users are anything like mine, they'll completely ignore an 800x600 red 'Close' button and click on the 'X' instead. So an On Close is safer, I think.

Here's another idea. Make a flag in the main file that's set when a valid close occurs and unset when the files are first open. Have all your On Closes check this flag and if it isn't set, chastise the user and either close all the files (easiest) or pass a unique database id to the main file and tell it to re-open the file after it closes.

BTW Welcome back, Ugo, my friend! I'm slowly catching up with you post number-wise! You should go on more vacations, then I'll max out sooner.

[Ugo DI LUCA]

That's a clever idea JT... as well as the vacation you gently offered.

These were really cool

May I choose the destination ?

[-Queue-]

How about California?

[Vaughan]

Just to go back to the beginning a bit...

If Status (CurrentGroups)="Portal"

Groups are associated with passwords, and one password may have more than one group associated with it (with group names paragraph delimited). Much better is to use...

PatternCount(Status (CurrentGroups), "Portal") > 0

Make sure the group names are unique and preferably a single word.

[-Queue-]

PatternCount( "