[horde] Horde does not appear to handle an error case w/MySQL prefs

[Rick Irvine]

Software Versions: Horde/Imp/Turba cvs RELENG (2/3/1)

I am finding that some of my users are clicking on the "blacklist" button in
Imp for every single piece of spam they get.  This quickly results in well over
500 or more filters in one horde prefs entry, and I believe creates a single
record that is then truncated when queried by Imp.  The code in
lib/Prefs/sql.php (around line 240) does not appear to check to see if
this record has been truncated.  I have seen users not be able to log in
once their filters entry gets too large.

As a suggestion, how about setting a value in one of the conf files to match
the max_sort_length variable on the MySQL server, and then do a length check
before writing any entry back to the database?  That way the prefs code could
handle such an error itself, with a log/error message set that notes this
problem.

I could simply increase values for the variable(s) on the MySQL side, but I
think this is a growth problem rather than a specific value problem.  (Ie, if
I double the value then when my users hit 1,000 filters I'll have the same
problem.)  Somehow we need to do a check when new horde preferences are added
to make sure that they are not too large for the SQL server.

That would allow Imp to be able to immediately return an error message to the
user if it is unable to write a new filters record out to the database.  (Or,
more correctly, to write one that it would then be able to read back.) Imp
could say "No, I canont write that new filter out, you need to delete some
of the older ones, first."  We could do something like limit the
users to a finite number of filters, but that's a patch to the larger problem
of not being aware of the size limits on returning things of TEXT data type.
(Or more accurately, on sort order returns.)

For now, I can remove the blacklist button and write some educational FAQ
entries for my users, but I would like to see Horde and the various
applications gain the ability to know before writing a record to a MySQL db
whether it can expect to be able to query that record and not see it
truncated.  I'd also like to see error checking put in to try and detect
for truncated records, especially for those table entries that are known to
grow signifigantly.  (I just discovered this today so I have no patches to
submit yet.)

How does this sound to everyone else?

- Rick