[ postfixadmin-Bugs-3306926 ] check_quota function fails to handle unlimited quota
Brought to you by:
christian_boltz,
gingerdog
From: SourceForge.net <no...@so...> - 2011-05-31 23:07:51
|
Bugs item #3306926, was opened at 2011-05-24 15:34 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306926&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: SVN (please specify revision!) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Dunnett (magick777) Assigned to: Nobody/Anonymous (nobody) Summary: check_quota function fails to handle unlimited quota Initial Comment: (found in SVN 1061) When a domain's quota is set to "0", meaning "unlimited quota" according to the web interface, all edits to a user's quota are rejected as too high. The problem is in the function "check_quota", which checks if ($quota > $limit['maxquota']) { $rval = false; } AFTER it checks if ($limit['maxquota'] == 0) { $rval = true; } and therefore declines any quota for being greater than the "maximum" of 0. Reversing these two checks fixes the problem and causes a quota of 0 to return a successful quota_check as expected. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-06-01 01:07 Message: I prefer code that does not depend on the execution order too much ;-) check_quota() was more or less rewritten to support domain-level total quota. On the positive side this means that 2.3.x is not affected by this bug. I just changed some parts of the function back to the 2.3.x state - it now uses "return true/false" again instead of settiong $rval if the result is final (as in "can't be changed by domain quota check"). I also added several comments that explain what the function is doing after it took me a while to understand it ;-) The bug you reported is fixed by this change: - if ($quota > $limit['maxquota']) { + if ($limit['maxquota'] != 0 && $quota > $limit['maxquota']) { This excludes the "unlimited" maxquota from the check and should therefore solve the problem. Commited to SVN trunk r1065. Thanks for the bugreport! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306926&group_id=191583 |