Lack of interest Add User criteria support to other systems

[CMTV]

Hi!

XenForo has a useful and extandable criteria system. Trophy and Notice systems are using the User criteria type already.

With this system, we can easily create different trophies (or show notices) to a users that match certain selected criteria.

But there are many more systems that are all about users but do not use the criteria system:

• Alerting users
• Emailing users
• Messaging users
• Search for users
• Batch update users

All systems above are using "User search criteria" which contains very few parameters. It is way much weaker than User criteria.

To sum up, we have a weird situation, where some systems can use the power of user criteria system (trophies and notices) and some can not...

My suggestion: Add or even replace "User search criteria" with User criteria which uses criteria system.

Why?

Because the User criteria provides many more different options. Adding it would greatly increase flexibility in sending/emailing/messaging users and etc.

For example, I can't alert users with 500 or more likes becuase, well, because there in such an option in "User search criteria".

Also, keep in mind that some addons also add their own criteria to User criteria. It is not very convinient for addon markers to copy-paste a code for both criteria and searchers systems!

--- (Realisation suggestions) ---

Why not adding "User criteria" tab to all systems in the list in the previous message and perform additional criteria-based fetching on the users, firstly selected by "User search criteria"?

Another way is to replace User searcher with new UserSearch criteria type which handles all "User search criteria" criteria. With this approach, you can simply add a new tab called "User search criteria" to all systems listed above.

 

[Mike]

For the primary suggestion, I'm tempted to say this won't happen. The searcher system and the criteria system do perform similar functions, but they also have different uses.

The general criteria system allows essentially arbitrary checks (other queries, accessing the file system, etc) and has to be handled in a way where you only check a small number of users at a time as it requires individual fetches and entity instantiation). The searcher system is entirely focused on SQL limiting. It needs to be able to take 100,000 potential users and get the 10 matches as quickly as possible. If you have a situation where criteria checks need to be run on the full user base, this essentially has to be done via a job. See the trophy/promotion rebuild tools.

There could theoretically be a medium, though that mostly adds a lot of potential complexity to things that use the searcher system, as it would completely redesign how they work (because all results would have to be precalculated and stored to allow them to be browsed). Personally, I don't think this is worthwhile.

Interestingly, the like example isn't ideal as 2.1 actually exposes the reaction score here. I think virtually all of the default criteria could be pretty easily converted to the searcher system, potentially with only template edits. For custom criteria, if the value is stored as a column in the DB, the same would apply. (If a particular value isn't stored, then it actually emphasizes the overhead/problem with applying arbitrary criteria as the overhead to calculate may be huge.)

 

[CMTV]

It really makes sense now. If handling criteria for one user takes, for instance, 0.1 second than it will require 10 000 seconds to check all users. Not cool