An expiring member should receive a renewal reminder email

[cmrn]

When a member's "Last Renewal Date" is about to reach a year, they should be sent a reminder to renew their membership. The email should contain a link to the renewal page (#49).

[brendam]

Unsure what the best way to have this sort of regular task run in a Flask app. Seems like there are at least three options:

• have an endpoint in the flask app that runs the renewals job
• use flask-script if we want it to be from the command line
• mailer.py decoupled from mhvdb2.app so that it can be called externally and read the database (seems like this would allow it to get out of step with the Flask app though)

[jamiereid]

Perhaps a endpoint that can be hit from a cronjob?

[brendam]

Make sure to only send out reminders to people who expire in 2014, not all the older members.

[mbainrot]

The flask endpoint should check the remote IP and only run if its equal to 127.x.x.x or ::1

Additionally to avoid bugging old members maybe have a setting to ignore expired accounts that have already been emailed logic would go?

Cronjob:

START for member in members do if member.expiryEmailSent < maxReminderEmails AND member.expiryEmailSent != (-1) then send email to member member.expiryEmailSent += 1 next END

Modification to member payment handler START ... member.expiryEmailSent = 0 ... END

This allows for a few things:

• The rate that the cronjob fires at determines at what interval the member receives a reminder
• maxReminderEmails allows the number of emails to be sent to be controlled, after x emails worth of reminding every month system considers member an inactive member and leaves them alone
• On paying for membership it self resets thus meaning that if a member had gone inactive for a period of time and then has come back, they receive notifications again if they miss any payments again.
• Allows for the exclusion of old members who are presumed inactive until they pay again (I take it thats what you mean @brendam) by simply setting expiryEmailSent to an arbitrarily high number or alternatively to -1

All the extra stuff isn't needed for MHV but makes it easier for other maker groups to tweak to what they want :)

Impacts/changes would be:

• Would change the member object definition file (add expiryEmailSet integer field)
• Add additional configuration parameter (add maxReminderEmails integer)
• Modify script(s) that handle payments receivable (specifically member payments)
• Existing databases may need to be migrated? (how does peewee handle additions to schemas?)

Sorry for the incohernet babble from me :) trying to keep the lunchbreak limited to 30 minutes today

On 29/07/2014 10:02 pm, "Brenda Moon" notifications@github.com wrote:

Make sure to only send out reminders to people who expire in 2014, not all the older members.

— Reply to this email directly or view it on GitHub https://github.com/makehackvoid/mhvdb2/issues/48#issuecomment-50466902.

[brendam]

Thanks @mbainrot.

The reminders are for people to submit the form saying they agree with the rules & code of conduct and check their contact details in order to renew their membership. Not anything to do with payments anymore.

For now I think we'll only be sending one renewal reminder, no point in chasing people about it? Or do we want to send one a week or so before and then again when it has expired? We probably do want a date field to tell us when we last emailed them, and maybe the number of reminders since they last 'signed' the agreement. Using a date field means the cron job can run each day but still be able to send out periodic reminders if we decide we want to.

I like your idea of only letting requests come from local host, although might be good if there was a way for an admin to trigger it too?

No one that has joined under the new system will expire until next year. The people who joined under the annual membership will start expiring now. Anyone who has expired in 2014 until end of June will have had the 'legacy' pay by the month membership and not changed over to the annual membership.

[mbainrot]

Ah okies, I noticed that the OP was a lot different than I expected ( I just read the top post in gmail on my phone... wooops)

I guess the concept could be reused (i.e. using a counter to "nag" x runs of the script) although with multiple time frames you would have to do it differently?

Yeah that could work, depends on how badly you want people to sign it, if you do different intervals it does make things a little complicated (could do multiple cronjobs with paramaters (i.e. http://somehost/mhvdb2/cron/nagomatic?mode=blah) or alternatively add additional logic to handle the cronjob being called more than one (a work around for no cron is to have an "include" script that gets called on every execution of a frequently hit page, then have logic inside of it so it only runs once)

I think maybe the billing standard of, 30days, 15 days, 5 days, 1 day then "expired" /could/ work but it really depends on how much you want to remind (annoy?) people and how much of an impact them not "resigning" has.

Also in the case of reminding them to "sign" the CoC, I think it would be helpful to allow them to do it from a link in the reminder email, preferably from outside (maybe email handling and if they reply "I ACCEPT" then its considered signed) because users won't sign declarations if you make it "too hard".

As for kicking off the cronjob endpoint, ideally there would just be a button in the admin area that the admin can click so they don't have to dig around in the doco/system config to be able to manually give it a "kick".

On 30 July 2014 12:26, Brenda Moon notifications@github.com wrote:

Thanks @mbainrot https://github.com/mbainrot.

The reminders are for people to submit the form saying they agree with the rules & code of conduct and check their contact details in order to renew their membership. Not anything to do with payments anymore.

For now I think we'll only be sending one renewal reminder, no point in chasing people about it? Or do we want to send one a week or so before and then again when it has expired? We probably do want a date field to tell us when we last emailed them, and maybe the number of reminders since they last 'signed' the agreement. Using a date field means the cron job can run each day but still be able to send out periodic reminders if we decide we want to.

I like your idea of only letting requests come from local host, although might be good if there was a way for an admin to trigger it too?

No one that has joined under the new system will expire until next year. The people who joined under the annual membership will start expiring now. Anyone who has expired in 2014 until end of June will have had the 'legacy' pay by the month membership and not changed over to the annual membership.

— Reply to this email directly or view it on GitHub https://github.com/makehackvoid/mhvdb2/issues/48#issuecomment-50566507.

[brendam]

Partially done in #100 - just need to work out how automate calling the renewal email endpoint from a cron job (password protected at the moment).