I use this when working with self hosted clients.

And what do you use with Cloud clients? 😉 

 

And what do you use with Cloud clients?

I can appreciate why locking down a cloud server would be appropriate for a VERY large portion of IPS's clientele but by doing so they lock out a segment of their client base that would consider choosing to purchase a cloud server subscription if they were afforded the ability to manage and troubleshoot "some" aspects of their cloud server environment such as marketplace and custom apps.

Maybe IPS could open up a section of the ACP that would provide a little more access to "that" server instance, but it would require agreeing not to hold IPS accountable for any missteps. If something were to go amiss IPS would simply offer to restore the site to a prior state.

I'm thinking that the additional access to be able to manage "some" aspect of one's own server would only be granted to those individuals that have shown they have a team in place that knows what they are doing, as evidenced by the client's support tickets (or lack thereof) over a course of time for new and existing customers.  This might be done via the installation of a plugin. 

If a client manages their cloud server well the plugin remains installed, the moment they show they aren't up to the task of minimally self-managing their server a customer support person would simply uninstall the plugin. 

 

You don't have 'a' server when running in the cloud. Our cloud platform has hundreds of instances (which doesn't even necessarily equal the number of actual physical servers) and your site is running on all of them at once. Which one actually handles a user request is decided by a load balancer.

Probably there is a solution of how to allow the installation of SQL toolbox and protect from mass usage at the same time? When I log in into Marketplace, I use my account and see the files that are available for my account. This is Independent of the project or domain and is tight to my user.

When you create a "hidden" Marketplace category containing SQL toolbox/Adminer and give the permission only for contributors, then no "simple, normal" (you know 😉 ) user would be able to install it. The contributor can log in into Marketplace from customers' AdminCP and install it though.

Then after investigating, purging, or whatever, the contributor deletes the app from the customer's installation. You can also add a big fat warning message in AdminCP with scary words that there is an app that can damage everything and the user should uninstall it immediately. Just in case, the developer forgets to delete it. 😉 

This would protect the usage of the SQL toolbox or Adminer by the inexperienced user. But at the same time, allows a developer to debug.

 

You don't have 'a' server when running in the cloud. Our cloud platform has hundreds of instances (which doesn't even necessarily equal the number of actual physical servers) and your site is running on all of them at once. Which one actually handles a user request is decided by a load balancer.

Okay, cloud customers may not have their very own server, but they do have a centralized place to manage various settings and install and manage custom and third-party apps.

Some additional functionality to assist in troubleshooting and fixing minor issues with custom or third-party apps would go a long way towards helping convert a subset of self-hosted customers to become cloud customers or those individuals thinking about becoming a hosting customer. 

No final release yet? 😜

 

No final release yet? 😜
 

No with the weekend so close. Probably next Tuesday.

 

No with the weekend so close. Probably next Tuesday.

What is @Lindy & @Matt throwing a big barbecue and @Jordan Miller  is doing the grilling and I wasn't invited?

 

Shhh... Jordan doesn't know he's volunteered yet. 😇

 

What is @Lindy & @Matt throwing a big barbecue and @Jordan Miller  is doing the grilling and I wasn't invited?

 

 

 

Shhh... Jordan doesn't know he's volunteered yet. 😇

 

Haha. Me unveiling the Alerts System:

Here I was picturing it something like:

🥰 😇

 

Here I was picturing it something like:

🥰 😇

That would be @Mark H cooking 🤐 . 

 

As a developer, this is extremely upsetting, actually. And of course, as others mentioned in this thread, with CIC this is completely impossible. Does IPS intend to provide developers with another way to access the database for clients that are hosted in the cloud? Or are we expected to submit support tickets every time we need to do our own troubleshooting for 3rd party apps/plugins?

Honestly, I'm not entirely comfortable with the idea of third parties directly executing SQL queries on customer databases. If it all goes wrong, we have to dig out back-ups to fix it. This is not a slight on anyone's abilities, I've deleted an entire table of customer tickets with a mistyped query. It happens.

We are not going to create a system where third parties have access to the client databases. There is no audit trail for what actions were taken. When our team need to access a cloud site, we complete a reason form which is stored to form part of an audit trail so we know exactly what was accessed and why. We also have to access via a fixed IP address VPN so there is a data trail.

We take our cloud customer's security and data very seriously.

The SQL toolbox should have been removed a decade ago in all honesty. As we move forward with our cloud platform, more and more SQL tables will be stored centrally and not exposed to the client in any case, meaning admins won't have access to all the data the community uses which could case a lot of confusion.

(Edited later to add:)
In terms of what to do with debugging, I do sympathise. I generally made prodigious use of the simple \IPS\Log::log( json_encode( $data ), 'argh_send_help' ); logger. I have also in the past used \IPS\Db::i()->select(...); in combination with \IPS\Log::log() to inspect a single row of data.

How about leaving a watered down verion of the SQL Toolbox that only allows Select statements?

 

How about leaving a watered down verion of the SQL Toolbox that only allows Select statements?

It doesn't solve the data privacy issue and I'd rather put energy into APIs to make it easier to integrate with third party apps and code.