Search private messages function requested

Interesting idea.

however searching is not trivial so this needs a bit more thought.

By the way. later versions of drupal6 privatemsg will allow categorizing messages by tagging them. this will allow for easy message organization and may eliminate the need to search the messages. what are your thoughts on this?

sorry i wont dedicate my time to it.

It's unfortunate that this is a "won't fix" since this seems like a natural necessity as a site grows.

I think it is a useful feature for many drupal users.

This feature has been commited yesterday.

The new privatemsg_filter module allows currently:
- Filter by authors
- Filter and organize messages by tags
- Search Message Titles

Searching could maybe be improved to search message body too and using proper text search instead of a simple LIKE '%placeholder%' but it does work for now.

The filter module does allow you to search the titles, just not the message body.

Just need to get into the hang of things again - nice simple patch - no idea if its a good idea or not - the module now searches through the message body too.

The problem with your patch is, that it is probably (I haven't tested it yet) quite slow. IMHO, we should atleast make it configurable so that sites with large amounts of private messages can disable it.

Another way of doing it would be to somehow re-use the standard drupal search, this might be complex because of all the permission issues or use fulltext indexes, but this needs atleast mysql5 or pgsql8.3 (afaik)

Some Tests with MySQL with many generated messages

pm_index: 375k rows, 30MB
pm_message: 36k rows, 62MB

Without body searching:

43.54	1	pager_query	SELECT pmi.thread_id, MIN(pm.subject) as subject, MAX(pm.timestamp) as timestamp, MAX(pmi.is_new) as is_new FROM pm_message pm INNER JOIN pm_index pmi ON pm.mid = pmi.mid WHERE (pmi.uid = 1) AND (pmi.deleted = 0) AND (pm.subject LIKE '%gos%') GROUP BY pmi.thread_id ORDER BY is_new desc, timestamp DESC LIMIT 0, 25
40.57	1	pager_query	SELECT COUNT(DISTINCT pmi.thread_id) FROM pm_message pm INNER JOIN pm_index pmi ON pm.mid = pmi.mid WHERE (pmi.uid = 1) AND (pmi.deleted = 0) AND (pm.subject LIKE '%gos%')

---

With body searching and a short, single word:

101.31	1	pager_query	SELECT pmi.thread_id, MIN(pm.subject) as subject, MAX(pm.timestamp) as timestamp, MAX(pmi.is_new) as is_new FROM pm_message pm INNER JOIN pm_index pmi ON pm.mid = pmi.mid WHERE (pmi.uid = 1) AND (pmi.deleted = 0) AND (pm.subject LIKE '%odio%' OR pm.body LIKE '%odio%') GROUP BY pmi.thread_id ORDER BY is_new desc, timestamp DESC LIMIT 0, 25
96.06	1	pager_query	SELECT COUNT(DISTINCT pmi.thread_id) FROM pm_message pm INNER JOIN pm_index pmi ON pm.mid = pmi.mid WHERE (pmi.uid = 1) AND (pmi.deleted = 0) AND (pm.subject LIKE '%odio%' OR pm.body LIKE '%odio%')

With multipe words

171.32	1	pager_query	SELECT pmi.thread_id, MIN(pm.subject) as subject, MAX(pm.timestamp) as timestamp, MAX(pmi.is_new) as is_new FROM pm_message pm INNER JOIN pm_index pmi ON pm.mid = pmi.mid WHERE (pmi.uid = 1) AND (pmi.deleted = 0) AND (pm.subject LIKE '%Valetudo scisco premo elit hos%' OR pm.body LIKE '%Valetudo scisco premo elit hos%') GROUP BY pmi.thread_id ORDER BY is_new desc, timestamp DESC LIMIT 0, 25
170.92	1	pager_query	SELECT COUNT(DISTINCT pmi.thread_id) FROM pm_message pm INNER JOIN pm_index pmi ON pm.mid = pmi.mid WHERE (pmi.uid = 1) AND (pmi.deleted = 0) AND (pm.subject LIKE '%Valetudo scisco premo elit hos%' OR pm.body LIKE '%Valetudo scisco premo elit hos%')

So, it is slow, but actually not as slow as I expected it.

Attached is a improved patch, that does make the body search configurable.

in order to improve performance of the searches we must combine body and subject fields into the same table. for that reason we must first improve pmsg API so the search functionality can store relevant copy of the messages in _it's own table_ to perform searches faster.

lets not perform searches on the core pmsg tables. searches with table joins are super slow :(.

**double post**

They are in the same table. ???

/me takes note not to reply to complicated issues seconds after waking up.

I assume that this needs review?

I also think that search functionality is critical to the success of this module on large sites... can I also inquire into the current status? Are there plans to incorporate this into 5.x?

Drupal 5.x and no one is working on it - though if someone provides a working patch and ALSO others review it, it may go in (I have previously got tired of a Drupal 5 support request, provided a patch only for all comments to suddenly stop. I assume that the patch worked, but that is no way to actually get the patch committed.)

The advice is to move new developments to Drupal 6.

Patch in comment 11 works. I have re rolled it to not be offset in the privatemsg.module file, but no actual changes.

I do think that the wording in the settings page could be better, but I could not think of anything better.

Thanks for the patch nbz! I'll give it a shot.

I'd love to upgrade to Drupal 6 (and have done so with a number of my sites), but I've got one monster site going that incorporates a number of modules that have sadly not yet been ported... even when (if) everything finally does get ported, it will be a huge task to upgrade the site to D6; and by then I'll be told to upgrade to D7. Sigh. ;)

PS that patch is just a reroll of one by Berdir and is for Drupal 6 version.

yup, upgrading can be a never ending task. I guess it all depends on starting new developments/feature work on a new base, but past sites will always be a problem.

I'm making changes affecting this issue, but I'm not going to test the patch, just modify search/tag code in the module for the open issue #351542: user interface. Should I have this issue assigned anyway?

I'm setting it back to CNR then.

I think this should stay at rtbc and if this goes in first, the other patch adapted.

Let them race to the finish line.

I could agree with this. Returning back to previous status (rtbc).

Committed with some of my own changes to the patch.

Ok, any way, I've done several improvements to the filtering and tagging schemas, And the result can replace the initial _filter module without trouble on merging.

I'll continue this 'searching' discussion in the UI thread. Please, go to #351542: user interface