Per request from Seth, logging a tracking bug to keep a tally on bugs causing havor in search and filters UIs.

havor = havoc I'm not quite sure just how far to take this list, will start with the most recent and blatant ones. Not sure if I should add ones which haven't been considered on our important list, but cause problems anyway (like criteria choices displayed but not implemented).

Sadly, not only does the UI need a cleanup - the code does too. :(

I'm not sure why that remark was called for.

It's an indirect question of whether there are any plans on code cleanup in that area. No offense to the author(s) of that code, it's just that I noticed that some areas of the code is sort of bit-rotted, or is using stuff that it shouldn't be using (like, NULL for instance as opposed to nsnull). If there are any plans on major cleanup, I'd more than eager to help. So please do let me know. Thanks.

Sorry, Hakan for overreacting. We can always use the help in making the code work better.

So, I know this is offtopic and all. But I was, a few weeks ago, planning to mass change all NULLs to nsnulls. Is it worth the effort? and FYI, most of those instances are in base/search/* code.

Seth requested two separate bugs to be logged, separating tracking for Search and Filter UIs. The Filter UI bug has been logged as 77248, I will revise this list.

Sorry for the notifications, but am correcting the list from "blocks" to "depends on".

reassigning to naving

taking search ui tracker bug from naving. we're down from 24 bugs to 4 left. woo-hoo!

only one left! (assuming nothing gets reopened and laurel doesn't have any more "big problems" that should block this bug)

All the bugs that this one depends on are now either WFM or FIXED. Additionally this bug hasn't been used since 2002 and is assigned to the default owner. Therefore I'm resolving this as WFM, but leaving the dependencies for historical tracking. If anyone really does need it open, please comment as to why.