Challenge: in a system with three privilege sets, Employee, Manager and Administrator, you want to control access to various panels on this tab control like so:
- Employees have access to tabs 1,2,3
- Managers have access to tabs 1,2,3,4,5
- Administrators and Developers have unrestricted access
As usual in the FileMaker world, there are various approaches you could take, and today we’re going to look at three of them with the help of these demos:
- Approach #1: conditional tab panel access, v1
- Approach #2: conditional tab panel access, v2
- Approach #3: conditional tab panel access, v3
The basic idea here is to trap the mouse click with an OnTabSwitch trigger (which is a “pre-trigger”, i.e., executes before the click is processed). Since the user in the screen shot below is logged on with the Employee privilege set, they will only be able to access the first three tabs. Clicks on the remaining four tabs will be ignored.
What I like about this approach: it’s super easy to implement. What I don’t like about this approach: unauthorized users can see the “forbidden fruit” of inaccessable tabs.
All of today’s demos have an explanation screen to show what’s going on under the hood…
Here’s the script. We don’t need to use named tab objects; the position of the tab within the control is what matters.
Incidentally, note the use of the 500px invisibility trick to show “Logged in as…” to reflect the current privilege set. I used an overlaid text block here out of laziness. In retrospect I should have used a merge variable for the button text, in which case I would not have needed to resort to this trick.
As noted above, what I don’t like about approach #1 is that users can see tabs they aren’t allowed to access. This isn’t just disrespectful, it’s also a bad idea from a common-sense security standpoint. Demo #2 resolves this issue, but relies on redundant replication of tab controls and is not recommended.
This demo was created primarily as a proof of concept and as a stepping stone to the version 3 demo. It also happens to be the only one of today’s demos that doesn’t use the OnTabSwitch trigger. Here’s what’s going on behind the scenes.
The invisible tabs have tab object names the same as their visible names, e.g.,
To reiterate: I don’t recommend going this route. It might be okay if your tab content is a) relatively simple, and/or b) unlikely to change… and of course there are always exceptions, but as a general rule I would avoid this approach like the plague.
So what would be really nice would be to have the UI benefit of this approach without the overhead and maintenance headache of redundant replication… which brings us to…
Outwardly (i.e., in browse mode) the main screen of this demo is identical to demo #2.
Under the hood, as per demo #2, there is an invisible outer tab control representing the three privileges. Unlike demo #2, each of these panels contains a visible empty tab control with the appropriate number of tabs, whose sole purpose is to navigate to the correct tab of a single invisible tab control that would actually contain your meaningful content. The advantage being no need to redundantly replicate and maintain multiple identical copies of complex and potentially evolving tab panel content.
To summarize: the invisible inner tab control, shown above with a blue dashed outline, is not actually enclosed within any other tab panel, and therefore only one copy of it needs to be maintained.
In an upcoming posting we’ll explore some improvements FM 12 offers in the venerable realm of simulated tab controls, as well as another trick or two with the genuine article.