Ideas about Powershell/Tools section

Hello,

David encouraged me to post my ideas and suggestions. So actually this is not a real feature request it is more a collection about ideas regarding Tools/Scripting in general.
Scripting and Powershell are getting more and more important so i think RDM could be a central tool for it. And maybe some of my ideas are already solvable or already implemented, but i couldn't find them in a straightforward way.

Macros/Script/Tools Section in Dashboard in general
It is not visible which Entries act local or remote and which work for the current Entry at all. So for example "Computer Management" does not help at a Website connection entry of a switch or "Netstat" is always only about my local machine. The function of the "visibility" entry in Description of a tool is complete unclear to me but points in a good direction. So it would be great to have a general Macros/Script/Tools container where i can set the visibility of the entries on different rules. So for example "Computer Management" is only visible on Dashboard of RDP Entries, or Tool "x" is only available on entries in a certain Folder or on entries with a certain Tag. The mentioned container could also act as global Script Repository for a whole database. I know some things could be maybe already handled with Templates as a workaround but for me it is not very straightforward.

Credentials and Powershell
While playing around with Powershell Tools entries i was not able to get a value with the $TOOL_PASSWORD$ variable. I think for sure there is somewhere a security entry to allow it, but i was not able to find. Anyway it would be not a good idea to have a plain password as a parameter. It would be nice for scripting to have [PSCredential] Variables ready to use as parameter. They are already encrypted and safe and cannot reversed to plain text (as far as i know). So what about having variables like $PSCRED$, $PSTOOLCRED$, $PSVPNCRED$ ready for parameters in Powershell Entries which can than directly be used as parameter for various commands with credentials needs.

Powershell and Parameters
With the existence of a script repository the parameters could be read from the script. So it would be nice to handle them in various ways.
So for example think of a simple "AddUser" or "DisableUser" Script which can work for several Domains (Customers).
To use "AddUser" in the most simple way you need Name, Domain, OU, Password, UPNSuffix
To use this script out of the repository you can make it f.e. available as a Tool entry of domain controllers.
The parameter Domain could be inherited from the entry
The parameter OU could be set as property
The parameter UPNSuffix could have another script from the repository as a source which fetches the available Suffixes for that specific domain
For the other parameters a dynamic dialogbox opens which contains a text field for Name, a password field for Password and a drop down box to choose UPNSuffix.
For a DisableUser Script the Parameter User could be first fetched from another script from AD and then presented as a DropDown Box.
With this possibilities Users using RDM would not need the credentials to log on to a machine. So the security could completely stay within RDM and Helpdesk Users only have the rights they really need

Powershell Output
Currently if you use a Powershell script you can leave the window open to see any output. In this case it the user is still able to use then powershell commands. If you choose to close the shell after running, you cannot see any outcome of the script. It would be nice to have the possibility for a result view. Either in a pane where the output of powershell is shown but the session is already closed or a msg box with the output.

Powershell and Cloud
It would be nice to have ready entries for Cloud Connectors. Building a powershell connection to the graph API to AAD, ExchangeOnline, Intune,... is a common but not so easy task. Often you don't want that the user has all passwords and so on to do it by himself. Having these kind of entries with the security context of RDM for interactive Shell or for Scripting would be a great help.

So i hope you like some of my ideas even if some would mean a lot of work and lot of changes.
If something of the ideas is unclear please let me know or anyway looking forward for an "ideas" discussion.

Best regards,
Heinrich