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

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

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.

In T202781#4540631, @aezell wrote:

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.

In T202781#4540939, @dmaza wrote:

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

In T202781#4540631, @aezell wrote:

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

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.

I've posted on wiki for discussion: https://meta.wikimedia.org/wiki/Talk:Community_health_initiative/Per-user_page,_namespace,_and_upload_blocking#How_should_partial_blocks_be_logged

@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)

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)

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.

In T202781#4865947, @Ottomata wrote:

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!