Forum Discussion

Lewis_Beard's avatar
2 months ago

"Enable Test Script" UIv4 security experiences?

On our portal, I recently noticed the "Enable Test Script" option under the UIv4 security section, because UIv4 recommended I toggle it from Enabled to Disabled. I avoid UIv4 like the plague but as L...
  • Anonymous's avatar
    Anonymous
    2 months ago

    Modules toolbox has come a long way, but that's not saying much. It's got a long way to go.

    My opinion: Actions that aren't associated with editing the module shouldn't be exclusively in the editor. LM has made the decision to have a "viewer" and an "editor". If they persist in this, they should put things like "show associated devices", "test appliesto", "test active discovery", and "test collection" in the viewer as well as the editor. They do not change the DS, so they don't need to be locked into the editor. That would solve the problem of modifying the script then using the test script button to run some malicious or untested code. 

    My 2nd opinion: they should do away with the module viewer. The editor should be the only way to view the details of a DS. It's where most of the pencils in the new UI take you anyway. Once there, I don't see any harm in having two levels of permissions: 1) read only and 2) read write. The read only users would be able to do anything except change the module. So they would be able to run any of the tests, see associated devices, etc. But the script fields would be locked down. They'd be able to read them, but not modify them. RW would obviously have everything.

    I guess my point is that RO users should be able to test appliesto, discovery, and collection (same as poll now, really) because that doesn't involve a modification, even temporary, of the DS. Creating a new permission level just because you took the lazy route and only checked permissions when someone hits the save button is, well, lazy.