We should avoid "Was a TWL partner, isn't now, but we have stored linkevents" because there isn't a clean way to delete this without losing the historical data.

@Chlod Do you have interest/capacity in doing this? If not we'll see if we can queue this up some time soon.

Hm, you're right. I and someone else were discussing this yesterday and both reproduced the issue, but now I'm unable to. Odd.

Some user feedback - it may not be visually obvious when a given collection is an 'apply' or 'access' one, without having to stop and read the button. Is there more we could do visually to distinguish them? This doesn't need to be a blocker, it could be a followup task.

See also T433019: Design: Suggested Edits (final specs for the pilot release of Home), which is another feed module.

Ha, thanks for pointing this out. I agree a fact that can change over time was a poor choice, on reflection :)

Tangible work to do here - move to the hosted stanza.

Sorry that we haven't been able to address this issue yet. We're currently using a custom config, but Fold3 have an EZProxy stanza we could be using instead. We migrated away from that to attempt to fix the issues ourselves, but clearly that didn't work, so I think we should move back to it, and if it's broken, contact Fold3 to fix things for us.

These are all old/deleted TWL partners that we didn't delete in Wikilink.

We set a target URL so this shouldn't happen again.

Staging is extremely slow for me, for some reason. Anyway, tried to access AM and eventually got:

Connection refused by www.amdigital.co.uk, please try again later.

It's certainly not ideal. We wanted to define a metric that was technically easy to implement, as a first pass, which could capture how many edits a user had interacted with. Reverting and thanking were the most obvious two actions to track, since all users can do those things and we have clear/easy logs of those actions.

Sorry if you're already aware of this, but I tried to access ?moduleGroup=home on patchdemo and got

Fatal error: Declaration of GrowthExperiments\PersonalDashboard\Mentorship::canRender() must be compatible with MediaWiki\Extension\PersonalDashboard\Modules\BaseModule::canRender(): bool in /var/www/html/w/extensions/GrowthExperiments/includes/PersonalDashboard/Mentorship.php on line 89

We seem to be actively collecting link events, see e.g. https://wikilink.wmflabs.org/admin/links/urlpattern/18/change/?_changelist_filters=all%3D

As a reminder, and as I investigate what I can, we define API URLs at the organisation level for fetching the user list for all collections/URL patterns under a given org.

BNA have got a fix in place. I've just tested it and the login seems to be working as expected now. Closing this out but let me know if you find any related issues.

users can contact the publisher to request a copy of the document needed for writing, or even to have it added to the lib access.

Thanks @Framawiki! We'll have the first monthly report file from EZProxy available to view in the first week of September, so we'll take a look then and provide an initial update here.

No problem!

We plan to do this after T433724. As the second flag, we need to decide whether to choose one chip or show all of them, or something else. For now, let's show both if an edit is both major and high revert risk.

I think this might be coming from Twinkle, or another user script or gadget ('vandalism' isn't a Mediawiki feature). Can you try looking at this page with ?safe mode=1 in the URL?

Stalled on me creating that Mediawiki page.

We'll tackle this one first, and use it to build out capability for flags in general - so if something can be generic to support other flags please make it generic!

From BNA:

This matches a known issue that we're currently investigating with our Engineering team. It affects some libraries accessing the British Newspaper Archive via EZProxy, where users are unable to sign in to their personal BNA accounts.