We have developed Automise templates that can be re-used. To re-use you just change four variables in an 'Set user variables' action list. Now recently a developer changed the behaviour of the script that was created from the template by editing a fileset and the end result was loss of files.
It would be good if somehow you could lock down individual actions or action lists so that they cannot be inadvertently changed. Maybe you can only edit them by entering a password. So for example if you right click on an Action List you get a Password Enabled/ checkbox and a Set Password... option.
+1 for this request. Although I think you need a more lenient version of the lock/protection of actions also.
Perhaps in addition to the password protection of actions you can also add a simple lock/unlock button on the action screen itself (to avoid inadvertent changing of variable names as is very easy to do in the ADO iterator screen). You could add a checkbox on the general tab to default the lock state (i.e. if you need it you set to auto lock just check the option, when you open the option it is locked be default until you click a link/button, once you close and re-open the action the default lock would be back on..
Adding password protection of individual actions in not likely to be added (far to complex, and people forget passwords all the time), however adding a simple locking option was pretty easy to add :
On the action’s General property page, there is a new “Locked” checkbox. If this is checked when you click OK, the next time you open the dialog you will see the Ok button disabled and label next to it stating how to unlock it. The action List view also shows a padlock icon if the action is locked.
Changing this from a checkbox to a some sort of multi-state button/toggle (not locked, locked, temp-unlocked) would allow you to temporarily unlock the action, make a change and have the lock reinstated immediately after the action is saved. Currently to make a change to a locked action and keep it locked you would have to open the action, unlock it, save the action, reopen the action, lock it and resave - just a thought that would streamline the process given if an action is locked to begin with, the chances are the user will want to re-lock it after the change is made..
Nice one, thanks. To finish it off you may want to add a right click/context menu item under the "other" option to allow changing that setting on the selected actions.
Also I checked out the password locking of project for editing - can that be easily extended to require a password to open the project? i.e. so a user cannot open/see the contents of the project without a password?
EDIT: Just thinking a bit more about it, I'm assuming any project secured with a password (for edit or for open) ran using ATCmd/commandline will have either no display of log output or minimal log output as you'd see all the SET actions and SQL commands etc. wipping by that could easily be captured...
Adding a right click menu will be added in a future update.
Extending the edit password to opening the project is not a simple thing. We will need to re-think how passwords will work.
BTW, I just noticed a bug in the AT4 with regards to edit passwords, in that it lets you save a project with an edit password in uncompressed mode… this should not be allowed (not secure, as it’s easy to remove the password), and will be changed for the next update.
As for the logging, there are no security options on the logging, the edit password is really just to stop users editing a project. As far as logging goes, we have tried to make sure that password fields are never logged as plain text, but that’s about it. If you have an action that is doing something you don’t want someone to see, then you can suppress the logging for the action from the action’s Runtime properties page.