[rt-users] Help! I enabled Full Text search and now Simple search won't look at Subjects !!

[Alex Vandiver]

On Tue, 23 Aug 2016 13:21:20 +0200
Claes Merin <claes at gastabud.com> wrote:

> I beg to differ about the attachments table, in our setup we rely on
> customfields and there parameters. We have quite a few tickets that does
> not have any attachments.
>   If you do not write anything in the message body when you create a
> ticket (through web-ui or REST), there will be no attachment connected
> to that ticket.

Creating tickets via the web UI creates empty Attachment rows if the
user enters no content, from my testing on 4.4. I thought we'd
resolved that REST didn't do the same, but I concur that still isn't the
case.

> Also i did a comparison between mysql/mariadb FULLTEXT index and sphinx,
> and it seems that sphinxsearch is able to extract more info than the
> mysql FTS. I guess it's about the data processing that sphinx does with
> encoding and other things.

I'd be curious to hear more about this.  What do you mean by "extract
more info"?  Do you mean better stemming, or what?

> Our goal is to include CF's in the fulltext index as well. As far as I
> can see right now, there are two ways to do this.

Be aware that this can have security implications, as RT has no way to
apply ACLs if all of the different content sources are in the same
index; it becomes possible to find tickets based on custom field values
you cannot actually see.

> a) Modify the RT simplesearch use an "TicketsIndex" instead of the
> "AttachmentsIndex".
> 
> Use sphinx to create the TicketsIndex table and modify the collector
> query to include both attachment, ticket.subject and customfields in the
> the database. (Simple join statements)
> 
> b) Create "null" attachments and attach these to tickets that does not
> have any current attachments, just to create and relation between ticket
> and attachment. The advantage with this is that we do not have to modify
> any of the RT code, but of course it adds some rows to the database.

(b) makes more sense to me.  You currently can limit on transaction
date and creator, and those limits apply in conjunction with content
limits.  If you effectively lump all attachment content to be
cross-referenced by ticket-id instead of attachment-id, you lose that
functionality.

 - Alex