Perspective Security on Component Action


This might be a blonde moment, but how can one implement Perspective permissions on the native action of a component, such as a toggle or numeric entry?

For a button, the permission is set on the event script.

For a toggle or numeric entry, no event script is required. The action is simply performed by the component through a bidirectional binding.

Is it necessary to make an event script on these components to effect security or am I missing something really obvious?


You could bind the props.enabled property against some sort of expression which defines the permissions required.

for example, a binding against


would prevent use of the toggle/field unless the user has been authenticated. The logic to determine what requirements must be met is up to you.

As for the button, the permissions are a little different because the component does nothing until you define the action. This isn’t to say you can’t enforce the same enabled bindings, but some users provide Script events for the onMouseClicked event, which fires whether the button is enabled or not.

Hi Cody,

I’m not a fan of disabling a control based on security, as the user may think the button is not available due to a different condition. The built in security notification is ideal.

I’m trying to make a plan using the onActionPerformed event, but may have found a bug. Steps below:

  1. Place component and configure 2 scripts for onActionPerformed
  2. Place some code in the first script and secure it with an authenticated permission
  3. Place some code in the second script and leave it at public
  4. If you perform the action while not authenticated, neither of the scripts execute. I would expect the first, secured, script to bomb out and then the second, public, script to execute

Tested on toggle and button. See attached view. Is this expected behaviour?

Deon (3.4 KB)

Hi Cody,

Is the behaviour described above w.r.t. to multiple components events expected or is it a bug?


It’s not expected and it’s not a bug. It’s a valid feature request and it wouldn’t break anything for anyone, so by all means go ahead and supply it through the ideas forum.

Some problems I see coming from it being implemented though are how those security restrictions are applied. Is a specified security restriction applied to ALL events, or does each event require its own security restriction (rhetorical - just thinking out loud)?

I’m bugging this right now - I’m not sure why I never got a notification for the response in question.

Ticket 15216, should you ever need to reference the multiple-action-for-single-event issue.

Thanks, I’ll keep an eye out for it

I am tring to give security to multi state button but its not work. i want to give permission to only operator change the state of button. how i will give the permission to button for access this?

any one have idea for this please guide.

Two Three ways:

You’re going to encounter the same options as Deon.

Preventing Script Execution By Security Level Of User:
Right-click the Multi-State Button and configure your script as normal.
Click the “Security Settings” button at the bottom of the Event Configuration popup.
Configure your security here.

  • Pros: prevents script execution.
  • Cons: Does NOT prevent the button click and/or value change for the button. Requires users to have Security Levels applied to them.

Preventing Script Execution By Role Of User:
Right-click the Multi-State Button and configure your script as normal.
Use the following logical check at the start of your script to determine if it should run:

# pseudo-code
inclusive_required_roles = ['operator']
authorized = False
for role in inclusive_required_roles:
    if role in self.session.props.auth.user.roles:
        authorized = True
if authorized:
    # script logic here
  • Pros: Uses existing configured roles for users. Prevents script execution.
  • Cons: Does NOT prevent the button click and/or value change for the button.

Disabling button:
You could also disable the button if a user is not authorized.

  • Pros: disables button, preventing value change. Might require Security level application to user, depending on preference.
  • Cons: Does NOT prevent onClick Events from firing (although DOES prevent actionPerformed Events from firing).
1 Like