Not a bug ConversationMessage search does not exclude messages well

[Xon]

Affected version

2.3.0

ConversationMessage::getTypePermissionTypeConstraints prevents non-recipients from searching for conversation messages they are not part of. This for some reason is skipped when $isOnlyType is true.

Without getTypePermissionTypeConstraints applying the recipient constraint when searching just conversations, search will be degraded for users as the number of conversations grows. That is Elasticsearch will return more and more results XF needs to filter out.

 

[Jeremy P]

When $isOnlyType is true the filtering should be applied by ConversationMessage::getTypePermissionConstraints instead. The whole approach is rather ugly but MySQL boolean syntax is a frustrating experience.

 

[Xon]

In that case I think getTypePermissionConstraints should return the "TypeMetadataConstraint MATCH_NONE constraint" for guest users when $isOnlyType is true.

As getTypePermissionConstraints will not filter out conversation messages by deleted users in ElasticSearch.

This entire API is definitely a deeply confusing

 

[Jeremy P]

I think that constraint should already be applied via getTypePermissionTypeConstraints regardless of $isOnlyType. The getTypePermissionConstraints method only handles the constraint for logged in visitors when searching the same type, while the getTypePermissionTypeConstraints method handles the scoped constraints for logged out visitors regardless of $isOnlyType or for logged in visitors for multiple types.

I'll double check though.

 

[Jeremy P]

I haven't been able to reproduce issues with this so far. The type constraint is applied for guests regardless. To be clear both methods should be run for all queries, regardless of $isOnlyType. The former method is for regular constraints and the latter is for type constraints. The former is applied for members searching conversations, and the latter is applied for all guests searches or members searching multiple types.