I’ve noticed some objects don’t seem to be completely affected by Component Security.
For example, rather than clutter a window with control buttons, I put a rectangle over an item of equipment on the screen. (The rectangle is not filled, and the border is set to the same colour as the screen background - its border is highlighted when the user moved the mouse over it, and is cleared when they move the mouse away.)
When the user clicks on the rectangle, a small window is opened containing controls for the equipment. However, even if Component Security is used to deny clearance to a role, if the ‘Disable component’ option is selected rather than ‘Hide and disable component’, someone logged in with that role can still click on the rectangle and run the script (and therefore control the equipment), despite the Mouseover Text being greyed out.
I have managed to restrict this function using the Action Qualifier, but this has to be done separately for each object. Is this expected behaviour?
Yes, this is expected. “disabling” a component only does something meaningful for a small handful of common components (buttons, text boxes, spinners, combo boxes, etc) This is why there is the “disable and hide” option.
It is important to know that mouse-based Action scripts will run regardless of component disabling on all components, but won’t run on invisible components. The actionPerformed event of a button will not be performed when the button is disabled.
The built-in component security is what it is. It isn’t meant to be a catch-all for security. That is why there are action qualifiers on the script builders, and various security-based methods in the scripting language.
It might be better to check the security when trying to open the window. If the user doesn’t have proper security, don’t open the window.
The Navigation Script Module goodie has a security check built into it’s open window functions. Checking security when trying to open a window has the added benefit of making a project easier to administer since there is only one place where you need to adjust security.
Good suggestion pat! If you’re worried about too many points of the same configuration, you could allowing the user to open the Window based on those rectangle clicks, but use “security” on the popup Window itself (a slight variation on what Pat said). This would allow security configuration in one place.
It’s worth noting that we have specified a better (fully backward compatible) model for the “security” feature. I added your implied idea of having an option to disable Jython events/actions on child components to the spec. The fact of the matter now is that “security” upgrades take a serious back seat since everything we can precan can be done relatively easily with a combination of the current feature and scripting.
My reply applies to the component “security” feature, not things like SSL support, gateway features, etc.