Last modified: 2013-06-04 13:55:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T50928, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 48928 - Impossible to patrol new page with subsequent edit
Impossible to patrol new page with subsequent edit
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Patrolling (Other open bugs)
1.22.0
All All
: Normal normal (vote)
: 1.22.0 release
Assigned To: Marius Hoch
https://translatewiki.net/wiki/User:Odea
:
Depends on:
Blocks: wmf-deployment 39480
  Show dependency treegraph
 
Reported: 2013-05-29 07:54 UTC by Nemo
Modified: 2013-06-04 13:55 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Nemo 2013-05-29 07:54:29 UTC
When I visit some page to its standard URL (e.g. from usual enhanced RC, possibly mixed up by CleanChanges), I can't patrol it if it has new edits and I have to use Special:NewPages.
If I remember correctly what I did here, the link at bottom was initially shown but actually patrolled the last *revision*, then disappeared: <https://translatewiki.net/w/i.php?title=Special:Log&page=User%3A%D9%85%D8%AD%D9%85%D8%AF+%D8%A3%D8%AD%D9%85%D8%AF+%D8%B9%D8%A8%D8%AF+%D8%A7%D9%84%D9%81%D8%AA%D8%A7%D8%AD&hide_patrol_log=0>

Likely steps to reproduce:
1) Create a new page as a non-autopatrolled user
2) Save an edit to the page, with whatever user
3) Visit the canonical URL of the page as a patroller user 
3-bis) Alternatively, visit the URL found in RC, e.g. https://translatewiki.net/w/i.php?title=User:Odea&rcid=8093638
I. Observed: No patrol link is shown at the bottom if (2) is autopatrolled, e.g. at https://translatewiki.net/wiki/User:Odea .
II. Expected: New page patrol link is shown (and actually patrols the page).
4) Visit Special:NewPages and find the page
III. Observed: it's marked as unpatrolled (as in Special:RecentChanges) and links to https://translatewiki.net/w/i.php?title=User:Odea&redirect=no&patrolpage=1
5) Follow the link and patrol.
IV. Observed: Works correctly.
Comment 1 Marius Hoch 2013-05-29 10:15:31 UTC
I can see the problem described here... the cause is that when both recent changes and new page patrolling is enabled the only way to patrol the initial revision (=> the whole page as seen on Special:NewPages) is adding patrolpage=1 or the oldid of the first revision to the URL. If neither of these parameters is there and RC patrolling is enabled MediaWiki will only try to show you a patrol button for the current revision, not the first one.

To work around this issue I could make Special:RecentChanges also set patrolpage=1 in case we have a yet unpatrolled page creation in there.

But I probably wont fix CleanChanges as it's not deployed and I've never had a look at it. If it's creating old style URLs someone has to create another bug and fix that.
Comment 2 Gerrit Notification Bot 2013-05-29 10:52:02 UTC
Related URL: https://gerrit.wikimedia.org/r/65958 (Gerrit Change I9f89f1d44852d4c03a67ac622d5cf4d86453dce3)
Comment 3 Nemo 2013-05-29 11:21:30 UTC
(In reply to comment #1)
> I can see the problem described here... the cause is that when both recent
> changes and new page patrolling is enabled the only way to patrol the initial
> revision (=> the whole page as seen on Special:NewPages) is adding
> patrolpage=1
> or the oldid of the first revision to the URL. If neither of these parameters
> is there and RC patrolling is enabled MediaWiki will only try to show you a
> patrol button for the current revision, not the first one.
> 
> To work around this issue I could make Special:RecentChanges also set
> patrolpage=1 in case we have a yet unpatrolled page creation in there.

Sorry, I'm not sure I understand. Isn't visiting [[Pagename]] supposed to always show me the patrolpage link at bottom if the page can be patrolled?
If this expectation is correct, there are two possible behaviours:
1) make the bottom link always be about page patrolling and not revision patrolling (as it always was),
2) make it patrol the page at least when all the following revisions are patrolled.

> But I probably wont fix CleanChanges as it's not deployed and I've never had
> a
> look at it. If it's creating old style URLs someone has to create another bug
> and fix that.

Sure.
Comment 4 Marius Hoch 2013-05-29 15:09:27 UTC
(In reply to comment #3)
> Sorry, I'm not sure I understand. Isn't visiting [[Pagename]] supposed to
> always show me the patrolpage link at bottom if the page can be patrolled?
> If this expectation is correct, there are two possible behaviours:
> 1) make the bottom link always be about page patrolling and not revision
> patrolling (as it always was),
> 2) make it patrol the page at least when all the following revisions are
> patrolled.

Well, the patch I've now uploaded for review will kind of restore the old behavior for new pages patrol on Wikis with RecentChanges patrol enabled: Only Special:NewPages and the page creation on Special:RecentChanges will allow you to patrol the first revision rather than the current one.
Comment 5 Nemo 2013-05-29 16:30:36 UTC
(In reply to comment #4)
> Well, the patch I've now uploaded for review will kind of restore the old
> behavior for new pages patrol on Wikis with RecentChanges patrol enabled:
> Only
> Special:NewPages and the page creation on Special:RecentChanges will allow
> you
> to patrol the first revision rather than the current one.

I had to read and contrast this comment and the commit message several times to find out how they do /not/ contradict each other. :)
It's not like the old behaviour, because even if you have rcid you can't patrol the page, unless you also have &patrolpage=1. Technically speaking however, the patch would fix this bug; if that way is chosen, as opposed to (1) and (2) in comment 3, we'll need
a) a new bug so that the buttom at bottom doesn't say you're patrolling a page when you're patrolling a revision,
b) reopening of bug 15936 because page patrol link is not always present.
Comment 6 Andre Klapper 2013-05-29 18:25:37 UTC
Marius Hoch: As you added bug 38865 to the "blocks" list, could you please elaborate why this issue is so critical that it should block future deployments on Wikimedia servers? Should priority=normal and severity=normal be changed?
Comment 7 Marius Hoch 2013-05-29 20:57:58 UTC
(In reply to comment #6)
> Marius Hoch: As you added bug 38865 to the "blocks" list, could you please
> elaborate why this issue is so critical that it should block future
> deployments
> on Wikimedia servers?
While there's a very simple fix this issue still *could* (We don't really know) make a lot of people complain about new page patrolling being partly broken on eg. Wikidata and Commons (wikis with both RC and new page patrolling enabled).
Comment 8 Nemo 2013-06-04 08:11:00 UTC
I'm getting quite tired of adding &patrolpage=1 to the URLs to patrol recent changes, can we at least get the simple existing patch merged? Surely it doesn't harm compared to the current situation, all what above standing.
Comment 9 Bawolff (Brian Wolff) 2013-06-04 13:10:11 UTC
merged.

As an aside, I think it would be good to use different messages for page patrol and revision patrol links. I filed bug 49115 for that.
Comment 10 Bawolff (Brian Wolff) 2013-06-04 13:32:26 UTC
BTW, if we want to make it so that "page patrol" is shown in the footer, even if we're not looking at the first revision, I think that should be filed as a separate bug, so as not to conflate issues.
Comment 11 Nemo 2013-06-04 13:55:03 UTC
(In reply to comment #10)
> BTW, if we want to make it so that "page patrol" is shown in the footer, even
> if we're not looking at the first revision, I think that should be filed as a
> separate bug, so as not to conflate issues.

Done with bug 49123.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links