As a Wikidata administrator or site operator, I want merging items to be subject to the same rate limits as other edits, and to be checked against AbuseFilter like other edits, so that the amount of damage that vandals can do is limited.
Problem:
ItemMergeInteractor bypasses MediaWikiEditEntity and directly uses the underlying WikiPageEntityStore, probably because it has to edit two entities at once. This means that ItemMergeInteractor is responsible for repeating all the checks done in MediaWikiEntity; it does permission checks, but doesn’t ping the rate limiter nor run the EditFilterMergedContent hook.
Rate limits are, as a result, not checked at all as far as I can tell. (I tested Special:MergeItems, but I assume the wbmergeitems API is equally affected.)
AbuseFilter is still checked at some point, but too late: when testing with a simple AbuseFilter that just blocks all edits unconditionally, there is an error message “EditFilterHook stopped redirect creation” on Special:MergeItems (which apparently comes from the EntityRedirectCreationInteractor) and the last edit (“redirected to target”) doesn’t take place, but the first two edits (“merged item into target”, which clears source the item without redirecting it, and “merged item from source”, which updates the target item with the data from the source item) still happen and aren’t blocked.
To test this, it can be useful to configure a very low rate limit:
$wgRateLimits['edit']['anon'] = [ 1, 60 ]; // 1 per minute
Acceptance criteria:
- Special:MergeItems and wbmergeitems don’t make any edits when the user has hit their rate limit
- Special:MergeItems and wbmergeitems don’t make any edits when there is an AbuseFilter that blocks all edits
