@kostajh I discovered an issue when applying the patch above. It is causing one past issue we previously fixed before - when clicking the user avatar with an open popover, now I can see it closes the popover on "click down", and then reopens with the "click up".

We are currently using the core messages addedwatchtext and removedwatchtext, which are the same message keys when the user manually adds a page to their watchlist.

Small side note but the title/user name text looks too large here, on the mock-ups it's 16px and the data points are 14px.

@KColeman-WMF, just confirming the alignment as well. When the line break happens, we should align the other items to the top, correct?

In T386440#10924585, @nettrom_WMF wrote:

@kostajh asked me to review the contextual attributes. I'd add agent_client_platform_family to the list, since that makes it easy to identify desktop/mobile web usage. That's all, looks good to me!

I'm resolving this as it should be solved in https://phabricator.wikimedia.org/T396443

The patch above is still pointint to the original URL in the ticket (https://www.mediawiki.org/w/index.php?title=Help_talk:Extension:CheckUser).

I believe this last patch should cover the components created in userInfoCard. We should be able to close this task after this last merge.

The first patch for this task is ready, though I'm still pushing more patches as I create unit tests for the remaining components

In T395210#10871487, @KColeman-WMF wrote:

Hi @Mimurawil and @kostajh - I've just been talking to the DST designer about the icon size.

The latest small button design sets the icon at 14px when displayed in small font size mode. Recent changes is always set to small font size mode, therefore it makes sense to me that the icon should in fact be 14px on this page, not 16px.

However, if the icon (and popover) displays on pages where the 2 other font size modes are available, it will need to scale up accordingly.

The following mock-up uses a 14px icon set within a 24px small icon button (figma):

The icon will use design token color-subtle rather than blue, as this is less overwhelming.

@kostajh, should we assume a fallback value (ie: 1000) in case $wgGEUserImpactMaxEdits is not available?

There's a new option in https://github.com/WikipediaLibrary/externallinks/blob/master/extlinks/links/management/commands/linkevents_archive.py#L385 I believe it's able to achieve this, it's the upload option and it accepts a list of files.

The patch above solves the first AC

Candidates in the "last eliminated candidates" statement should show the candidate name, not the candidate id

Just posting some test instructions (mostly copied from https://phabricator.wikimedia.org/T310909#8807183

I'm logging some discoveries while testing my changes.

In T291821#10692972, @dom_walden wrote:

@Mimurawil Thanks. Will this change be made in this task or should I create another one?

I dropped the old PR considering we're already migrating the old archives, which would make this new script unnecessary.

For the integrity errors, the field username_id uses a key that doesn't exist in organisations_user anymore. I replaced those instances and set to null the username_id field (it's a nullable field in the table).

• backup/links_linkevent_202406.4.json.gz
  • Fixed 1850 records
• backup/links_linkevent_202406.5.json.gz
  • Fixed 6628 records
• backup/links_linkevent_202406.6.json.gz
  • Fixed 3645 records
• backup/links_linkevent_202406.7.json.gz
  • Fixed 4377 records

Just adding a final count, now considering the 5 files that got rejected in the migration process (mentioned in https://phabricator.wikimedia.org/T387887#10702024)

Adding sums from 2024-11-01 to 2025-02-12

I executed the scripts for all archives. Since the file is too large, I sent it over GDrive.

Summary from our archives in GDrive - from 2019-07 to 2024-10:

• From date 2023-08-04 to 2023-08-20 - from ID: 11166681 to 11673113
  • Result: change = 0, count = 882 | change = 1, count = 6165
• From date 2023-08-21 to 2023-08-22 - from ID: 11673114 to 12100012
  • Result: change = 0, count = 315 | change = 1, count = 734
• From date 2023-08-23 to 2023-08-26 - from ID: 11673114 to 12100012
  • Result: change = 0, count = 355 | change = 1, count = 3605
• From date 2023-08-27 to 2023-08-29 - from ID: 12584644 to 14147477
  • Result: change = 0, count = 333 | change = 1, count = 937
• From date 2023-08-30 to 2023-08-31 - from ID: 14147478 to 15149195
  • Result: change = 0, count = 148 | change = 1, count = 597
• From date 2023-09-01 to 2023-09-30 - from ID: 15149196 to 23173260
  • Result: change = 0, count = 1595 | change = 1, count = 7757
• From date 2023-10-01 to 2024-01-31 - from ID: 23173261 to 27923227
  • Result: change = 0, count = 7917 | change = 1, count = 51359
• From date 2024-02-01 to 2024-10-30 - from ID: 27923228 to 39687576
  • Result: change = 0, count = 17106 | change = 1, count = 142238

• From date 2023-06-27 to 2023-06-29 - from ID: 8442155 to 9020957
  • Result: change = 0, count = 156 | change = 1, count = 703
• From date 2023-07-01 to 2023-07-18 - from ID: 9020958 to 9421373
  • Result: change = 0, count = 739 | change = 1, count = 6261
• From date 2023-07-19 to 2023-07-21 - from ID: 9421374 to 9726862
  • Result: change = 0, count = 140 | change = 1, count = 757
• From date 2023-07-22 to 2023-07-31 - from ID: 9726863 to 10776213
  • Result: change = 0, count = 844 | change = 1, count = 3405
• From date 2023-08-01 to 2023-08-03 - from ID: 10776214 to 11166680
  • Result: change = 0, count = 207 | change = 1, count = 970

Adding more results from yesterday + today's morning:

Still working on https://phabricator.wikimedia.org/T387887, but posting the metrics I got so far.

In T387887#10652583, @jsn.sherman wrote:

I'm thinking that it could be kept simple by breaking over to a day.x file when you encounter a date change within the current file. The downside would be that it could result in a lot of "extra" undersized files, but the benefit would be not having to worry about trying to track date boundaries across existing files.

I see two different approaches for solving this ticket:

I believe we can use the script created in https://phabricator.wikimedia.org/T386477 to perform the schema update to the latest version we have (considering the open PR https://github.com/WikipediaLibrary/externallinks/pull/420 is correct).

In T386477#10614999, @Mimurawil wrote:

Regarding migrating the old schema from old archives, the fields below will have the treatment:

• user_is_bot -> default to 0 (False)
• domain -> not null field, we need a default value for old archives (maybe a simple n/a should work?)
• hash_link_event_id -> computed (same way as in the migration 0010_data_link_event_id_hash.py)
• content_type_id and object_id -> default to null

PR https://github.com/WikipediaLibrary/externallinks/pull/420 is ready for review

PR is ready for a first review https://github.com/WikipediaLibrary/externallinks/pull/418

• content_type_id and object_id -> default to null

Regarding migrating the old schema from old archives, the fields below will have the treatment:

• user_is_bot -> default to 0 (False)
• domain -> not null field, we need a default value for old archives (maybe a simple n/a should work?)
• hash_link_event_id -> computed (same way as in the migration 0010_data_link_event_id_hash.py)
• content_type_id and object_id -> default to null

In T291821#10559872, @dom_walden wrote:

Do we need to change what we are adding to the droop quota from 0.000001 to 0.0000000001?