Page MenuHomePhabricator

New page's patrol button should always be visible, even when not having special links
Closed, ResolvedPublic

Description

For a complete fix of bug 15936, new page's patrol button should always be visible, even when you don't come from Special:RecentChanges or Special:NewPages.
With the fix for bug 15936, the parameter rcid=X was replaced with patrolpage=1, but essentially the situation didn't change, as noted on 48928.

Note that now a button is often visible at the bottom (even without special links, just at normal page URL) which is not about page patrolling as it used to be, but about change patrolling; bug 49115 is about clarifying the purpose of that button.


Version: 1.22.0
Severity: enhancement

Details

Reference
bz49123

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:47 AM
bzimport set Reference to bz49123.
bzimport added a subscriber: Unknown Object (MLST).

So if a revision of a page can be both new page patrolled and revision patrolled, would it make sense to have both in the footer one after each other, like as follows:

[Mark page as patrolled]
[Mark revision as patrolled]

?

(In reply to comment #1)

So if a revision of a page can be both new page patrolled and revision
patrolled, would it make sense to have both in the footer one after each
other,
like as follows:

[Mark page as patrolled]
[Mark revision as patrolled]

I doubt it. A minimal fix of this bug would require the page patrolling link to appear where the change patrolling link is not shown; a complete fix would make the latter always disappear if the former can be shown.

The space has always been used only for page patrolling, which should therefore take precedence.

Nemo: Why did you set a Target Milestone here? If this is just "normal" priority and nobody works on it, it looks like wishful thinking?

(In reply to comment #3)

Nemo: Why did you set a Target Milestone here?

Because it doesn't make sense to release the fix for bug 15936 without a fix for this.

Related URL: https://gerrit.wikimedia.org/r/67040 (Gerrit Change Ib4d72179e4029f0c089c3147bdf4bd6daac0374e)

(In reply to comment #5)

Related URL: https://gerrit.wikimedia.org/r/67040 (Gerrit Change
Ib4d72179e4029f0c089c3147bdf4bd6daac0374e)

Adding Kaldari and Benny to cc so that they can check for interactions with PageTriage.

+keyword design since this is essentially confusion caused over a usability issue

(In reply to comment #8)

Change has been merged.

I still can't patrol a page without rcid: https://translatewiki.net/wiki/User:Danielquayle

(In reply to comment #9)

(In reply to comment #8)

Change has been merged.

I still can't patrol a page without rcid:
https://translatewiki.net/wiki/User:Danielquayle

Fixed in follow-up: https://gerrit.wikimedia.org/r/68588

Yay, I tested on translatewiki.net: recent new pages, new pages created before the patch, new pages with subsequent non autopatrolled edit; all seems to work.

I've tried a quick and dirty query to see if the revision patrolling link in the place of the new page patrolling link, which was available in 1.22wmf5-6, had any effect on amount of patrolling.
Given a number of assumptions one shouldn't make:


SELECT count(*)

FROM logging log

WHERE log.log_type = 'patrol'
AND log.log_action = 'patrol'
AND log.log_timestamp BETWEEN /*20130521200000 AND*/ 20130605235800 AND 20130620180400
AND ( log.log_params LIKE '%"6::auto";i:0%'
OR log.log_params LIKE '%\n0' /* not autopatrolled */ ) ;


So, in the 13 days before the change / with the change:
fr.wiki: 11791 / 12296
nl.wiki: 35436 / 30711
it.wiki: 7652 / 7506