Page MenuHomePhabricator

Implement functionality for RC page 'User registration' filters
Closed, InvalidPublic


Filtering and/or highlighting editor contributions based on registration status is useful to a number of workflows. The User registration' filters enable users to identify and isolate contributions in this way. Find the authoritative interface text (filter names and descriptions) for these at T149385. There are two filters in the group:

This finds contributions by all users who are registered and logged in. It includes bots (which users can be eliminate via a separate filter).

This finds contributions by all users who are not registered or are not logged in.

About the functionality of these filters

  • The current RC page includes the ability to hide and show Unregistered users. This existing functionality can be used as the basis for these filters.
  • HOWEVER, like all filters in the enhanced RC page filter UI, these filters conform to a set of rules that are, in some ways, very different from the existing RC page filters. The existing filters are designed primarily to EXCLUDE selected properties (in this case, Unregistered users). The new filters are designed to INCLUDE those properties; logically, each new group is a set of OR filters (and each group of ORs is connected to other groups by ANDS). Which means the filters in this group follow these rules:
    • To INCLUDE property A, users check the box for property A.
    • To EXCLUDE property A, the user must uncheck A and check it's complement, property B.
    • If NEITHER A nor B are checked, then BOTH are included.
    • If BOTH A and B are checked, then the result is the same: BOTH are included.
  • As per T146076, searches on the RC page are meant to be bookmarkable. Please make sure your search adds query strings to the URL.

Event Timeline

The existing filters can be used to accomplish this.

Registered: hideanons=1
Unregistered: hideliu=1

It is possible to use both of those filters together, in which case it does something unexpected[1], but using them carefully works. Do we want to use them or add a new-style filter (userRegistration=registered|unregistered|all)?


if ( $opts['hideanons'] && $opts['hideliu'] ) {
	if ( $opts['hidebots'] ) {
		$hideanons = false;
	} else {
		$botsonly = true;

If I read that code correctly, it's saying the system will always show something, even if the user says not to? Pinging @Pginer-WMF, but I'm pretty sure he'll agree that the new implementation has no room for such hidden functionality. (And no need, since our system would not allow the user to hide both registered and unregistered in any case.)

I.e., stick to the spec above: if neither is checked, then it's the same as if both are checked -- the function returns registered and unregistered.

Some of the complexities of the existing model seem to come by the diversity of actions ("hide x" vs "show only y"). Our proposed approach is based on describing a list of properties you want to see in the results (and considering that mentioning nothing means not adding any restriction).

I don't have a preference on how to better express filters on the API as long they support the intended user behaviour at the UI level.
For a filter such as "newcomer + experienced + good-faith", I can imagine multiple representations ("filters: newcomer, experienced, good-faith", "(newcomer OR experienced) AND good-faith", "showNewcomer=1, showExperienced=1, showGoodFaith=1") but the concept of "hide" does not seem very intuitive here.

Another relevant question is what do we want to do in terms of backward compatibility. If we change the way filters are expressed, do we want people with old bookmarks to be redirected to the new naming system to avoid breaking their workflows? (I think it would be desirable but I'm not sure how complex it would be or how many people reach the page base on external links/bookmarks).

For most filters, we've decided to continue using the hide* style. It's different than what the UI presents but it works quite well and the new filters will co-exist better with the old ones.

hideanons and hideliu already exist and will be used by the new UI.

The "creative" behavior when both are true won't be possible with the new UI but if it turns out to be a problem, we'll change it.

Related to this, I created a ticket about communicating contradicting filtering parameters that cannot be represented in the current model: T151873: Redirect when a URL cannot be adapted to the new filter system for Recent Changes