Your comments

Yes. Last year I installed an on-prem instance running 6.5 for testing and to look for how to disable the new "feature" myself so I don't have to get permission to use my own extensions. My instance was remotely disabled by CW after about 36 hours.

Before installing the 6.5 instance I read the license to make sure what I was doing was within the bounds of the terms of use, and it was, per my concurrent session license. Not once does the license stipulate how many on-prem instances I can install, only the number of concurrent sessions I can use. I never came close to the number of concurrent sessions across both instances (mostly because the second instance was NEVER used to login to any device and was used exclusively to review the code and test my extensions). There were zero external devices connected to it -- the only device it even had an Access client installed for was itself. I contacted CW when it was disabled to have it reinstated and they said that my use (installing a second instance for development purposes) was in violation of the license because I had the ability to use a "Hosted instance" for extension development and testing, which you can see from my concerns and screenshots in this thread, simply isn't true.

If anyone has a 6.5+ license installed and active I would love to be able to get a look at it in order to address this issue.

CW has changed their sites several times since this was requested. The link for the forum post is now only available through the wayback archive here. Since the CW docs domain blocked the wayback machine it was never able to capture the other pages. :(

As if punctuating my argument for the ability to edit our own extensions without having to deal with ConnectWise's "approval process," this is the current state of Extension Development as of March 2021 (and acknowledged for the last two months, but the sad reality much much longer):

Note specifically: "turn-around times for existing submissions may take 14 business days or longer." That's three "business" weeks OR LONGER. This is just so you can use your own code on your own on-premise installation. Insanity.

Can we please get an update from ConnectWise on this feature request?

I submitted one of my extensions almost FOUR MONTHS ago to the "approval process" and it has yet to be approved by ConnectWise. As far as I'm concerned this is breach of contract. 

As an example of just how ridiculous reliance on a third-party resource is (such as ConnectWise signing our extensions), ConnectWise even removed the page from their site that said they were removing this ability. 

this says it's roadmapped for 6.7. is it available in the latest release yet?

Do you have a potential ETA for future release? My ConnectWise Control renewal is due soon and getting this feature back is the deciding factor.

do you think silencing people on this platform will make our concerns go away? removing the post from jeremy.awecomm that specifically details why you should stop attacking users who make feature requests and bug reports only demonstrates that you are, in fact, doing that.

can we change the name as it appears in the uninstall page ye

1) sometimes the user won't have access to run either cmd or powershell so without logging out and then back in as another user, that's not possible.

2) the commands feature stores my command history, which would grant me immediate access to the previous command i might need to run again.

3) the commands feature also stores a record in the log of exactly what commands were run, and their output which i personally need for auditing purposes.

4) through the use of extensions i can also manipulate commands behavior to effect shortcodes without having to install additional software.

5) the commands feature is already elevated. if i have to open an elevated interactive prompt on a corporate device, for example, then the user can kill my SC task immediately after it's run and will have a persistent elevated shell they can then use to abuse the device or potentially abuse the clients network with. 

6) on Win10 an end user without admin rights could just click the eye to see the password i enter when typing in the admin credentials as i am typing it.

7) not every command i run needs to be visible to the client. while some are as simple as dir and del, others will be sc delete or 'secret sauce' that include business logic or advanced functions that could be catastrophic in the hands of an unskilled user that might try to fix it themselves next time. 

8) by your logic, there's no reason to include the commands feature in the SC backend interface either, since the tech could always just login to the device, open a cmd prompt or powershell prompt, then run the commands. It's not that the feature is necessary, but that it would make things easier for us. if the goal for the software is to improve the tech experience, this would do that. at least for me.

9) ditto a few of those but replace 'end user' with 'hacker/malware/keylogger/malicious user/person who stole the device' and you'll see a couple more reasons why the user doesn't always need to see the commands (or even know a tech is connected)