I’ve noticed that when I make a change from the Nodeworx panel to a particular Siteworx account (e.g. change their “Burstability” option to “no”), they can still go into their Siteworx account and change it back to “yes” (they get the drop-down, as opposed to a static yes/no.)
Tell me this is quickly fixable … 
My only option is to mark their account inactive until the next billing cycle, which is going to create a housekeeping nightmare.
JB
JayBean,
The only quick fix is to edit the template associated with that screen and “disable” the dropdown.
The file is located at:
/home/interworx/siteworx/smarty/templates/interworx/prefs.tpl
Change:
{if $option.type eq 'bool'}
<input type="radio"
name="{$option.key}"
value="true"
{if $option.value > 0}checked{/if}>##LG_YES##
<input type="radio"
name="{$option.key}"
value="false"
{if $option.value eq 0}checked{/if}>##LG_NO##
{/if}
to:
{if $option.type eq 'bool' && $option.key != 'LG_OPT_BURSTABLE'}
<input type="radio"
name="{$option.key}"
value="true"
{if $option.value > 0}checked{/if}>##LG_YES##
<input type="radio"
name="{$option.key}"
value="false"
{if $option.value eq 0}checked{/if}>##LG_NO##
{elseif $option.type eq 'bool'}
{if $option.value > 0}##LG_YES##{else}##LG_NO##{/if}
{/if}
That will remove the burstable options from the client’s menu. If you choose to do this be aware that on the next update it will revert back to the template we provide by default.
Hope this helps,
Chris
A nice short term fix…
Specifically to Burstability, it seems it would make sense that on the Nodeworx side we should be toggling on and off the ability for the Siteworx side to have a dropdown for the choice of yes or no. If we (Nodeworx) toggle the option “off,” then the customer (Siteworx) will have no choices – defaulting to “no.”
Of course, I’m saying this as a guy who has no concept of the dependencies that allow your panel to work otherwise so flawlessly … :o
Can this be a planned “upgrade?” I think it’s good to give the client a choice of paying for more bandwidth if we give them the option. At the same time, if someone abuses that, or doesn’t pay for the (slight) overage, it’s nice to have the ability to toggle the option off without suspending their account entirely.
Does this make sense? I tend to babble …
JB
The idea behind letting the client choose whether the account is “burstable” or not was to give them the option of being charged for bandwidth transfer overage, or not, for a given month.
I see your point of view as well though, sometimes you just want to disable a site until the end of the month, and this option would be perfect for that goal, if the client couldn’t switch it around.
Both ways have value, so we’ll see about giving you the option if having it work one way or the other, depending on how you want it to work.
Hello,
I copy/paste here my other thread ( -->HERE <–) about the burstable option
About the bandwidth limit and the burstable option (not sure it is related to the 1.9) :
when a user exceeds the limit of bandwidth there is no mail alarm sent to the administrator of the box. It’s a shame, as I can’t check all account every days and I can’t force the burstable option to OFF (in fact I could by tweaking the theme)
I have a user who had exceeds his bandwidth limit. His account had been created on february 12th. I told him, I’ll wait until his birthday date, to send him an invoice for the exceedent bandwidth used. But on the March 1st, his bandwidth data has been reseted. So I can’t know how much he exceeded his bandwidth during his one month subscription (ended on march 11th), also I couldnt invoice this bandwidth’s going beyond to him.
It could be great to have :
I also create this post in the “feature request”
Regards
Pascal