Page MenuHomePhabricator

Implement way of querying Proofread Page Status of a Page: (or revision) from the databases directly...
Open, LowPublic

Description

Currently on English Wikisource Proofread page uses an embedded string at the head of the page to find the status of a page and the user that changed that status.

This means that whilst a search like:
insource: /pagequality level\=\"4\" user\=\"ShakespeareFan00\" / or
insource: /pagequality level\=\"4\" user\=\"Sfan00\" /

will find pages that I validated, it's a lot less easy to determine if these were later downgraded or re-validated over concerns about the original validation.

It's also possible to examine the status be cross-referencing the Category_links table.

However it would be appreciated if there was a way to query the Proofread Page status of any given Page: more directly such that a complex query can be reduced to a very simple WHERE clause based on a numeric test.

I'm not sure how this could be implemented in the long term though

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 3 2017, 3:42 PM
ShakespeareFan00 triaged this task as Low priority.Aug 3 2017, 3:42 PM

https://quarry.wmflabs.org/query/20680 is a partial soloution, but it can't easily track when something's status changed.

Tpt added a subscriber: Tpt.Aug 3 2017, 8:53 PM

The pageprop mechanism seems a good way to allow such things (and will remove the need for the extension to rely on categories): https://www.mediawiki.org/wiki/Manual:Page_props_table

That was my thinking... The categories are useful though

My other additional thought was to have an additional "revision properties" table, that was like page properties but applied to specific revisions, so you can track status changes more closely by examining specific entries in a revision properties log_table.

Side question, how and where are certain types of "logged" edit summaries stored? (Examining that might be a possible suggestion on how revision properties might be added.)

The other issue would be recording in the database (possibly with a revision) who changed the status.

Tpt added a comment.Aug 4 2017, 7:55 PM

We could use the revision tag system and add a tag for each revision giving the status or a tag for each status change. See: https://www.mediawiki.org/wiki/Manual:Tags
I believe that storing which user changed the status in the database is not useful because it could be easily retrieved from the revision table (especially if we choose to have specific tags for each status change)

Hmm so the /* Problematic */ etc auto summaries become proper revision tags?

That makes sense. :)

Tpt added a comment.Aug 4 2017, 8:12 PM

Hmm so the /* Problematic */ etc auto summaries become proper revision tags?

It's the goal :-).

And how would this allow the sort of query I had in mind in my use case?

(I am assuming you do a Quarry query and cross reference the tag table as well, but I am not as up on SQL stuff with mediawiki as I perhaps should be.)

Tpt added a comment.Aug 4 2017, 8:28 PM

And how would this allow the sort of query I had in mind in my use case?

You do two joins between the revision table and the change_tag table (one for the current revision and one for the previous revision using the rev_parent_id column) and you use a WHERE close to filter on the previous/current revision status (using the change_tag table). You could retrieve the editing user with the rev_user column. With that you could retrieve e.g. all the validations done by a given user.

Which was my use case, Thanks...

The next problem is how someone could change proofread page in a non-breaking way to support this in future. Hmmm...

Tpt added a comment.Aug 4 2017, 8:36 PM

The next problem is how someone could change proofread page in a non-breaking way to support this in future. Hmmm...

It should not be too hard to add proper revision tags for new revisions. Then we could run a database update script to fill the tags for older revisions. When every revision is going to have their tag we could start to use them in ProofreadPage code instead of categories. But it's not a small task.

That's appreciated, and kind of why I'd tagged this as longer-term.

Still it would be VERY useful.

Magol added a subscriber: Magol.May 3 2018, 8:54 AM
MJL moved this task from Backlog to Backlog (Proofreader) on the Wikisource board.Sep 9 2019, 11:41 PM