Access Panel User vs. Subscription User

[PleskSpider]

Greetings...

I'm using Plesk and things are going okay - I see and use it fairly easily, but still don't really have my head wrapped around exactly what's going on there.

As an example, I don't get the significant difference between the Access Panel User (Credentials that the customer will use to access their Control Panel) vs. the Subscription User (System user account used to manage files and folders of the websites created within the subscription).

I mean, I can read what I just typed and understand the words, but why couldn't (or shouldn't) these be the same user? Can you name them the same thing? (I haven't tried, as it seemed like it would create even more confusion.) Is there an obvious naming convention for either of them? (Such as one might name databases to somehow reflect the domain name with which they are associated.) Basically, any logic mapping or personal strategies on this would be appreciated.

 

[abdi]

A quick difference (one of the many):

- A customer can create subscription(s) but a subscription user can only manage or create (domains)

I know you are going to ask the difference between a subscription and domain, well the limits and independence makes the big difference ...
For example a subscription has it's own control panel (but a domain doesn't, actually domains belong to subscriptions)

I hope I haven't confused you the more ...

 

[PleskSpider]

Three Card Monte

Thanks AJ,

The good news is that I'm no more confused than I already was, but I still don't get the practical relationships.

Consider the Server Admin vs. the Reseller. I see the logic to that; as a server manager you need to be able to delegate (sell) reseller space and set the parameters of the Reseller's capacity to use and redistribute resources. So, I create a reseller account, subscribe it to a Reseller Service Plan, and give the access information to the reseller. When she logs on, from the Reseller interface she learns that while she cannot create additional reseller packages, she is free to create as many Customer accounts as needed for individual clients.

So far, so good, but what does the reseller do next? Create Service Plans? Then what? Get a customer and subscribe them to a Service Plan? That might make sense on the surface, but after creating a user account for the customer, you'd realize that the Customer account has nothing to do with the account you are required to create in the subscription dialog.

As I'm understanding it, you cannot assign a subscription to an existing customer, so you have to create another user in the Subscription. And of course, these are different users than ftp users or email users, or apparently panel users - all with (sometimes overlapping) settings scattered back to the Customer account you created in the beginning - a customer who probably doesn't really want to create accounts for anything! After all, "You're the network guy; just do what you think is best and give us the passwords."

But wait! I never created a Customer account for the Reseller!!! Does that even matter?

How do you organize this so you aren't logging into multiple unnecessary user accounts to get anything done? As another example, I'm a Reseller and I get a call from a client explaining they have a new consultant and need a temporary email address and ftp account. The email would be best as a forward and the FTP account can go to an isolated area. Sounds simple enough. However, the Control Panel opens in a new window and all of a sudden I'm acting as one of multiple users that become more confusing with every account I set up.

Actually, I've had Plesk loaded for some time now, but it was on a server that was barely used by anyone other than administrators on ssh. I'm only now trying to actually use the web hosting system. I guess I'm looking for some strategy to minimize the headaches. Often, you will find the super admin will be able to manage any possible function by logging into a single admin interface. The administrator for phpMyAdmin, for example, can do anything with just that one account - and the same goes for an Enom Reseller account and many other online management systems.

You would think a single group of Plesk users would be enough. You could assign Reseller status if appropriate, issue a mailbox to the account, select the domain name for the address, allow or disallow FTP access, select the domain name web space to be accessed, and select whether the user has access to the panel for that domain name. And if so, then select the areas of the Control Panel that can be accessed. And whether the Server Administrator, the Reseller, or the retail Customer made these changes they would all be working on the same single user account - an account that could have permissions equal to or subordinate to the owner of the Customer account the particular domain name was under.

Of course, Plesk can only do what it can do, so within the existing framework, I just wonder how others have organized the workflow.

Thanks again!

 

[Sergey L]

The difference between Customers and User is simple
* use Customer account when sites belong to someone else (different organisation),
* use User account for someone assisting with your own sites (same organisation).
Some people would try to use Users as Customers, but it results in multiple privacy concerns, as Users are supposed to be a part of your organisation.

As I'm understanding it, you cannot assign a subscription to an existing customer

Actually you can. A customer can have as many subscriptions as you give them - open a customer and "Add New Subscription".

However, the Control Panel opens in a new window and ...

This is something you can control. Tools & Settings > Open hosting operations in Server Administration Panel. No new window in this mode, all operations will be open embedded. Notice, that even if new window is opened, you are acting there as Admin (not a Customer) and keep your Admin privileges. So you would see this interface slightly different than a real Customer would.


If I understand your problem correctly, you are an admin in organisation, you would do most of operations in the system and you don't find Plesk convenient for that. But Plesk was primarily designed with shared hosting business in mind - thus Customers, Resellers, Service Plans, etc - all the things which are probably confusing for you. It is also very much shaped for self-management - i.e. if you setup a Reseller, they are supposed to take care for them, but that's not your case again. Same problem for people in so called "managed hosting" industry. We are aware of the problem and we are working on making Plesk equally convenient for both worlds. Till then, we are glad to help with consulting.

I think it will become much easier for you once you enable "Open hosting operations in Server Administration Panel" (above).
if you can tell who would be other visitors of the control panel and what needs they have - we can advise something for workflow and account management.

Regards

 

[PleskSpider]

Still Too many Users

SL, Thanks for taking time to respond to my post. I also appreciate your attention to improving the software's usability for managed hosting business models. The fact is, at some level we're all professionals here sharing (donating) our time and expertise to improve the product or help others overcome problems with the software. So it is with all due respect and in the spirit of improving your product that I submit that while there are several areas where Plesk's work flow is problematic, the most glaring problem is that it simply has too many users for any business model.

The most glaring example of user overkill is that of the Subscription.

To demonstrate, please consider the following logical work flow for hosting:

(1) First you create Service Plans to sell.

For simplicity, we'll say you created a Bronze Plan, Silver Plan, and a Gold Plan. Each plan has defined resources, such as the Gold Plan having unlimited disk space and bandwidth, and each plan is limited to 10 websites.

(2) Once you get a customer, you setup a Customer account (username/password).

(3) And since the Customer wants to sell others websites, you designate the Customer account as a Reseller by selecting that "role" for the account.

(3) Next you provision (or subscribe) one of each of your three Service Plans to that Customer account and the Reseller is ready to go.

(4) Now, when the Reseller gets a customer, she simply creates a Customer account (end user business role) and delegates (assigns) one of her 30 websites to her new customer.

(5) The Reseller's Customer (end user) now has the ability to create email, FTP, and control panel users for their one website.

Note that if the end user want to move from a Silver Plan to a Gold Plan, then the Reseller could change the subscription for that website. Or if the end user Customer needed another website, the Reseller could easily delegate another of her 30 websites to the end user. And since the "system user" is always the Customer, websites created (under any subscription) would be anchored to the Customer account under which it was created. You could also move websites between customers, so long as the receiving Customer account had at least one website available under a plan subscription.

Using the above example, the Reseller could indeed create just those three Service Plans and sell subscriptions to an unlimited number Resellers. And if the Reseller wanted to say, make an increase in the disk space for the Bronze Plan, she could make that one change to that one Service Plan and everyone with a subscription for that plan attached to their website would immediately see the increase. And if a Reseller used up one of their subscriptions, such as they had sold all ten Gold Plan websites to customers, the Plesk administrator could just sell them another subscription for another ten Gold Plan websites. So that particular Reseller would then have four subscriptions: one Bronze Plan subscription, one Silver Plan subscription, and two Gold Plan subscriptions.

Now, if I have this right, and you try this in Plesk today, you still end up creating Service Plans, but you next have to lock your customer into being a Customer or a Reseller. (You cannot change the role of your Customer later to a Reseller or vice versa.) So you create a Reseller account and give the Reseller her username/password. Then, when the Reseller logs in she has to create her own Service Plans, then a Customer account (username/password) for her new end user Customer, and then create a Subscription (username/password) for the Customer account.

Of course, by now the end user already has two username/password pairs to keep up with - one pair for their Customer account and another their Subscription - and if they want another website later, that will require yet another Subscription with another username/password. And if at some point the Customer wants to move one of their websites to a better Service Plan, that would require yet another Service Plan, since you can't move a website between Subscriptions and if you modify the Service Plan that the Customer's website subscription is tied to, you will be modifying the Service Plan for every Customer with a Subscription attached to that Service Plan.

This highlights just a few of the problems with Plesk's current implementation of Service Plans and Subscriptions. Currently, in order to anticipate handling an array of normal hosting situations, a Plesk Reseller would need to create a unique Service Plan and Subscription for each of their end user Customers' websites. That's a lot of unnecessary work. And it only creates more confusion when the application allows you to use the exact same username for both, a Customer and a Subscription.

Well, I have to get out of here now, but I hope this is useful.

 

[Sergey L]

Hi, Thanks a lot for detailed explanation of a problem. Probably I can help with some pain points:

Now, if I have this right, and you try this in Plesk today, you still end up creating Service Plans, but you next have to lock your customer into being a Customer or a Reseller. (You cannot change the role of your Customer later to a Reseller or vice versa.)

Indeed, that was troublesome up to Plesk 11.5 - the one had to make new Reseller or Customer account and move all Subscriptions there. But in Plesk 12.0 we added an ability to convert Customers to Resellers and back.

Of course, by now the end user already has two username/password pairs to keep up with - one pair for their Customer account and another their Subscription - and if they want another website later, that will require yet another Subscription with another username/password.

Well, Subscription can have multiple websites - so the one can stick to one Subscription as long as they are comfortable with 2 websites sharing resources and FTP access.

And if at some point the Customer wants to move one of their websites to a better Service Plan, that would require yet another Service Plan, since you can't move a website between Subscriptions and if you modify the Service Plan that the Customer's website subscription is tied to, you will be modifying the Service Plan for every Customer with a Subscription attached to that Service Plan.

This is supposed to be handled with
1) custom Subscription. Just go and edit amount of resources for a single Subscription (customize) - it doesn't require additional Service Plan and it will not change any other Subscription.
2) or apply an Addon Plan, which can add extra resources and keep Subscription on a current Service Plan.

Currently, in order to anticipate handling an array of normal hosting situations, a Plesk Reseller would need to create a unique Service Plan and Subscription for each of their end user Customers' websites. That's a lot of unnecessary work.

Definitely unnecessary - each Reseller would get a Default Plan automatically. And if they have unique setup for each Subscription - why to bother with Plans at all? Just make all Subscriptions custom (based on Default Plan and then shaped to any desirable resource amount).

And it only creates more confusion when the application allows you to use the exact same username for both, a Customer and a Subscription.

We do not limit that, but we expected a Customer named as a person (i.e. John Smith) and Subscription named as a primary domain (i.e. domain.com)

Now I am little bit confused with your point about "too many users for any business model" and the actual model you kindly described in steps. The model still includes all available Plesk entities - Customer, Reseller, User, Service Plan and Website/Domain. The only exclusion is Subscription which is not listed explicitly and you say Customer would manage their _one_ site - that made me think you imply that your Bronze/Silver/Gold is always for one site. But you also said that each plan is for _10_ sites. So if a plan is for 10 sites, than Subscription is also involved and now I am not getting which user is useless? What am I missing here?

Just not quite clear to me, what kind of easier workflow we could do for your needs. You seem to utilize all entity types in Plesk and the complication comes from you doing extra steps which Plesk doesn't really require from you (like making Service Plan for each unique setup or putting each site into separate Subscription). i.e. if there were no Subscriptions and resources assigned to each site separately - would it be easier? This can be simulated with limiting each subscription to a 1 domain only.

Regards