Page MenuHomePhabricator

Cannot filter AbuseLog by filter ID without abusefilter-log-detail
Open, LowPublicFeature

Description

Author: alexsm333

Description:
See URL above with autoconfirmed but not sysop user:
the field "Filter ID" is missing.

The issue is with this code in SpecialAbuseLog.php:
if ($this->canSeeDetails())

$this->mSearchFilter = $wgRequest->getIntOrNull( 'wpSearchFilter' );

Which means that users without abusefilter-log-detail right also cannot filter the AbuseLog by specific filter, which doesn't seem to make sense.


Version: unspecified
Severity: enhancement
URL: http://ru.wikipedia.org/wiki/Special:AbuseLog?uselang=en
See Also:
T44902: "wpSearchFilter" query string does not work on some wikipedias.

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:30 PM
bzimport added a project: AbuseFilter.
bzimport set Reference to bz18476.
bzimport added a subscriber: Unknown Object (MLST).

It's because users without that right aren't allowed to see which filter matched which edit. They just see "matched a filter", rather than "matched filter X"

aokomoriuta wrote:

I think "filtering by ID" isn't belong to "detailed log".

Because anyone can find the mathced abusefilter's name (public description) at "Filter description" in the every AbuseLog's entries without abusefilter-log-detail (but with abusefilter-log).
So it's very easy to find "which filter matched which edit".

Additionally, the api result can filter by ID without abusefilter-log-detail.

   No filtering: http://ja.wikipedia.org/w/api.php?action=query&list=abuselog
filtering by #4: http://ja.wikipedia.org/w/api.php?action=query&list=abuselog&aflfilter=4

This means it's unuseful to hide "filtering by ID" in [[Special:AbuseLog]] to hide something detailed, but only inconvenient.

I agree to comment #0.
This bug should be fixed.

(In reply to comment #2)

I agree to comment #0.
This bug should be fixed.

Me too. I was just going to report it because
http://pt.wikipedia.org/w/index.php?title=Especial:AbuseLog&wpSearchFilter=96
is not filtering the list to me on Portuguese Wikipedia.

For those who are slow (like me), the following will show the problem clearly:

http://en.wikipedia.org/wiki/Special:AbuseLog

and

http://ru.wikipedia.org/wiki/Special:AbuseLog?uselang=en

vs

http://pt.wikipedia.org/wiki/Especial:AbuseLog?uselang=en

ptwiki is missing the "Filter ID" field that enwiki and ruwiki have. As a result, on ruwiki, you can see links to examine the details of the filter.

The behaviour is by design. I'm open to changing it, though.

The real question is whether or not it makes sense to separate the ability to see which filter a specific edit tripped from the ability to view all edits that tripped a particular filter.

How is the configuration of ptwiki different from enwiki and ruwiki? Is it simply that the rights on ptwiki are different than the others?

alexsm333 wrote:

Mark: yes, see bug 17998 which we had to file because of this bug; plus you can compare
http://pt.wikipedia.org/wiki/Special:ListGroupRights?uselang=en and [[Special:ListGroupRights]]

(In reply to comment #7)

Mark: yes, see bug 17998 which we had to file because of this bug;

/me reads bug 17998

Heh, I did say I was slow.

Daimona subscribed.

Hmmm, I just closed T37124, which was about abusefilter-log-detail and briefly wrote there what this right is about. However, here I see that we actually do have a conflict. In AbuseLog, we show the filter's name (=public description) to people with abusefilter-log right. However, this means that such people, IF they also have abusefilter-view, can easily deduce the ID from the description, making abusefilter-log-details more or less unuseful. These are my proposals:

  1. Remove abusefilter-log-detail right and replace its uses with abusefilter-log
  2. Remove the filter's description from abuselog for those without abusefilter-log-detail
  3. Hide IDs in abuselog iff the user doesn't own ( abusefilter-log-detail AND abusefilter-view rights )

And of course, whatever choice we make, we may have to accordingly change sites' configuration.
Every other solution that I can think of is either unuseful or brings a conflict.

From my POV, solution (3) is more straightforward, less controversial, easier and less breaking (probably no need to change configs) than the others, so I'll start doing some testing, but I'd also like to hear other thoughts.

Change 431085 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Show filter ID in abuselog if the user has abusefilter-view

https://gerrit.wikimedia.org/r/431085

This is a scheme of what happens now vs what would happen with the patch above.

Note: This was tested with abusefilter-modify right and without abusefilter-view-private. The last column of the table only takes into account filter ID, details and examine links.

Now

abusefilter-log-detailabusefilter-viewShowed in Special:AbuseLog
yesyesfilter ID (linked), details and examine
yesnofilter ID (linked, gives permission error), details and examine (gives permission error)
noyesnothing
nononothing

With my patch

abusefilter-log-detailabusefilter-viewShowed in Special:AbuseLog
yesyesfilter ID (linked if public), details and examine
yesnofilter ID (not linked) and details
noyesfilter ID (linked if public)
nononothing

And for completeness, this is the situation without any of abusefilter-modify, abusefilter-view-private and abusefilter-private-log.

Now

abusefilter-log-detailabusefilter-viewShowed for public filtersShowed for private filters
yesyesfilter ID (linked), details and examine (without editor)nothing
yesnofilter ID (linked, gives permission error), details and examine (gives permission error)nothing
noyesnothingnothing
nononothingnothing

With my patch

abusefilter-log-detailabusefilter-viewShowed for public filtersShowed for private filters
yesyesfilter ID (linked), details and examine (without editor)filter ID (not linked)
yesnofilter ID (not linked) and detailsnothing
noyesfilter ID (linked)filter ID (not linked)
nononothingnothing
Aklapper subscribed.

Removing task assignee due to inactivity, as this open task has been assigned to the same person for more than two years (see the emails sent to the task assignee on Oct27 and Nov23). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.
(See https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.)

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM
Aklapper removed a subscriber: wikibugs-l-list.