This may or may not be a useful default, that probably depends on the type of community, but I’m not sure it really solves making personal messages more accessible in searches.
In the context of private support, it seems reasonable to assume that it will be strongly related to the community at large, making it likely that there will be similar topics/posts and could produce a lot of noise around the personal messages a user might be searching for.
In the same way that categories get computed titles in the suggestions, perhaps in:personal could benefit from its own associated title to make the suggestion a bit more friendly.
For example, if I start a search while viewing the feature category here, I will see this:
and selecting that will add #feature to the search query. For personal messages, that could be something like “in Messages” where selecting it would still add in:personal to the search query.
Doesn’t the search automatically scope to PMs when you are viewing PMs? Let me check. Oh I see, this behavior did change @sam@pmusaraj. It’s no longer defaulting to that search option when you are on the messages tab, but it really should IMO…
Yes, we moved away from defaulting to a search filter in specific routes in the app because our search widget now suggests filters as you type. (For example, if you type words that match a category/tag name, it’ll be suggested as a filter).
But nobody is going to type in:personal, so that doesn’t help. and I agree with @jerry0, it is a confusing label. The easiest improvement would be to add in:messages as a synonym to in:personal and use that in the UI.
A more complicated solution could be to do what we do for in-topic search. We have a special case there, that is only automatically enabled when the ⌘+F shortcut is invoked (which we override on topics with many posts):
This would be golden. I really miss the ability to do a keyword search for messages in a specific group inbox. I don’t think this is possible at all right now, unless I am missing something.
2: This commit added support for the in:messages keyword. It works the same as in:personal (which is still available), but now we prioritize in:messages in the UI.
This is a great improvement! in:messages is so much more intuitive to me than in:personal.
Is there any way to also make it possible to search for messages in a group inbox? I am realizing now that I don’t think there’s been any conversation about what this would look like. Maybe group:GROUPNAME?
I’ve just noticed that using the search for group_messages: doesn’t give a ‘more…’ link at the bottom of the quick results like the others. Is that by design?
This is also on the searching of Private Messages thing.
My users (and I) struggle to find messages from or involving a specific user. When searching in:messages, username only pops up if it has been included in the body of the message.
It would be super helpful to have username and name of the message author be searched too, and given priority.
It would be even better to have a specific filter for messages from a user or group when one is looking in their inbox, but I suspect that would be quite a bit more involved!
The advanced filter does get them (with @mention in the search term) but that is a little too technical for my very untechnical users who will just type in the name of the person and expect them to pop up.
This is a typical dysfunctional workflow:
From their inbox, they try to find the user in their messages using the lovely default in:messages (and fail)
Open up Advanced Search and Select the user in Posted by. Realise that this only includes those mesages with the name in the body as it remains in the search box:
For numpty users (i.e. most of them/us) it would be super helpful if these were included in the initial results as only the most savvy will successfully drill down the first time.
Sure, users can be taught how to do this. But that isn’t great UX!!
Yesterday, I merged a fix that includes topic participants in PM search data @nathank. Note that it works for new PMs only by default, if you would like to have it reply retroactively, you would need to run the search:reindex rake task.