Last modified: 2014-09-01 19:56:17 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 70239 - Generate entries for deletions and restores in page histories
Generate entries for deletions and restores in page histories
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
Page deletion (Other open bugs)
1.24rc
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nathan Larson
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-31 19:26 UTC by Nathan Larson
Modified: 2014-09-01 19:56 UTC (History)
5 users (show)

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


Attachments

Description Nathan Larson 2014-08-31 19:26:58 UTC
Add null revisions for page delete and restore events. In the case of a page deletion event, the null revision would be stored as a new archive table row.
Comment 1 Jesús Martínez Novo (Ciencia Al Poder) 2014-08-31 19:29:59 UTC
Could you explain what problem are you trying to solve, or why would it be useful?
Comment 2 Nathan Larson 2014-08-31 21:00:02 UTC
(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #1)
> Could you explain what problem are you trying to solve, or why would it be
> useful?

Then the page history (index.php?action=history) can display the deletion and restoration log events. That seems like a pretty important part of the history of what's been happening with the page, much like imports. [[mw:Manual:Null revision]]
Comment 3 Gerrit Notification Bot 2014-09-01 01:29:51 UTC
Change 157636 had a related patch set uploaded by leucosticte:
Save a null revision in page history notifying of deletion/undeletion When a page is deleted or undeleted, save a null revision in the page history.

https://gerrit.wikimedia.org/r/157636
Comment 4 Jackmcbarn 2014-09-01 02:00:20 UTC
History splits/merges/etc. are already really messy as it is, and this would make them even worse for virtually no gain. There's no good reason to duplicate this information that's already in the logs.
Comment 5 Nathan Larson 2014-09-01 03:36:25 UTC
(In reply to Jackmcbarn from comment #4)
> History splits/merges/etc. are already really messy as it is, and this would
> make them even worse for virtually no gain. There's no good reason to
> duplicate this information that's already in the logs.

I wonder if there are some other log events that don't need to have null revisions either? Like page protection events?
Comment 6 MZMcBride 2014-09-01 05:17:44 UTC
(In reply to Jackmcbarn from comment #4)
> History splits/merges/etc. are already really messy as it is, and this would
> make them even worse for virtually no gain. There's no good reason to
> duplicate this information that's already in the logs.

?action=history (that is, the page's history) probably should include matching items from Special:Log. The fact that page protections and page moves leave a visible entry and administrative actions such as page deletion and page restoration do not leave an entry in the page history is strange and unexpected, I think. We're logging this information, why oddly segregate it? It should be integrated. There's some parity with Special:Contributions and Special:Log (cf. bug 3716).

There's a real design issue here: in the GUI, we're currently poorly exposing what should be internal implementation details. Yes, there's a revision table and a logging table, but only people working on MediaWiki need to care about this. There are a few different approaches we can take to address this issue. This bug report is probably a duplicate of bug 4172.
Comment 7 Nathan Larson 2014-09-01 05:23:05 UTC
(In reply to MZMcBride from comment #6)
> need to care about this. There are a few different approaches we can take to
> address this issue. This bug report is probably a duplicate of bug 4172.

What approaches did you have in mind?
Comment 8 MZMcBride 2014-09-01 05:31:55 UTC
(In reply to Nathan Larson from comment #7)
> (In reply to MZMcBride from comment #6)
>> need to care about this. There are a few different approaches we can take to
>> address this issue. This bug report is probably a duplicate of bug 4172.
> 
> What approaches did you have in mind?

Figuring out a way to fold Special:Log entries into ?action=history and Special:Contributions is one approach.

Another approach would be adding null revisions when deleting or undeleting. But I'm not a huge fan of this idea, as it feels messy. Even the null revisions being inserted for page protection and page moves feel kind of hackish to me.
Comment 9 Nathan Larson 2014-09-01 12:27:34 UTC
Don't null revisions also have the drawback that changing the visibility of a log event doesn't automatically change the visibility of the null revision?
Comment 10 Jackmcbarn 2014-09-01 16:13:33 UTC
(In reply to Nathan Larson from comment #9)
> Don't null revisions also have the drawback that changing the visibility of
> a log event doesn't automatically change the visibility of the null revision?

Yes.
Comment 11 Nathan Larson 2014-09-01 16:21:11 UTC
(In reply to Jackmcbarn from comment #10)
> Yes.

Filed as bug 70261.
Comment 12 Jesús Martínez Novo (Ciencia Al Poder) 2014-09-01 19:25:44 UTC
> (In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #1)
> > Could you explain what problem are you trying to solve, or why would it be
> > useful?
> 
> Then the page history (index.php?action=history) can display the deletion
> and restoration log events. That seems like a pretty important part of the
> history of what's been happening with the page, much like imports.
> [[mw:Manual:Null revision]]

"Add null revisions for page delete and restore events" This is an implementation design/decision, not a valid issue. Please see the summary description in the "how to report a bug" guide [1]. Changing accordingly.

The problem with this patch is that it will "fix" it for new deletions and restores, but old actions won't have that null revision.

(In reply to MZMcBride from comment #6)
> The fact that page protections and page
> moves leave a visible entry and administrative actions such as page deletion
> and page restoration do not leave an entry in the page history is strange
> and unexpected, I think. We're logging this information, why oddly segregate
> it? It should be integrated.

Yes, that's not very consistent. But when you delete the whole page, you delete the entire history, so there's no point in having an entry in the history about that unless you restore the page again.

(In reply to MZMcBride from comment #6)
> There's a real design issue here: in the GUI, we're currently poorly
> exposing what should be internal implementation details. Yes, there's a
> revision table and a logging table, but only people working on MediaWiki
> need to care about this. There are a few different approaches we can take to
> address this issue. This bug report is probably a duplicate of bug 4172.

Agreed. Although page moves can mess the things. Imagine you have a lot of logs in page A, you then move page A to B (without leaving a redirect), and then move page C to A. With the current logging system, if this approach would be implemented, the page history of A would have the history of the old page C mixed with logs of the new page B.

----

[1] https://www.mediawiki.org/wiki/How_to_report_a_bug(In reply to Nathan Larson from comment #2)
Comment 13 Jackmcbarn 2014-09-01 19:56:17 UTC
If the inconsistency is a problem, I'd much rather see it fixed by removing the null revisions from the things that cause them now, rather than by adding them in even more places.

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


Navigation
Links