Page MenuHomePhabricator

Cannot add a change tag to AbuseFilter
Closed, ResolvedPublic

Description

Steps to reproduce:

  1. edit an abuse filter
  2. make it tag changes
  3. save

Now you will get message "You must specify a tag name." (tags-create-no-name). The cause is wpFilterTags is always POST'd empty.

Workaround: after unsuccessful attempt modify wpFilterTags request field (using browser tools) and POST again.

Details

Related Gerrit Patches:
mediawiki/extensions/AbuseFilter : wmf/1.32.0-wmf.14Fix jQuery selector when editing filters
mediawiki/extensions/AbuseFilter : masterFix jQuery selector when editing filters

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 28 2018, 12:28 PM
matej_suchanek renamed this task from 'anno to Cannot add a change tag to AbuseFilter.Jul 28 2018, 12:28 PM
matej_suchanek triaged this task as High priority.
Restricted Application added a subscriber: Daimona. · View Herald TranscriptJul 28 2018, 12:28 PM
matej_suchanek updated the task description. (Show Details)

@matej_suchanek I'm afraid this is caused by OOUI switch and introduced in .14. Luckily it doesn't affect group2, but we need to fix and backport it ASAP I guess, since this completely prevents from editing filters with "tag" option. I'll try to give a look at the code to see if I can spot the problem, but won't be able to send a patch, nor backport it.

If you figure out what's wrong, I'll make the patch instead. I wouldn't have created this task if I could figure out that myself...

In the end, we can revert the problematic change if it turns out to be a deeper/upstream issue.

Many thanks. I'm already looking at it, although it's not easy without a testing environment :-) Would you be available e.g. on IRC? At the moment, the first thing I would try is what happens with javascript disabled.

Tried on beta cluster; with JS disabled (so the bogus field is used) the filter is saved correctly, and going back to the filter with JS enabled shows that the correct tags were saved. Looks like a JS problem to me, but I may be wrong.

Apparently, $( '#mw-abusefilter-hidden-tags input' ) refers to nothing.

Change 448855 had a related patch set uploaded (by Matěj Suchánek; owner: Matěj Suchánek):
[mediawiki/extensions/AbuseFilter@master] Fix jQuery selector when editing filters

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

Yes, that's what I concluded as well. I can +2 it, but could you be there for SWAT next week?

Change 448856 had a related patch set uploaded (by Daimona Eaytoy; owner: Matěj Suchánek):
[mediawiki/extensions/AbuseFilter@wmf/1.32.0-wmf.14] Fix jQuery selector when editing filters

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

Yes, that's what I concluded as well. I can +2 it, but could you be there for SWAT next week?

I will.

Change 448855 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Fix jQuery selector when editing filters

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

Many thanks! I confirm that everything is fine on beta cluster, and I was also thinking that maybe we should go safe and infuse that element. This way we can use OOUI-specific methods to set its value without relying on CSS selectors. This also happens another couple of times in AF code, but I haven't determined whether we would benefit from converting those as well.

Change 448856 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@wmf/1.32.0-wmf.14] Fix jQuery selector when editing filters

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

Daimona closed this task as Resolved.Jul 30 2018, 12:25 PM
Daimona removed a project: Patch-For-Review.

Mentioned in SAL (#wikimedia-operations) [2018-07-30T12:58:17Z] <zfilipin@deploy1001> Synchronized php-1.32.0-wmf.14/extensions/AbuseFilter/: SWAT: [[gerrit:448856|Fix jQuery selector when editing filters (T200604)]] (duration: 00m 55s)