Last modified: 2014-09-24 00:02:57 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
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.
(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.
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.
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.
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.
Isn't there a (change visibility) link that gives the hidden item?
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.
Also, some users can't see those links.
In fact, almost all users can't see them. :)
(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.
(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!
(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.
At the moment (on WMF sites) admins don't have links either.
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.
See also bug 18753
(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.
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.
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.
"*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.
(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
(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.
(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.
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?
(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.
(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.
*** Bug 18753 has been marked as a duplicate of this bug. ***
Created attachment 6987 [details] Patch This patch shows hidden log content in the logs, if the user has the rights to unhide them.
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 on attachment 6987 [details] Patch Obsolete per automated testing by Rusty, http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056340.html
