I have this idea I want to implement in our database, to include a tab in a tab control object that has restricted access, allowing only users in an administrative or developer permission set to go to the tab.

So far I have added an OnObjectModify script trigger to the tab control that passes in as a parameter Get (ActiveLayoutObjectName), presumably passing in the name of the current tab before the tab switching action executes.

Then in the script I'm able to identify the user permissions and selectively post a custom dialog informing restricted users they do not have access. I do this by naming the dev tab "dev_fields" and then using an

If GetLayoutObjectAttribute ( "dev_fields"; "isFrontTabPanel")

to determine if this restricted tab has been brought forward, followed by

If Get ( AccountPrivilegeSetName ) ≠ "[Full Access]"

to find out if the user has the right permissions to access this tab.

At this point, if the user is not of a permitted permission set, I would want to take the user back to the originating tab, which I was hoping I could do by passing in the Get (ActiveLayoutObjectName) and simply returning to this object with a Go To Object step. However, this step has not been working. the user just gets the popup saying they don't have permission, then when they click ok they are looking at the tab they are not supposed to have access to.

Is there something I'm missing in this execution? What do I have to do to restore the last tab state after receiving the restriction message?

In general, this is not a good idea: there is no security in layout measures. Perhaps you could use a fake tab and switch to another layout - one that is properly restricted in Accounts & Privileges.

Thanks for the advice. My original goal was to avoid making new layouts for these, I just want quick access to administrative functions without the added overhead of maintaining a series of mostly identical layouts. Is it generally not considered a good idea to handle permissions within scripted processes? Another idea I had was to simply do a permissions check in the scripts presented on this extra tab, but since it essentially boils down to the same process of scripted permissions handling I didnt see this as a problem to approach it with the tabbed idea. But if the consensus is that this is a poor practice I shall have to rethink my strategy.

Well, it really depends on what is on the restricted tab. If, for example, it contains fields for which the access has been properly restricted in A&P, then no harm (security-wise) will be done if the layout measure is circumvented - all the user will see is a bunch of fields with <no access> in them.

The remaining issue is then merely a cosmetic one. This could be handled by using buttons (only) to switch the tab panels. Then your script can decide whether to comply, based on the privilege set.

Again, the main point here is that "layout security" is not. You must assume that users CAN gain access to the restricted tab - and make sure security is not compromised if they do.

This makes a lot of sense. So in my case, rather than setting permissions to the switching of the tab, it would be sensible to just build the permissions into the restricted scripted functions. That way if somebody manages to get access to the tab somehow, they still can't execute these administrative scripts.

I think I know how to proceed from here. Thanks again.