Fixed :)

Looks like the project (https://tools.wmflabs.org/openstack-browser/project/hashtags) was assigned to user Samwalton instead of Samwalton9, so I don't currently have access!

Oh great, thank you!

Translatewiki support is now active and therefore this task doesn't make much sense. We'll put some effort into making sure these major languages are translated, but not specifically.

Just curious - when is the migration expected to happen?

Translatewiki integration is now live and we've done what we can here. We'll take individual issues case-by-case from here.

Now live at https://translatewiki.net/w/i.php?title=Special:MessageGroupStats&group=wikipedia-library !

Immediate first thought: You should be able to browse the page while not logged in, just not see/post the form.

This is now live for testing on Staging: http://twlight-staging.wmflabs.org/

Thanks! Fine by me :)

I'll figure this out soon.

Thank you! As part of the rewrite I planned to move the tool over to a VPS project (T204059) rather than keeping it on Toolforge, to avoid future issues :)

Just a heads up that I've made some time to work on a new version of this tool incorporating improvements we'd wanted in the past (e.g. EventStream monitoring). It will be hosted on a VPS project (T204059) rather than Toolforge to avoid DB issues.

Per the above, I've taken the tool webservice down (not that it was able to do anything without db access anyway), and removed all scheduled db tasks from the crontab.

Work on this is starting in T202615, where a staff dashboard is necessary to enable bulk-uploading of access codes.

Re-opened PR at https://github.com/WikipediaLibrary/TWLight/pull/128.

Both issues fixed in https://github.com/WikipediaLibrary/TWLight/pull/139

In a shocking turn of events, that line wasn't ordering correctly, and is reversed in https://github.com/WikipediaLibrary/TWLight/pull/138, along with some other improvements to that button's functionality.

After the access code PR (T202615) has gone through we can pull this to staging for review.

Probably related, because it's likely to do with the view mixin, but coordinators can also change the partner ID in the URL to send data for other partners.

Need to do some more tests with the csv upload, adding a range of garbage uploads and making sure there's always a descriptive error message.

Per T188205 the tool's database access has been revoked, and the tool will therefore remain down for the forseeable future. I don't have time to create a whole new version of the tool that's more DB-friendly, and I haven't heard from Stephen on this.

As part of this we should further minimise the possibility that someone can even file a duplicate application. The two way it's currently possible are:

• A user had multiple applications for the same partner imported, giving them multiple Renew options on their user page.
• They apply, and then navigate to the Apply (not Browse) page and select the same partner and apply again.

This is an issue with the SUL Info tool, which is currently down: T198320.

Primary functionality implemented. A couple of bits and pieces still need doing (like making sure only staff can visit the staff dashboard), and I need to do tests, update the example data script, and make sure this all plays nicely with account deletion.

Done in https://github.com/WikipediaLibrary/TWLight/pull/136

Done in https://github.com/WikipediaLibrary/TWLight/pull/136

Looks like https://github.com/tiliv/django-field-permissions might be the solution if we're going to still use the admin interface. It don't think it can hide information that staff don't need, but it can restrict them to only editing certain things (i.e. user perms, but not their email).

https://github.com/WikipediaLibrary/TWLight/pull/135

https://github.com/WikipediaLibrary/TWLight/pull/134
Just removed this text entirely based on it being quite self-explanatory.

Thanks to T169618 I've migrated almost all important information over from the old signup pages. We're just waiting on T201152 and we can start minimising our on-wiki information.

Not sure whether this would be best achieved by limiting access to portions of the admin interface, or by creating a new staff dashboard for editing this information.