Re: [rt-users] Full text indexing error with MySQL
Quoting Alex Vandiver on Thu, Aug 25 22:39: > > On Thu, 25 Aug 2016 20:49:48 -0700 > Omen Wild wrote: > > I activated the full text indexing under Ubuntu 16.04 (request-tracker4 > > 4.2.12-5) and (mysql-server 5.7.13-0ubuntu0.16.04.2). Both the initial > > indexing and subsequent calls to rt-fulltext-indexer have the same error: > > > > - Begin quote - > > [3159] [Fri Aug 26 03:03:08 2016] [warning]: DBD::mysql::st execute failed: > > MySQL server has gone away > > That error is almost always that RT tried to do an insert or update > of data larger that the MySQL server's max_allowed_packet. Try > increasing that setting, restarting MySQL, and indexing again. And indeed that was the problem. Bumped it from 16M to 64M and all is well. And now that I check the MySQL error logs I see it complaining there. Thanks for the tip! -- Omen Wild Systems Administrator Metro Cluster - RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training * Boston - October 24-26 * Los Angeles - Q1 2017
Re: [rt-users] How to set up a recursive group in RT 4.4.0
I did not have to do anything special. I simply have some groups which are members of another group, and that is sufficient to have the privileges inherited from the top group down to the members of the bottom groups. Hope this helps. Cris Il venerdì 26 agosto 2016 alle 07:52:53 CEST, Tom Robinson ha scritto: > What does the "Recursive member" flag indicate in the Memberships list of a > group? How does it get set? > On 25/08/16 15:44, Tom Robinson wrote: > > RT 4.4.0 > > > > Hi, > > > > I can't seem to set up a recursive group so that the main groups > > privileges are inherited to member groups. > > > > Can someone please point me in the direction of the best documentation for > > this or give me guidance. My google-fu has failed me today! > > > > Kind regards, > > Tom > > > > > > > > > > - > > RT 4.4 and RTIR training sessions, and a new workshop day! > > https://bestpractical.com/training * Boston - October 24-26 > > * Los Angeles - Q1 2017 - RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training * Boston - October 24-26 * Los Angeles - Q1 2017
Re: [rt-users] Help! I enabled Full Text search and now Simple search won't look at Subjects !!
On Tue, 23 Aug 2016 13:21:20 +0200 Claes Merin 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 - RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training * Boston - October 24-26 * Los Angeles - Q1 2017
