Page MenuHomePhabricator

Determine then implement the proper way to log partial blocks
Open, MediumPublic

Description

Questions to answer
  • How will we log partial block entries, especially when they are very complex? (e.g. 100 pages)
    • Ideas documented below
  • How will we log when an admin modifies an existing complex block?
    • Current block modifications are logged as if the admin were setting a new block, but the message Admin blocked user is updated to Admin modified block settings for user
    • Would we re-log every page/namespace in the block, or just the pages/namespaces added/removed?
  • Should the pagenames be linked? Namespace names?

Ideas

Idea 1: One log entry per item blocked

  • If an admin blocks a user from multiple pages/categories/namespaces, a log entry would be created for each item.
  • For example:
    • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Carbon with an expiration time of N (reason) (unblock | change block)
    • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Nitrogen with an expiration time of N (reason) (unblock | change block)
    • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the namespace Template with an expiration time of N (reason) (unblock | change block)
  • All active blocks would then appear on Special:Log (filterable to the user), which would be how a user would see what pages they are prohibited from seeing
  • Pros:
    • Builds off existing structure and behaviors
  • Cons:
    • List could get long and gnarly.
    • Potentially spammy if a user is blocked from a lot of pages at once

Idea 2: One log entry per block action, simplified

  • If an admin sets a granular block, the log could be generic and point to another page that lists the full details of the block
  • Example:
    • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing certain parts of the wiki with an expiration time of N (reason) (unblock | change block)
  • “certain parts of the wiki” could be a link, or a “see details” could be added to the last parenthesis
  • We could create a new Special page (or expand a current Special page) to shows the pages/cats/namespaces a user is blocked from
  • Pros:
    • Saves space, one log entry per block
  • Cons:
    • Block log is not comparable to other block log entries (e.g. to determine when/who/why a certain page was added to a block.) Block logs show a sequence of events and are used to determine wheel-waring and other changes. Because of this, I think Idea 2 is a no-go.

Idea 3: One log entry per block action, detailed

  • Log every log action as a single log entry
  • For example:
    • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Carbon, Nitrogren, Potassium, and Argon and the namespace(s) Template with an expiration time of N (reason) (unblock | change block)
    • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Antidisestablishmentarianism, Pneumonoultramicroscopicsilicovolcanoconiosis, Winchester-on-the-Severn, Maryland, Saint-Remy-en-Bouzemont-Saint-Genest-et-Isson, Supercalifragilisticexpialidocious, The Name of This Band Is Talking Heads, My Best Friend, General Vasili, Son of Joseph Stalin, United States v. Article Consisting of 50,000 Cardboard Boxes More or Less, Each Containing One Pair of Clacker Balls, Fourteenth Amendment to the United States Constitution, and 1995–96 Courage League Division 4 and the namespace(s) Template, Template talk:, Wikipedia, Wikipedia talk:, MediaWiki, MediaWiki talk:, File, File talk, Category, Category talk, Draft, Draft talk and User with an expiration time of N (upload block, This user has abused a lot of things and needs this very specific block.) (unblock | change block)
  • Might not be possible in big blocks (e.g. user is blocked from 100 pages at once or certain length of pagenames)
  • Might not be technically possible
  • Pros:
    • Single log entry
  • Cons:
    • Unreadable in complex situations
    • "Clogs" up Special:Log and other places

Idea 4: Two logs

  • Keep the existing block log as-is, but mark if a block is sitewide or partial
  • For example:
    • TIMESTAMP Admin-who-blocked (t|c|b) sitewide blocked BadApples (t|c) with an expiration time of N (account creation blocked, email disabled, cannot edit own talk page) (reason) (unblock | change block)
    • TIMESTAMP Admin-who-blocked (t|c|b) partially blocked BadApples (t|c) with an expiration time of N (account creation blocked, email disabled, cannot edit own talk page) (reason) (unblock | change block)
  • Introduce a new "partial block log" that only logs each individual item (page, namespace, action) blocked.
  • For example:
    • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Carbon with an expiration time of N (reason) (unblock | change block)
    • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Nitrogen with an expiration time of N (reason) (unblock | change block)
    • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the namespace Template with an expiration time of N (reason) (unblock | change block)
  • The partial block log could be hidden from the primary view of Special:Log, so it wouldn't matter if it was unwieldy
  • Could potentially cross-link between the two, maybe showing the block ID.
  • Pros:
    • Allows Special:Log to be readable, but also allows for the granularity needed to understand the exact contents of a block.
    • Because Special:BlockList and Special:Contributions will show a table view of what a user is currently blocked from, the lengthy nature of the partial block log is acceptable.
  • Cons:
    • The partial log could become very lengthy and unwieldy.
    • Are two logs really necessary? Potentially overkill.

Event Timeline

Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptAug 24 2018, 9:49 PM
TBolliger updated the task description. (Show Details)
TBolliger updated the task description. (Show Details)Aug 24 2018, 9:58 PM
TBolliger updated the task description. (Show Details)Aug 27 2018, 5:52 PM
TBolliger updated the task description. (Show Details)Aug 28 2018, 6:51 PM
TBolliger updated the task description. (Show Details)Aug 28 2018, 11:39 PM

I'm currently favoring Idea 4, as it balances the readability needed for Special:Log while also allowing for a granular (and therefore investigatable) chronologic list of every single partial block action.

Logging block modifications currently only changes one message. From: admin blocked user to admin changed block settings for user

TBolliger updated the task description. (Show Details)Aug 28 2018, 11:55 PM
aezell added a subscriber: aezell.Aug 28 2018, 11:58 PM

Are these block logs ever purged? If not, that secondary partial block log could get out of hand on larger wikis.

dmaza added a subscriber: dmaza.Aug 29 2018, 2:38 AM

I think idea 2 is the way to go. @TBolliger, why do you say that the sequence of events is not gonna be clear? On a side note, we could have a flag as part of the filter to display the full details of the block, or the summarize version of it.

Are these block logs ever purged? If not, that secondary partial block log could get out of hand on larger wikis.

I don't think they are.

TBolliger added a comment.EditedAug 29 2018, 9:04 PM

I think idea 2 is the way to go. @TBolliger, why do you say that the sequence of events is not gonna be clear? On a side note, we could have a flag as part of the filter to display the full details of the block, or the summarize version of it.

Logs are also used to keep admins accountable. An admin could set a partial block against a page, then later modify that block to remove the page. If the pagename is not logged (and the add/remove history is not logged) then there is no evidence of these actions and the admin can not be held accountable. This is also used to determine non-malicious uses (accidents, for example.)

Are these block logs ever purged? If not, that secondary partial block log could get out of hand on larger wikis.

I don't think they are.

I don't think so either, but I vaguely remember something about only old logs being deleted or optimized. Alex — there are dozens of things logged every second (take a look at https://en.wikipedia.org/wiki/Special:Log) — not to include the edit revisions (which are stored in a different table.) I don't expect Partial Block logs to really blow this up, but I guess it's the same questions we're asking in T202322

dmaza added a comment.Aug 29 2018, 9:25 PM

I don't mean not to log the pages/namespaces of a partial block. I mean not to display it by default. The data should be there and accessible if someone wants to know more.

dbarratt added a subscriber: dbarratt.EditedAug 29 2018, 11:51 PM

@TBolliger Could we introduce a template that would allow us to specify each page in the template... maybe by id or something for brevity, but would present to the user a link to "certain parts of the wiki" (or something like that) and it would expand the full list inline? The only problem I foresee is that a log entry might be limited by the number of characters that can be stored in the database. We could mitigate this by storing page ids rather than titles, but we might have to create another entry if it's too long. (which I think is fine).

I guess I'm basically advocating for Idea #2, but the link would just expand it inline (and would look like #3 when expanded). Really that's the only way to do #2. The reason why is because if you delete the block under #2, you wouldn't be able to link to the restrictions anymore (because they would be gone). However, we could either store them on the entry itself (and expand it like I'm suggesting) or create a new log (Idea #4)

aezell added a comment.EditedAug 30 2018, 12:21 AM

The documentation about the comment table says this about the comment_text field where this info is stored:

-- Text comment summarizing the change.
-- This text is shown in the history and other changes lists,
-- rendered in a subset of wiki markup by Linker::formatComment()
-- Size limits are enforced at the application level, and should
-- take care to crop UTF-8 strings appropriately.
comment_text BLOB NOT NULL,

So, I don't think length is that much of an issue but there may be other concerns.

Ah! so that's great in some ways. So it looks like it only does wikitext links (i.e. no other wikitext). So we'd insert them into the log entry by the title (to prevent a database lookup).

So the "cleanest" way would probably be to introduce a "collapsable link set" type of built-in wikitext (which would be acceptable in a log) that would allow you to specify a set of links and have that can be collapsed.

I suppose ideally it would list the first few items and then something like "Show more" to expand the rest of them. The only trouble might be the non-JavaScript version, but I think the "Show More" could refresh the page with a url param that instructs the page to auto-expand the requested one.

Alternatively, we could parse the log and look for a set of links that exceeds a certain number and collapse those entries automatically.

So, in the no-JS version, the "Show more" could just link to the individual log entry like so:
https://test.wikipedia.org/wiki/Special:Log?logid=215476
when loading a single entry, it would be expanded (it would look like Idea #3)

TBolliger renamed this task from Determine the proper way to log partial blocks to Determine then implement the proper way to log partial blocks.Sep 19 2018, 11:20 PM
TBolliger moved this task from Backlog to Snackbox on the Anti-Harassment board.Sep 26 2018, 5:22 PM

Hi all! There are a lot of tickets about this stuff, and I'm just learning about it from Moriel's email so forgive me if I don't have a full understanding. Just an FYI, this will affect both eventbus and change-prop stuff. The EventBus extension is emitting user/blocks-change events on the BlockIpComplete hook. The user/blocks-change schema includes the blocks as they were before the change and as they are after.

A. Will the existing hook function as it does now after the partial blocks change is deployed?
B. Should we modify the event so that it also captures partial block status?

(Ping @Pchelolo :) )

Good questions, @Ottomata. I'll need @Mooeypoo, @dmaza, @Tchanders, or @dbarratt to answer your question.

This particular Phab task was intended to be about the front-end log entries in various feeds, but I understand the technical implementation and storage are inseparable.

A. Will the existing hook function as it does now after the partial blocks change is deployed?

Yes. The hook has not changed, but the Block object has changed.

To determine if it is sitewide or not, there is a new isSitewide() method. You can get the restrictions with getRestrictions().

B. Should we modify the event so that it also captures partial block status?

If it's useful, then sure. You might capture the whether it's sitewide or not, just to know how many partial blocks are being set. You could capture all of the restrictions if you want to know what the users are being blocked from.

OK cool, so then it sounds like at least for event schema stuff, adding partial block info to the event is not a blocker for partial blocks deployment; we can do that whenever we get around to it/need it.

There's another ticket T211950: Add partial blocks to mediawiki history tables out there about mediawiki_history stuff, and I think that one might have more implications about how the log table entry is structured. @Milimetric or @JAllemandou can you comment? It sounds like even for that the change is backwards compatible. But, if yall currently get the blocks from the log table, you might want to weigh n here. If not, then don't worry, T211950 will be enough to track. Thanks!

TBolliger triaged this task as Medium priority.Jan 30 2019, 10:39 PM
TBolliger moved this task from Backlog to User blocking on the MediaWiki-User-management board.
TBolliger moved this task from Snackbox to Backlog on the Anti-Harassment board.Jan 30 2019, 11:05 PM