Our features site is undergoing a refresh! Be sure to explore the revamped site and discover our latest product roadmap launching here on Monday, March 18th.

Allow resetting of bandwidth count on single accounts

Peter Bishop shared this idea 10 years ago
Needs Feedback

From time to time, it is possible that us lovely administrators need to reset somebody's bandwidth count after they have either exceeded it or paid to have it reset for example...


I propose that a new feature be added under "Account Functions" in WHM where we may reset a users bandwidth count back to 0.

Best Answer
photo

This seems like it would introduce significant confusion, awkward account "states", and loss of historical information.


Right now bandwidth overage is simply a binary state. Is X value >= Y value. Yes? Over.


Introducing your request requires some fairly awkward results, in my opinion. Either we...


[1] Introduce a gray area state where Usage >= Limit does not mean overage if X state is "bandwidth has been reset". This in effect duplicates a temporary "unlimited bandwidth" state until the next month


[2] If we try and get around the "temporary unlimited bandwidth" state of #1 by truly resetting their usage and enforcing a fresh limit again. Now we run into a state where we have to track "time of reset" with actual usage to have this "sub usage limit" or we otherwise simply destroy the month's usage to "reset" it (causing loss of historical data)


There are a bunch of other awkward/confusing setups I can think of, but I can't think of anything that is clear and concise and makes sense to handle this both in a way that provides the desired end result to the customer without producing unintentional/undesired/complicated results in the cPanel & WHM backend.


If you could recommend specific implementations that address all of these concerns, I'm certainly open to hearing them.


Right now the recommended method of handling this would be to temporarily give the customer a boost of X bandwidth and then set it back down to normal at the end of the month. This tackles the problem pretty elegantly by not introducing confusing "If this but not this but this" conditionals (it still is solely "If X usage >= Y limit"). It also gives the end-user the desired result (site not disabled) while still retaining all of their historical usage. That would be my recommendation and most elegant way I can see of handling this request, which request no product changes.

Replies (3)

photo
1

This seems like it would introduce significant confusion, awkward account "states", and loss of historical information.


Right now bandwidth overage is simply a binary state. Is X value >= Y value. Yes? Over.


Introducing your request requires some fairly awkward results, in my opinion. Either we...


[1] Introduce a gray area state where Usage >= Limit does not mean overage if X state is "bandwidth has been reset". This in effect duplicates a temporary "unlimited bandwidth" state until the next month


[2] If we try and get around the "temporary unlimited bandwidth" state of #1 by truly resetting their usage and enforcing a fresh limit again. Now we run into a state where we have to track "time of reset" with actual usage to have this "sub usage limit" or we otherwise simply destroy the month's usage to "reset" it (causing loss of historical data)


There are a bunch of other awkward/confusing setups I can think of, but I can't think of anything that is clear and concise and makes sense to handle this both in a way that provides the desired end result to the customer without producing unintentional/undesired/complicated results in the cPanel & WHM backend.


If you could recommend specific implementations that address all of these concerns, I'm certainly open to hearing them.


Right now the recommended method of handling this would be to temporarily give the customer a boost of X bandwidth and then set it back down to normal at the end of the month. This tackles the problem pretty elegantly by not introducing confusing "If this but not this but this" conditionals (it still is solely "If X usage >= Y limit"). It also gives the end-user the desired result (site not disabled) while still retaining all of their historical usage. That would be my recommendation and most elegant way I can see of handling this request, which request no product changes.

photo
1

In regards to your concluding comment where you mention temporarily increasing bandwidth allocation, could it not be possible to implement this into WHM so that when an admin enables a "bandwidth reset", the bandwidth limit is increased to say, double however, when the reset kicks in each month, it checks the user data to ensure the bandwidth limits set are the correct ones and if somebody is still temporarily increased, it reverts the account back to it's default bandwidth limit respectively?

photo
2

That's an example of how this adds some potentially crazy complexity to the usage of the feature.


Now when a user views their bandwidth consumption in cPanel's UI, how do we handle indicating this? Potentially we add some unique coloring or, worse, having to bloat it with a pop-up/tooltip explaining their cap isn't really their cap, but a temporary boost.


Same deal with WHM's UI. All places where bandwidth consumption is shown now needs to be visually adapted to somehow convey it's not really the limit, which means there may be confusion on the end of the viewer.


Similar problems dealing with APIs that return limits and having to somehow convey it's a temporary limit in a meaningful way as well as the true limit.


To then "return" bandwidth to the old level, we'd then have to introduce a new tracking element of what the old bandwidth was. This is now something that has to be further checked against and considerations make with respect to someone editing bandwidth while it's in the temporary state, modifying packages while it's in this temporary state, etc.


All of the above, in my opinion, adds a slew of potential confusion points in the product and how we maintain the state of an account.


Again, this is not a rejection that a feature that results in the end behavior you're looking for being an impossibility. But, I do have major concerns with the ideas proposed so far in the sheer complexity and potential confusion they introduce when otherwise the state of an account's bandwidth is nothing more complex than "If USAGE > LIMIT, they are over their consumption", with only one "limit" and one "usage" involved.


I'd like to hear of potential ideas that try to maintain this simplicity. I'm not sure if it meets your guidelines, but an individual toggleable "do not suspend this account if over bandwidth" controlled on a per-account limit would maintain most of the simplicity. However, I could still see the argument in this being forgotten by hosts and thus accidentally leaving users with effectively unlimited bandwidth. It's a tough issue to tackle gracefully, I feel, so I'd like to hear further ideas/comments from the community that take into account these concerns.

Leave a Comment
 
Attach a file