- Affected version
- 2.2.12
This is related to this bug, but is a deeper design issue.
Both
Making
Basically, XF should resolve from the
XF still does canView validation php-side, but this can result in more results being filtered out and which displays less results than expected to the end-user.
Both
actionSearch/actionMembers allow a search query to target the thread search handler without loading the post search handler's getTypePermissionConstraints values. These search constraints would normally be loaded if a "thread" search was done via the advanced search form.Thread::getTypePermissionConstraints returns an empty array, unlike Post::getTypePermissionConstraints which returns constraints. This is because Post::getTypePermissionConstraints and Thread::getTypePermissionConstraints are both called during a 'general' search and it is desirable to avoid duplicate conditions.Making
Thread::getTypePermissionConstraints call Post::getTypePermissionConstraints would not solve this issue in the general case, which includes 3rd party add-ons, around parent/child searchable content types which follow the same pattern of the child-content type implementing search constraints.Basically, XF should resolve from the
thread to post handler and use the post handler + a thread filter instead for searches to ensure getTypePermissionConstraints is called in the same way. Conveniently, search handlers can return a list of search types they cover and if they are grouped by another search type. A lack of grouping is effectively how to determine what is the "parent" search type.actionMembers probably needs to call prepareSearchQuery instead of setting up an ad-hoc Query object, and then it would inherit the above fixes.XF still does canView validation php-side, but this can result in more results being filtered out and which displays less results than expected to the end-user.
