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.

mike.lifeguard+bugs wrote:

(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.

mike.lifeguard+bugs wrote:

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.

mike.lifeguard+bugs wrote:

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?

mike.lifeguard+bugs wrote:

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.

Prodego wrote:

Also, some users can't see those links.

matthew.britton wrote:

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.

mike.lifeguard+bugs wrote:

(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.

Prodego wrote:

At the moment (on WMF sites) admins don't have links either.

foxyloxy.wikimedia wrote:

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.

FT2.wiki wrote:

See also bug 18753

mike.lifeguard+bugs wrote:

(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.

mike.lifeguard+bugs wrote:

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.

mike.lifeguard+bugs wrote:

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.

Attached:

"*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.

mike.lifeguard+bugs wrote:

(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.

mike.lifeguard+bugs wrote:

(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.

FT2.wiki wrote:

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?

happy.melon.wiki wrote:

(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.

mike.lifeguard+bugs wrote:

(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. ***

revvar wrote:

Patch

This patch shows hidden log content in the logs, if the user has the rights to unhide them.

attachment bug_18335.patch ignored as obsolete

sumanah wrote:

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.

sumanah wrote:

Comment on attachment 6987
Patch

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