[bugs]
[Bug 1033] Changed - Quota bug report NO LIMIT when no messages in INBOX
bugs@bugs.horde.org
bugs@bugs.horde.org
Wed Nov 20 12:44:24 2002
http://bugs.horde.org/show_bug.cgi?id=1033
*** shadow/1033 Wed Nov 20 05:16:18 2002
--- shadow/1033.tmp.31107 Wed Nov 20 08:44:24 2002
***************
*** 141,143 ****
--- 141,162 ----
correct behaviour on my server. But I don't understand what your patch to
cyrus.php should be for. If imap_get_quota doesn't return an array there was
obviously an error or no quota set. Or did I miss something?
+
+ ------- Additional Comments From kevin_myer@iu13.org 11/20/02 08:44 -------
+ I'm trying to remember why I had to patch cyrus.php. I believe I had to do that
+ because of the case where there is no quota set. You're right when you say
+ that, "if imap_get_quota doesn't return an array there was obviously an error or
+ no quota set." But in cyrus.php, in the function QuotaHTML, the "if
+ (is_array($quota)) {" line is going to be false if no quota is set so the
+ function is going to return with a value of "Unable to retrieve quota", which is
+ wrong if no quota is set. So its safe to assume that a) if opening the stream
+ to the IMAP server did not fail then no quota must be set for that user so you
+ need to short-circuit the function and return prior to hitting the error. This
+ has the effect of returning an empty value to _quotaHTML, which in turn results
+ in the proper "Quota status: NO LIMIT" being presented. In other words, without
+ the patch, quotaHTML will only return a value to _quotaHTML if a quota is set -
+ otherwise, it kicks up _quotaError (for either no quota set or for a real
+ error). That behaviour is wrong and adding the line that I did lets _quotaHTML
+ properly return the "NO LIMIT" value for a user without a quota. It might not
+ be the most elegant way to do it but it works exactly the way one would expect
+ it to.
More information about the bugs
mailing list