Keeping track of addon domains usage
I've been maintaining cpanel servers for a long time now - and one thing that always troubles me is the fact that a customer can easily downgrade their account to a plan that has less addon domains, but retain the same number of addon domains they had previously.
I appreciate that if enabled, an admin notification Email will be sent to warn that an upgrade / downgrade has taken place - which then allows you to investigate manually to make sure everything is in order.
Unfortunately in practice, these don't always get followed up.
There is seemingly no simple way to see at a glance, how many addons each account has in relation to the plan limit. It would be VERY useful to have this info on hand, not only to see who has more addons than they should - but also to see at a glance what the general usage is.
Would be great to see some optional columns added to the "List Accounts" page with the ability to choose what is displayed via "tweak settings".
In the absence of this kind of functionality - is there a quick and easy way to get this info from a server? Perhaps via a small script or an API command or something?
Realistically, I would like a report of what accounts have more addon domains than the limit allowed by the plan they are using - and perhaps a report of all accounts with the plan's addon limit and addon domain count.
I wonder if anyone has already found a solution to this - or if the info already exists somewhere and I missed it.
-
Hey there! I don't have one command that would get you this information, but there are two API calls that would be useful for this situation. The first is this guy: Return cPanel accounts - this will show the maxaddon value for a domain The second is this: Return all domains' hosting configuration - that will show a list of the addon domains under a particular account and their settings. If you'd like to see something added to the interface, such as in List Accounts, we'd need a feature request. If you'd like to get one created using the link in my signature, I can get that approved and then bring it up with the team during out meeting next week. 0 -
I Appreciate your reply CPRex but you really should give up with the old "Submit a Feature request" line. We all know that is a complete waste of time. The fact is that the packages system in cpanel is flawed. Especially in terms of automation. It is impossible to effectively change plan limits for customers and it is impossible to prevent them from using more resources than they have been allocated. Here's a simple scenario.... Customer starts on Package B which has 10GB space and 10 Addon Domains. Let's assume he's using 8 of his 10 addon domains. There are two options available to the web host for allowing this customer to upgrade / downgrade... 1. Switch to a different package. 2. Use the API to change their limits "on the fly". Scenario 1. Customer downgrades to Package A which has 5GB Space and 5 Addon Domains. Problem: Customer still has 8 addon domains in use. As far as I know, there is only one thing that happens here to let the web host know this has occurred. An Email from WHM to the admin Email address simply saying that the package was downgraded. If you have more than a few servers, managing this is impossible. There is nothing in place to stop the downgrade from being processed. What should happen is the API command should Fail - with a message that the package cannot be downgraded because there are more addons in use than allowed by the new package. This isn't a "would like to have" type of requirement. This is a basic fundamental functionality that should have been in your product from day one. And to add insult to this huge oversight, you don't allow the web host any possible way of identifying the accounts that are using too many addon domains / parked domains / subdomains. For what is considered a "mature product" this is really an embarrassing and frankly stupid lack of basic functionality don't you agree? So - on to Scenario 2 - API. Customer wants to increase his disk space... Using your favourite web host billing software, you can set up "configurable options" that allow you to change the customers plan limits. In this scenario, the client wants to increase their disk space, so they order 5GB more space. This increases the disk quota for the customer - but this will never be retained if the package is modified. As soon as a change is made to the package, the plan limits are reset and the client loses their disk space. Again, there is no way to keep track of this - or to re-apply the limits after the package has been changed. Terrible. Of course, what you need is a separate mechanism. Strict Package limits on one hand - and custom "on the fly" limits as a separate system altogether. You can't have a fusion of the two. In practice it simply doesn't work. This is the bread and butter of a system like this. How could you get it so wrong? I would have thought that after so many years, cpanel would have refined the way these things work. It is clear to anyone that uses cpanel servers on a regular basis, that the package / limits system in place is not up to an acceptable standard. When you think that this is a fundamental aspect of the provisioning process, you start to wonder how far removed the cpanel dev team is from their client base and how poor their understanding is of the basic requirements a web host expects when dealing with the setting up and maintaining of their customers hosting accounts. And of course we are paying more and more and more for the privilege of using the mighty cpanel - worlds most popular control panel - yet you can't even get the basics right. Such a shame. 0 -
I Appreciate your reply CPRex but you really should give up with the old "Submit a Feature request" line. We all know that is a complete waste of time.
Strongly disagree. I also manage the Feature Requests area and we have completely revamped how those are being handled. Just because a feature gets submitted doesn't guarantee it's going to be implemented, but I review each one, communicate with the appropriate development team about the issue, and then they will reply to the feature within 30 days. It's been a solid system since I implemented that. What would be your ideal solution to this issue? I'm happy to file a case directly with the developers and just skip the feature process, but what are you wanting to see happen? Would you like the account downgrade to fail? Would you like the account downgrade to succeed but with a notification to the server admin? What specifically would make this easier to manage for you? If you can get me something more specific than "change the entire package and provisioning system" I can get a case created.0 -
What I'm looking for is a way to easily identify the customers who are using more addons than their plan limit allows. That's my original post. You'd think this would be simple - but there is literally no way of easily finding this info. Unfortunately those two API commands are not really any use without a lot of work to put the data from both commands together. It's up to you whether you "file a case" or not, but really my additional comments are there to vent my frustration at your product still failing to work adequately on even the most basic level. The cPanel devs should already be fully aware of these failings. There's no point asking why your developers are seemingly unaware that the functionality of these aspects of your product is extremely poor and why they haven't taken the time to make what is clearly a problematic set of features better. I'd be happy to submit a feature request for something new that I might want including in your product (even knowing it would sit there for 5 years and nothing would happen), but I'm not going to waste my time submitting a feature request for something that is already in place but has been very poorly implemented. That's more of a complaint than a feature request. My feature request might then be entitled "cPanel devs - work harder and do better". I'd love to open a feature request entitled "cPanel - get rid of that stupid Jupiter theme and bring back paper Lantern" but I know that would fall on deaf ears too, despite your entire community of customers absolutely hating it. 0
Please sign in to leave a comment.
Comments
4 comments