[bugs] [Bug 1033] Changed - Quota bug report NO LIMIT when no messages in INBOX

[bugs@bugs.horde.org]

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.