Are you really committed to the portal idea? I've found that method to be difficult to implement. The best version of it that I've used was one that was based on user access privileges. The same portal was shown to everyone. By dint of their user access privileges a different set of records was visible to each user/group. It worked very well but it still had limitations.
At present I prefer a method I've called "the sorting hat" and I use with all the layouts which are designed for different groups. For each layout within the database that warrants a button in the navigation scheme I create a blank layout. I then create an onLayoutEnter script for that layout which determines who the user is and it switches to the correct layout. With this method, all my navigation scripts are the same. They all go to layout "home" or "contacts" etc As soon as the user enters the layout the onlayoutenter script is triggered. The script on those layouts can be rather long and complicated ( which group? which user? what day of week?) but the code is one place and so its easy to maintain.
I'm not fully committed to the portal navigation idea, but i find it intriguing - one portal on each layout changes depending on the records in the layout table. When I click on a portal row, it grabs the value of the field in that row (the layout name) and goes to that layout by name by calculation.
I only want the user to see the layouts that concern them: the teachers don't need the principal dashboard, and the central office doesn't need to see the teacher stuff. Malcom, will your method work with this idea?
Again, I'm not fully committed. I may just have the home page with the various positions listed there and the user clicks on the one pertaining to him/her. If they don't need to get into that section, then it lets them know that and asks them to pick the correct. Heck, I could use the script to direct them, upon log in, to their correct screen: Teacher screen, Office screen, Principal Screen, and Central Office Screen. I may just do that.
I was playing with this portal-rows-based-on-user-position idea. It seemed good at the time
I use portal nav almost exclusively....love it.
Let me give u one approach to play with based on what u r already doing and see if u like.
So - u r using $$ global vars to set ur keys based on the current user.
I have a few other tactics to handle this but I'll skip for now.
Assuming u don't have an overwhelming number of destination layouts,
Use portal filtering. Click on ur portal (enter portal setup). Select filtering.
Enter conditionals ala:
$$location=field in portal containing this
$$nextvar=field in portal
Use "or" and use "and" in cases where u have more than one condition needing to be met.
U can use parenthesis to group things according to the type of view filter I want.
Long night here so if this doesn't make sense, I'll throw u a demo solution hen I wake up.
You may want to check out the demo file I posted for a global navigation scheme called "Crumb." It was my reaction to several portal-based navigation schemes I've seen floating around and their tendency to needlessly duplicate or bypass functionality provided by FileMaker's native security and navigation functionality. I've found portal-based schemes useful for situations where users without [Full Access] privileges or the privilege to manage extended privileges need to be able to configure navigation settings, but I've found that that's a minority of real applications.
Crumb works by parsing all the layout names in the file on startup, and using the result of that to display whatever navigation widget you wind up using. (I used merge variables, but it could be adapted to a virtual list in a portal.) If the security settings for a user say that they don't have access to a layout, then the start-up script (which does not run with Full Access) can't see the layout either, and that layout isn't exposed in the navigation widget. This way, you don't have to maintain a separate table of what layouts there are in the system and who has access to them, which would duplicate settings readily available in the "Manage Security" and "Manage Layouts" dialogs.
I'll certainly check this out. I do like the idea of a vertical menu on the side of the layout to give people choices. I think I'm going to try to set it up based on the school. Each school's layouts will come up on the menu. And then do a filter portal based on the teacher's position.
I will look at your idea though. At first glance I had no idea what your solution does. But that's not surprising. I'm way behind some of you in terms of databases.
I'll give your stuff a strong study.