Program Officer at The Wikipedia Library.
Also User:Samwalton9 (WMF).
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.
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:
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.
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).
Just removed this text entirely based on it being quite self-explanatory.
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.