This issue is about adding messages to global search. This is part of devang2511 GSOC 2016 project proposal.

This seems quite straight forward but it is not, I propose to add two search areas, one for sent messages and another one for received messages. I need to explain it a bit, keep messaging case in mind:

1. Each document have an id, unique across all moodle's contents and an itemid that is unique only inside the search area. The global one is created from the document itemid + the search area.
2. Each document have a context field and a owneruserid field, documents with a owneruserid field can only be accesed by the owner, so the difference between setting a document in context user and setting the userid in the owneruserid field is that if owneruserid is set not even admins can access that document, only the owner. Admins though can access all documents contexts, including other user's contexts.
3. The current api does not allow us to set an array of values for a given field, this was designed this way because we want to support all kind of search engines people can think of, would be pretty easy for some of them like solr, but for some of them would be hard, imagine the moodle database search engine, would need to re-parse the document objects that is receiving from the search api to split them in two, would also require multiple context ids as search areas like messaging works at context user, mapping between them... This search area would be suitable for messaging as it would be the only way we have to avoid redundant messaging contents in the search engine
4. Each searchable document should have a unique URL. I mean that we should not have a mycourses search area document pointing to course/view.php?id=X and a potentialcourses document pointing to course/view.php?id=X, the later one should point to the enrol page, this would not be a problem for messaging because the URL changes between users.

To skip this search API limitation I suggest to have two different search areas because:

1. The amount of redundant data would not be huge (no files support)
2. I don't even know now what kind of dirty engineering tricks we would need to do to adapt the search api to support an array of users with access to a document
3. Having two different search areas will only be noticeable by the user when filtering by search area, thanks to the nice autocomplete thing this will not be a problem, as we can easily see the potential choices and we can select multiple search areas