Under the hood, a renewal is a new application which copies data from its parent application (and has a foreign key back to the parent). The presence or absence of the foreign key tells us whether this application is a renewal. But since it's just a new application, it acts the same way as any other application and can be reviewed/processed via the same set of steps.

Okay! Now there is test coverage and it has been deployed. You have a checkbox for marking renewals available in the admin interface for partners (it defaults to False). Users have a one-click way to request renewals if they have an access grant that's about to expire for a renewals-available partner, and renewals are marked as such in the review queue.

OK, I've got a rough draft of this done, but I need to add test coverage.

Hm, can't seem to replicate that problem (it was redirecting to twl-test instead of wikipedialibrary, so the token didn't work...but then again I was sick when I was doing that testing and the error may have been with me and not the code). If anyone sees this problem again, we can reopen this.

OK, figured out how to check the consumer configuration and it's right, so I need to figure things out on my end.

OK, the consumer was approved and it works on staging, but something's not right yet about the callback URL on production. I need to figure out whether this is an issue on my end (communicating the wrong URL to my OAuth system) or on TWL's end (misconfigured consumer). You can still use the twl-test URL successfully.

It's possible the problem is something else - we had a bug where date_closed wasn't getting set, so I had to just make up a date for the affected applications. I *think* I recall having set it so that it wouldn't disturb the median, but I may be misremembering. I may be able to recover a more accurate date_closed by grepping through the logs, but I don't think this is a high priority for my scant remaining time.

Status: I have this working on the staging server (hooray!)

Status: I've got a first draft of the code for this but I need to test it; waiting on my OAuth consumer for staging to be approved so that I can complete the testing.

Status update: I've got what I think is workable code written, but I need to write tests for it and make sure before I deploy it.

Well, I have learned a delightful amount about the internals of Django model field construction. It works now (including if you leave fields blank).

OK, figured out the problem and the fix, documented it, deployed it. You have tags now! You even have them in French and Finnish if you want. They don't autocomplete, so it's on you to maintain the controlled-ness of the vocabulary (but that seems to be squarely within your core competencies).

Status: I have some code on local/github that does tags, but it's not yet integrating properly with modeltranslation. It's actually on the server but we're not running HEAD right now - we're running code before taggit deploy.

This turned out to be a ridiculous thing rooted in MySQL's inability to do utf-8 correctly. I've updated the database settings, documented them, and added a workaround to the Django settings file. I don't know the user's actual username so I can't fix it, but if you run across this in future and you *do* know the correct username, you can update it through the admin interface.

OK; it's now deployed. I'm going to close this as I have fixed the error you were referencing; if the coordinator has a different error we can reopen it.

Thanks. I have figured this one out - it was SUPER obscure - but I have written a fix (not yet deployed). If the coordinator has seen server errors that come via a different pathway, those may be a different error.

I am unable to replicate this error. Can you give me specific steps (which URL, which application)?

OK, done.

I have actually already fixed that first issue! :) Will fix the second.

Okay, done. You should add coordinators to Partners using the interface at /admin.

OK, done.

What if I put it on the same dashboard/metrics page that has all the other metrics, but display it only to admins?

And with how much visibility - admins only, admins + coordinators, authenticated users, the whole world?

Where and how would you like these metrics to be reported?

But not all partners allow for renewals, so only let them do quick renew if the partner allows it.

Different partners have different policies on this, so we will need the coordinators to keep track of it. Therefore make it easy for users to renew an application, and make sure coordinators can see if it's a renewal or a new application.

Emails for approved and rejected are done. Waitlist emails are waiting for waitlist status to exist.

From meeting on 1/13 - designate the coordinator and list them on the page, but don't do anything permissions-y.

(...deploying that when github is not in the midst of a major status outage.)

OK, the only two packages in that grid that support Django 1.8 and look reasonably credible/well-supported are modeltranslation and hvad. Of these, modeltranslation looks easier to deploy, and is more obviously straightforward for site administrators to use, so that's what I'm going with. Deploying that now.

This raises some implementation questions for me.

If the user isn't logged in, I can't consult the user's settings, because I don't know what user they are yet. I use the home wiki to construct the URL for OAuth; although their username should be the same across different wikis, the information I get back from Wikipedia (e.g. edit count) will be different based on which wiki I query, and that has implications for TWLight (e.g. what data do we display on the user profile page, do they even have autoconfirmed status).

Ah! Okay, I understand. I have removed those system details from display and updated the tests accordingly.

Hey, I have done this thing! twlight-staging.wmflabs.org now exists. In the process I have battle-tested and updated the sysadmin docs - they need a little bit of cleanup, but I've written out all the commands in a form that would be pretty easy to package up in scripts.

This is several bugs, but I believe I have now deployed code which addresses all of them (and added some regression tests :).

I suppose so!

OK, I have this fixed locally now. As with a lot of things, the deploy is being held up until I set up a testing server and push the 1.8 changes.

I want to clarify something here. When I say 'what is required', I mean that I'm displaying the information that each partner requires editors to submit in order to apply for access. But you are saying that partners only need to receive lists of emails in order to grant access, even if they say they require more information in the application?

Yes, we can get this from OAuth and Alex Stinson confirmed for me a while ago that it is a good plan.

OK, I've updated the translator instructions (in locale/README.md).

I've requested this at T153549 ; once that resolves I can start installing & configuring things.

Okay, I've got this code done, but I'm going to block deploying it on T147471 - I want to do the whole upgrade process on a testing server first to make sure I've got the instructions right.

If we don't have an email address, that means either Wikipedia doesn't have an email address for the users, or they don't have Special:Email enabled, so we haven't harvested it.

Fixed by updating jQuery version.

Are renewals different from access grants? That is, would a partner potentially have X renewals and Y new access grants available? Or do they just have Y access grants available, which we can split between new and renewed as desired?

Assigning this to @Ocaasi_WMF because the spec is unclear - exactly what sort of filtering options do you want? Go ahead and assign it back to me when you have details.