Page MenuHomePhabricator

Need a way for WDQS updater to become aware of suppressed deletes
Open, Stalled, HighPublic

Description

Once T237502: Provide public "reload entity to WDQS" API is fixed, reloading entity should be automatically invoked after a suppressed delete (probably via a job).


Original:
From comment by @Legoktm at T105091:

If a page is deleted with the supppress checkbox ticked (common when the entire page needs suppression), then no recentchanges entry will be generated since the log action is private (Special:RecentChanges or RCStream).

We need a way to get WDQS notified of such thing happening and have it to process it as a removal of the corresponding item.

Event Timeline

Smalyshev raised the priority of this task from to Needs Triage.
Smalyshev updated the task description. (Show Details)
Smalyshev added subscribers: Smalyshev, Legoktm.
Restricted Application added projects: Wikidata, Discovery. · View Herald TranscriptJul 9 2015, 11:33 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Deskana triaged this task as High priority.Jul 10 2015, 6:50 PM
Deskana added a subscriber: Deskana.

We may need some help from Wikidata folks on the question of how we discover such things. Any API? Or any way to patch it so that they would appear in the stream? After all, there's nothing informative in the Q-ids themselves, so I do not see how any harm could follow from having them in the public stream, even if the content of the item has to be suppressed.

That is not specific to Wikidata. IMHO it is not a good use of time to create a software solution that is specific to Wikidata. Any Mediawiki installation that uses page deletion with suppression has the same problem for anything that mirrors it via changes. So this task in its generic form has nothing to do with Wikibase.

What do the rest base people do to not leak stuff like this?

The easiest solution that is specific for Wikidata is: Tell the few people with this capability to not use it, but instead oversight revisions (possibly create a new one first). Maybe it can even be disabled via configuration?

Lydia_Pintscher moved this task from incoming to monitoring on the Wikidata board.Jul 12 2015, 1:08 PM

The easiest solution that is specific for Wikidata is: Tell the few people with this capability to not use it, but instead oversight revisions (possibly create a new one first). Maybe it can even be disabled via configuration?

And what happens when a steward does an emergency suppression and isn't familiar with this technical restriction?

I think we should write a small WDQS extension that hooks into ArticleDeleteComplete, and sends a HTTP request (maybe with an auth token?) to WDQS telling it to force update the page.

And what happens when a steward does an emergency suppression and isn't familiar with this technical restriction?

If you don't read https://www.wikidata.org/wiki/Wikidata:Oversight before doing that it is natural that you are going to make errors. Anyway the error can be corrected afterwards. How often does an emergency suppression of an entity with only one revision happen?

I think we should write a small WDQS extension that hooks into ArticleDeleteComplete, and sends a HTTP request (maybe with an auth token?) to WDQS telling it to force update the page.

Then what about all the WDQS instances not hosted at the foundation and the mirrors and so on?

Is some public log of suppressed page and revision ids more work than your proposed solution? (Preferably it would be in RecentChanges.)

I think we should write a small WDQS extension that hooks into ArticleDeleteComplete, and sends a HTTP request (maybe with an auth token?) to WDQS

The problem here is that WDQS is purely pull now. Adding push to it adds a lot of complication, as Wikidata now needs to know about every instance of WDQS is running, and be able to notify them, which requires a whole host of functionality developed on both sides. I'm not sure developing this just for this narrow case is warranted.

Alternatively, could we have some API that just would show the list of Q/P-ids that were suppress-deleted? Maybe some extension to query API or separate API? The Q/P-id does not have any private/sensitive information in it, and as far as I can see, can not contain any info covered by oversight policy. So the impact of the API saying "this ID was deleted, no further info available" would be minimal.

Of course, even better solution would be to just have it in the RC stream, which also doesn't have any info besides IDs anyway, as I understand.

Smalyshev moved this task from Needs triage to WDQS on the Discovery board.Jul 14 2015, 10:15 PM

Change 226931 had a related patch set uploaded (by Smalyshev):
T105427: produce a blank RC entry on suppressed deletes

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

Change 227372 had a related patch set uploaded (by Smalyshev):
T105427: create nearly-blank RC entry for suppressed events

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

Excellent work, Stas. I did some trivial reformatting of the note.

At this stage, I'm just going to post the note directly onto the Oversight page with an explanatory note on the talk page. If someone on Wikidata objects, they can revert me and we can discuss.

Deskana closed this task as Resolved.Aug 12 2015, 7:41 PM

https://www.wikidata.org/w/index.php?title=Wikidata:Oversight&diff=prev&oldid=240547936

https://www.wikidata.org/w/index.php?title=Wikidata_talk:Oversight&diff=prev&oldid=240551918

In light of these, I think is is fair to consider this issue resolved for now. We're still looking for a more rigorous solution, but this is good enough for a first release.

Change 226931 abandoned by Smalyshev:
T105427: produce a blank RC entry on suppressed deletes

Reason:
Probably not the right way to solve it, we'd get to that with Event Bus

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

Change 227372 abandoned by Smalyshev:
T105427: create nearly-blank RC entry for suppressed events

Reason:
Probably not the right way to solve it, we'd get to that with Event Bus

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

Bugreporter reopened this task as Open.Nov 6 2019, 8:34 AM
Bugreporter added a subscriber: Bugreporter.

Reopened: This is only a workaround and not a proper fix of the problem described in task description.

(If anyone think this should be filed as a new task, feel free to say so. But as what needs be done is exactly in the task title, I choose to reopen this task.)

Bugreporter updated the task description. (Show Details)Nov 6 2019, 8:45 AM
dcausse removed Smalyshev as the assignee of this task.Dec 10 2019, 10:02 PM
Zbyszko claimed this task.Jan 13 2020, 8:38 AM
Zbyszko changed the task status from Open to Stalled.Jan 16 2020, 1:02 PM

We are stopping work on this for now, pending architecture change. We have a solution in mind that can make this work automatically - based on the events coming from mediawiki.revision-visibility-change we can refresh affected entities. Once we move to a fully reactive system, we can implement this quite easily.

revi added a subscriber: revi.Jan 29 2020, 3:41 PM
Gehel removed Zbyszko as the assignee of this task.Apr 15 2020, 12:34 PM
Gehel added a subscriber: Zbyszko.