<br><font size=2 face="sans-serif">As I mentioned in an earlier message,
reading through the code for</font>
<br><font size=2 face="sans-serif">searching by Custom Field values led
to finding another behavior that</font>
<br><font size=2 face="sans-serif">I consider incorrect.</font>
<br>
<br><font size=2 face="sans-serif">Basically, allowing CF's to take multiple
values is nice, but the</font>
<br><font size=2 face="sans-serif">support for searching these CF's isn't
there, and that reduces the</font>
<br><font size=2 face="sans-serif">usefulness of the feature.</font>
<br>
<br><font size=2 face="sans-serif">Once you allow multiple values in a
single field, the search logic</font>
<br><font size=2 face="sans-serif">gets more complicated. The behavior
I consider intuitive is:</font>
<br>
<br><font size=2 face="sans-serif">1) For positive searches (&quot;is&quot;/&quot;contains&quot;),
the search should be</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;interpreted as &quot;ANY
of the values match this criterion&quot;.</font>
<br>
<br><font size=2 face="sans-serif">2) For negative searches (&quot;isn't&quot;/&quot;doesn't
contain&quot;), the search should be</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;interpreted as &quot;NONE
of the values match this criterion&quot;.</font>
<br>
<br><font size=2 face="sans-serif">I've already mentioned case (1), and
posted a patch to make RT behave</font>
<br><font size=2 face="sans-serif">the way I want, so I won't give examples
here.</font>
<br>
<br><font size=2 face="sans-serif">But the current behavior for case (2)
is, IMHO, even worse.</font>
<br>
<br><font size=2 face="sans-serif">Suppose we have a CF named &quot;Tags&quot;
that accepts multiple values, and</font>
<br><font size=2 face="sans-serif">suppose ticket 123 has values &quot;A&quot;
and &quot;B&quot; for &quot;Tags&quot;.</font>
<br>
<br><font size=2 face="sans-serif">So if the user searches for tickets
that are _not_ tagged with &quot;A&quot;,</font>
<br><font size=2 face="sans-serif">ticket 123 won't be found, right?</font>
<br>
<br><font size=2 face="sans-serif">Wrong! :-(</font>
<br>
<br><font size=2 face="sans-serif">The SQL that gets generated for this
search will effectively find the</font>
<br><font size=2 face="sans-serif">&quot;B&quot; tag, and since that meets
the criterion &quot;!= 'A'&quot;, the ticket will</font>
<br><font size=2 face="sans-serif">be returned.</font>
<br>
<br><font size=2 face="sans-serif">What we need is SQL something like this:</font>
<br><font size=2 face="sans-serif">select main.* from Tickets main</font>
<br><font size=2 face="sans-serif">where ...</font>
<br><font size=2 face="sans-serif">&nbsp; and not exists (select id from
ObjectCustomFieldValues obj1</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; where obj1.Content = 'A'</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; and obj1.ObjectId = main.id)</font>
<br>
<br><font size=2 face="sans-serif">I started to look into getting Tickets_Overlay.pm
to do this, and</font>
<br><font size=2 face="sans-serif">ran into a road-block: afaict, DBIx::SearchBuilder
doesn't provide a</font>
<br><font size=2 face="sans-serif">way to generate this kind of SQL. I
couldn't find any support for</font>
<br><font size=2 face="sans-serif">subselects.</font>
<br>
<br><font size=2 face="sans-serif">I'll be glad to work on a patch, if
some one comes up with an approach</font>
<br><font size=2 face="sans-serif">that doesn't require restructuring lots
of the existing code ...</font>
<br>
<br><font size=2 face="sans-serif">-- <br>
Harry</font>