Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
(found in SVN 1061)
SQL query at line 110 of edit-domain.php fails with an error in SQL syntax.
quota=$fDomainquota needs to be in single quotes, i.e. quota='$fDomainquota', in order to accept a value of '-1'.
Hmm, what database are you using? I can't reproduce it with MySQL.
Another question: does this bug also happen with the other fields, for example the numer of mailboxes and aliases?
Please check this - it would be good to know if I decide to backport the fix to the 2.3 branch.
Afterwards, please update to the latest SVN version. I replaced the query to use db_update() in SVN r1064 which results in more readable code and, as a side effect ;-) also fixes this bug.
Database is MySQL 5.1.49-3, shipped with Debian 6.
Problem does not occur with other fields (mailboxes and aliases); these seem to accept a value of -1 without having quoted them in the SQL query. Doesn't make much sense.
Removed the single quotes again to check I'm not going mad. Having done so, editing any domain now fails regardless of the quota value, with:
Invalid query: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'transport='virtual', backupmx='0',active='1',modified=NOW() WHERE domain='cardre' at line 1
This applies regardless of the quota value specified, it turns out, which confuses me more. But, I put the quotes back in and the query succeeds with the quota correctly recorded - whether or not that quota is a positive or negative integer. Colour me (very) confused; my description of the issue now seems imperfect, but, it breaks as soon as I remove the quotes.
I'll hold off for a couple more days on 1064 in case there's any more debugging I can usefully do, but, if the problem is fixed in latest SVN it may or may not be worth spending too much debug time on it. Let me know if I can usefully test anything else against 1061.
A possible explanation: the quota and maxquota fields are of type "bigint", the aliases and mailboxes fields are "int". Can you test if you need the quotes for unlimited maxquota also?
Regarding debugging: You can use something like "echo $query;" to print the query - and then copy it into a MySQL shell and shorten it (delete one field after the other, then re-add them one by one in another order) to find out which part breaks.
If you are unsure which changes you did to the file, run "svn diff" to see the changes or "svn revert" to go back to the file as it exists in SVN (this will overwrite all your changes!).
The fix I did in SVN trunk is too intrusive for a backport to the 2.3 branch IMHO, therefore I'd have to "just" add quotes in the 2.3 branch. And for that it would be good to know which fields are affected by this bug and how your working query/code looks like.
OTOH, you are the first one who hit this bug - therefore we shouldn't invest too much time for the backport ;-)
More and more bizarre; maxquota works fine unquoted, leading me to suspect that the problem lies in whatever PHP is feeding to SQL for quota.
One debug statement later:
UPDATE domain SET description='Redirect',aliases=0,mailboxes=-1,maxquota=-1,quota=,transport='virtual', backupmx='0',active='1',modified=NOW() WHERE domain='cardremit.com'
so, the problem has precious little to do with quoting, it has to do with there being no quota passed to the query. In my DB, the quota field is "0" for all domains, so for reasons I haven't yet looked into, the edit-domain code in 1061 seems to be losing that value as I edit a domain. My apologies for a less than complete bug report; since quoting fixed the problem, I assumed it was the problem. Oops.
However, I agree this isn't worth chasing further (for me at least), and less so still if quota and domainquota are working in current SVN. I suspect it might come down to "user has upgraded and not configured something right", or to a bug that no longer exists. Either way, thanks for looking at it and I'll try 1064.
That's really interesting. The empty value instead of 0 sounds like a funny[tm] PHP automatic type conversation to me (string instead of int).
Since you seem to be the only one who has/had this problem, I'll close the bug as fixed. Feel free to reopen if you still have problems with r1064 or newer (or in the 2.3.3 release).