CHANGE LIMIT/QUOTA > can't save

davidd1

Verified User
Joined
Jan 31, 2013
Messages
104
Hi
User level > E-Mail Accounts > CHANGE LIMIT/QUOTA > change to "unlimited" > button "save" can't click!

E mail Accounts   DirectAdmin 1 55 0.png
 
It seems to be tied to the Evolution skin expecting a value to be present in the field. Pressing the unlimited button several times in a row will sometimes, instead of toggling it between a set amount and unlimited, make it display "1. Required Field" and retain the Unlimited setting. If you try to enter a 0 as per the old way, it will display "1. Should be larger than zero" instead.

On a side note... Would it be possible to get both of those unlimited buttons outright removed as well, if the admin/reseller desires? Since e-mail quotas count towards overall quotas, we don't allow our users to set unlimited quotas (by means of a custom email_change_pass_pre.sh and email_create_pre.sh).

How this presently works with the Evo skin is that it will throw an error when a user tries to submit an unlimited quota:
Script output: /usr/local/directadmin/scripts/custom/email_create_pre.sh
Cannot set unlimited E-Mail quotas

And then I presume an attempt at unlimited using "Change Limits", once it works anyway, would display the following:

Script output: /usr/local/directadmin/scripts/custom/email_change_pass_pre.sh
Cannot set unlimited E-Mail quotas

I suppose the alternate of greying them both out is fine but if neither is selectable then hiding them seems better.
 
It works, though now it seems to submit "unlimited" instead of 0 when unlimited is checked. It's something that won't matter to 99.9% of users but it will break any scripts that check against a 0 for preventing unlimited quotas.

Code:
/usr/local/directadmin/scripts/custom/email_change_pass_pre.sh: line 12: [: unlimited: integer expression expected
 
Are you 100% sure that line 12 is checking $quota? Could it be a check on $limit?
If user_can_set_email_limit=0 then it the $limit wouldn't be passed at all.

But checking the code, if quota is not a number, it shouldn't be able to get past that point.
If "quota=unlimited" is set, it should error out before anything with "That is not a valid quota".

Anyway, please confirm exactly what check is done on your line 12, and we can continue to dig.

Side-note, I've added:
user_can_set_email_limit=0|1
to the script, as that would be required info to know if the $limit variable should even be checked, as if user_can_set_email_limit=0, then $limit won't be present at all.

John
 
email_change_pass_pre.sh
Code:
#!/bin/bash
while IFS= read -r line; do declare "$line"; done < /usr/local/directadmin/data/users/$username/user.conf

echo "Send Limit is $send_limit - ";
echo "User Send Default is $user_send_default - ";
echo "User Send Limit is $user_send_limit - ";
echo "User Size Default is $user_size_default - ";
echo "User Size Limit is $user_size_limit";
if [ "$quota" = "" ]; then
    exit 0;
fi
if [ "$quota" -eq 0 ]; then
    echo "Cannot set unlimited E-Mail quotas";
    exit 1;
fi
#if [ "$quota" -gt "$user_size_limit" ]; then
#    echo "Cannot set quotas above $user_size_limit MB";
#    exit 1;
#fi
exit 0;

That's the present state of the email_change_pass_pre.sh on our test server. At some point, I'd like to re-visit my attempt to restrict the email quota sized based on custom package variables but I digress. Line is indeed a comparison based off $quota, with those two if statements being provided by you around 5 years ago. There may be a better way to handle it now?
 
email_change_pass_pre.sh
Code:
if [ "$quota" -eq 0 ]; then
    echo "Cannot set unlimited E-Mail quotas";
    exit 1;
fi
I can see issue with that..because DA is allowed to set quota=unlimited. When that is the case, you cannot do a numerical comparison, else you get the mentioned "integer expression expected" error.
Should be this instead:
Code:
if [ "$quota" = "unlimited" ]; then
    echo "Cannot set unlimited E-Mail quotas";
    exit 1;
fi
John
 
Back
Top