Last modified: 2014-09-24 00:02:57 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 T20335, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18335 - Log entries for deleting log entries are opaque
Log entries for deleting log entries are opaque
Status: NEW
Product: MediaWiki
Classification: Unclassified
Revision deletion (Other open bugs)
1.15.x
All All
: Low normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 18753 (view as bug list)
Depends on:
Blocks: revdel SWMT
  Show dependency treegraph
 
Reported: 2009-04-04 02:39 UTC by Mike.lifeguard
Modified: 2014-09-24 00:02 UTC (History)
12 users (show)

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


Attachments
Mockup of a priviledged user's view of hidden log entries in situ (8.58 KB, text/html)
2009-07-18 15:57 UTC, Mike.lifeguard
Details
Patch (1.03 KB, patch)
2010-01-20 17:10 UTC, revvar
Details

Description Mike.lifeguard 2009-04-04 02:39:29 UTC
There is no indication here of /which/ log entry was hidden for

# 01:53, 4 April 2009 Mike.lifeguard (Talk | contribs | block) changed event visibility of (Global account log) ‎ (hid content for 1 event: hiding grawp attack) 

I think a better way to show this would be to restate the parts (if any) of the log entry that are not hidden. In this case, I hid the target, so restate the comment, timestamp and who made that log entry in the first place:

# 01:53, 4 April 2009 Mike.lifeguard (Talk | contribs | block) changed event visibility of (Global account log: 19:51, 26 March 2009 Shanel (Talk | contribs | block) <s>(log action removed)</s> ‎ (name) ) ‎ (hid content: hiding grawp attack)

"Global account log" would ideally link back to the original log entry
Comment 1 Alex Z. 2009-04-04 02:44:50 UTC
What happens if the comment or the user is hidden later? Then the comment of the initial log deletion entry would have to be hidden as well. The timestamp could probably be included though.
Comment 2 Mike.lifeguard 2009-04-04 02:48:22 UTC
(In reply to comment #1)
> What happens if the comment or the user is hidden later? Then the comment of
> the initial log deletion entry would have to be hidden as well. The timestamp
> could probably be included though.
> 

Yes, it'd have to be a reference back to the actual log entry, not just a copy. Alternatively, just making (Global account log) link to the actual log entry instead of the log as a whole would be acceptable - hit the link to load that entry & see whatever you can see, which will depend on what is hidden at that moment.
Comment 3 Alex Z. 2009-04-04 17:17:27 UTC
I think a link to the log entry would probably be better, otherwise, you could end up with some /really/ long entries in the deletion log, a max of 255 bytes for the comment of each log entry, plus the title and username, etc.
Comment 4 Mike.lifeguard 2009-04-04 17:54:35 UTC
True... also showing each log line would be equivalent to showing 2, since you have to get the one it refers to as well... making things twice as expensive sounds bad when a simple link would do the trick just as well.
Comment 5 Mike.lifeguard 2009-04-05 02:57:05 UTC
Currently blocks using hideuser are logged in their entirety in the suppression log, but for deleting log entries, you only get a useless entry saying that someone hid something for some reason - but no indication of what it was. If you can see the suppress log then you should be able to see that information without hunting it down. This is a big usability issue.
Comment 6 Aaron Schulz 2009-04-07 02:44:27 UTC
Isn't there a (change visibility) link that gives the hidden item?
Comment 7 Mike.lifeguard 2009-04-07 03:53:00 UTC
Right, but if you want to look at the last 50 log entries that were suppressed or deleted, you have to load up 50 of those links. Like I said, that's a huge usability issue. If the user can see that information anyways, just put it in the suppression log directly instead of hiding it behind a link.
Comment 8 Prodego 2009-04-07 14:16:07 UTC
Also, some users can't see those links.
Comment 9 Gurch 2009-04-07 15:31:02 UTC
In fact, almost all users can't see them. :)
Comment 10 Aaron Schulz 2009-04-10 20:04:37 UTC
(In reply to comment #9)
> In fact, almost all users can't see them. :)
> 

In the vacuous sense that they can't see the entire log since it is private anyway.
Comment 11 Mike.lifeguard 2009-04-10 20:06:01 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > In fact, almost all users can't see them. :)
> > 
> 
> In the vacuous sense that they can't see the entire log since it is private
> anyway.
> 

The deletion log isn't!
Comment 12 Aaron Schulz 2009-04-10 20:18:10 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > In fact, almost all users can't see them. :)
> > > 
> > 
> > In the vacuous sense that they can't see the entire log since it is private
> > anyway.
> > 
> 
> The deletion log isn't!
> 

I'm talking about what is actually live and used, which almost exclusively suppression. This bugs lacks clarity. First, it says the hidden item should be linked. Then it says that it is linked, but it should be shown inline. Then there are comments about non-admins not having links.

What information should be shown inline anyway? Username, new, minor, and comment? Certainly the text wouldn't fit in any useful way.
Comment 13 Prodego 2009-04-13 17:30:53 UTC
At the moment (on WMF sites) admins don't have links either.
Comment 14 en:Fl 2009-05-10 03:47:00 UTC
We should have a more informative log entry, such as; User (talk | contribs | block) changed event visibility of logid 4958 in the Move Log or include the related revision/logid within the edit summary.
Comment 15 FT2 2009-05-10 20:25:02 UTC
See also bug 18753
Comment 16 Mike.lifeguard 2009-05-21 03:19:31 UTC
(In reply to comment #14)
> We should have a more informative log entry, such as; User (talk | contribs |
> block) changed event visibility of logid 4958 in the Move Log or include the
> related revision/logid within the edit summary.
> 

The logid is included, I think... but that's not informative for the user unless they specifically look up what that logid actually is. It's like saying someone deleted articleid X... not that great if we want this to be usable by mere mortals.
Comment 17 Mike.lifeguard 2009-07-18 15:16:58 UTC
Aaron: Sorry for the confusion. I think part of the issue is a lack of experience with using the tools in various situations.

After putting some more thought into this, I think the issue is primarily one of usability. While the information is there, it's hidden behind a click+page load. If you're looking for a particular entry, then opening each "change visibility" link in turn is your only strategy. "Is it this one? No. Is it this one? No..." isn't a very good strategy unless your goal is to waste time and energy.

Instead, users who /could/ see the information, were they to click the "change visibility" link, should instead be shown that information upfront in the original log (ie where the information appeared before it was deleted/suppressed).

In this way, searching through the logs would actually be fruitful for the people who actually need to use these features.

Take an example:
*I lock+hide User:Mike.lifeguard's address is 123 Main St., Chicago@global.
*I block the local account using hideuser - this is logged in it's entirety in the suppression log, so it is very easy to find.
*I hide the entry in Special:Log/globalauth because it contains personal information (with the "hide from sysops too" option)
*Now, the information is gone from Special:Log/globalauth *and* it doesn't appear in Special:Log/suppress (except behind a "change visibility" link -- but which one? Nobody knows until you actually look and find it, which is a waste of time).
**INSTEAD: In Special:Log/globalauth, the entry remains (appropriate parts crossed+greyed out and with a bolded (show/hide) link (since it was hidden from sysops... if not, then that link wouldn't be bolded).

There would still be a suppression log entry of the kind that exists now, however leaving the information available in the log where the suppressed content appeared makes this usable. To match this, consider putting blocks which use hideuser in the block log for those who are allowed to see them, but appropriately greyed out/crossed out. The suppression log should then have log entries which point (via "change visibility" links) to the more relevant logs (block log for hideuser-blocks, and globalauth log for entries hidden there, and so on)

This leaves information where it can be most easily found by the people who need it, and retains the suppression log as a central place to see when/where such actions get taken, for oversight/audit purposes.

In short: users who could see the information, were they to click the right "change visibility" link, should see the hidden information in the original location instead of <s>(log action removed)</s> etc. The interface for users who aren't allowed to see the hidden information doesn't change.
Comment 18 Mike.lifeguard 2009-07-18 15:57:59 UTC
Created attachment 6359 [details]
Mockup of a priviledged user's view of hidden log entries in situ

Here's how two entries in the globalauth log would look to those with the appropriate rights to view this information.

Unprivileged users would have the standard (log entry hidden) + greyed out.
Comment 19 Aaron Schulz 2009-09-02 23:36:03 UTC
"*I hide the entry in Special:Log/globalauth because it contains personal
information (with the "hide from sysops too" option)"

Then go to that globalauth entry and click "show/hide". That will give the reason.
Comment 20 Mike.lifeguard 2009-09-02 23:38:58 UTC
(In reply to comment #19)
> Then go to that globalauth entry and click "show/hide". That will give the
> reason.
> 

That makes sense for one or maybe two at a time. But if you need to quickly review several hundred... not so much
Comment 21 Aaron Schulz 2009-09-03 01:11:38 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > Then go to that globalauth entry and click "show/hide". That will give the
> > reason.
> > 
> 
> That makes sense for one or maybe two at a time. But if you need to quickly
> review several hundred... not so much
> 

Yes, but the point is that "... Nobody knows until you actually look and find it, which is a waste
of time)." doesn't really apply.

What this *can* do is save a extra click though.
Comment 22 Mike.lifeguard 2009-10-02 16:01:32 UTC
(In reply to comment #21)
> What this *can* do is save a extra click though.

An extra click for every row you need to click on, which may be hundreds.
Comment 23 FT2 2009-10-02 16:12:44 UTC
We have collapse boxes for text sections. If we added inline collapse boxes to the common.js, then the log could have "User (t|c|b) changed visibility of <N> entries in the Delete Log [list +/-]"

where the list expands on clicking to an in-line list of affected entries for those able to see it.

Neat, quick to use, low clutter, and (hopefully) simple?
Comment 24 Happy-melon 2009-10-02 16:16:25 UTC
(In reply to comment #23)
> We have collapse boxes for text sections. If we added inline collapse boxes to
> the common.js, then the log could have "User (t|c|b) changed visibility of <N>
> entries in the Delete Log [list +/-]"
> 
> where the list expands on clicking to an in-line list of affected entries for
> those able to see it.
> 

This should be done by an asynchronous AJAX query, rather than having the content inline and hidden.  Otherwise the amount of content being served on each pageview could become massive. But the principle is the same.
Comment 25 Mike.lifeguard 2009-10-02 16:34:43 UTC
(In reply to comment #23)
> where the list expands on clicking to an in-line list of affected entries for
> those able to see it.

Sexy! But we'd also need a way to expand/collapse all of these on a page at once.
Comment 26 Aaron Schulz 2009-11-18 20:13:23 UTC
*** Bug 18753 has been marked as a duplicate of this bug. ***
Comment 27 revvar 2010-01-20 17:10:49 UTC
Created attachment 6987 [details]
Patch

This patch shows hidden log content in the logs, if the user has the rights to unhide them.
Comment 28 Sumana Harihareswara 2011-11-25 02:56:03 UTC
revvar, I'm sorry to say that this patch no longer applies cleanly to trunk; we delayed in reviewing it, for which I apologise, and the codebase has changed.  If you have the time and the interest, please do revise it and reattach, and we'll be sure to review it a lot sooner this time.  Thank you for the contribution.
Comment 29 Sumana Harihareswara 2011-11-25 02:56:25 UTC
Comment on attachment 6987 [details]
Patch

Obsolete per automated testing by Rusty, http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056340.html

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


Navigation
Links