Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 5082 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

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?

Posted

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.

Posted

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.

Posted

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.

Posted

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.

This topic is 5082 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.