Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retention policy #247

Merged
merged 13 commits into from
Apr 21, 2021
Merged

Retention policy #247

merged 13 commits into from
Apr 21, 2021

Conversation

SamWinterhalder
Copy link
Contributor

@SamWinterhalder SamWinterhalder commented Mar 23, 2021

Check if a Sand membership fee is due on each member.

  • send an email upon failed payment

If Sand membership fee not yet paid (new member):

  • force payment process on login
  • send a reminder email after 24 hours
  • send a reminder email after 72 hours
  • delete account and send email to notify after 120 hours.

Fixes #77

(Following is no longer PGL)
If Sand membership fee is due soon, send member reminders to pay. Relates to #128

If Sand membership fee is not paid after six months:

  • update their membership termination date
  • the author on posts published by that member must be changed to "Anonymous [animal]"
  • their member profile must be set to private.

@SamWinterhalder SamWinterhalder force-pushed the ret-policy branch 2 times, most recently from e9d22cc to 3de65ec Compare March 29, 2021 00:25
@SamWinterhalder
Copy link
Contributor Author

@jamesgeddes I have just started thinking about/implementing the first remind email and it would not work to send all the emails at 9am every day for all users who do not have the has_paid_sand permission. This perm is granted afer successful payment and that could be a few minutes after the member has registered.

A common scenario would be if a member registers at 08:59, starts their payment but when they finish it is already 09:01. This would mean that the user does not have the has_paid_sand perm as their payment has not technically gone through, but it is not because it has failed.

For this reason I am starting to reconsider the 'only having has_paid_sand permission' but am not yet sure about what to do.
I think one way to do it (whilst keeping only the one permission) is to look at the datetime of when the user signed up to see if it has only been a few minutes or if their payment is taking some time.

@jamesgeddes
Copy link
Contributor

That's a fair point. Perhaps we should go with the 24 hours after the individual registers.

@SamWinterhalder
Copy link
Contributor Author

@jamesgeddes I think celery beat is the best option for scheduling the recurring task of sending the emails.

@SamWinterhalder
Copy link
Contributor Author

SamWinterhalder commented Apr 10, 2021

Another option is to schedule a check, upon membership creation, to find if the member has paid, if they still have not, send an email and schedule the next check. This would be easier than using celery-beat and creating periodic tasks which checks through all members.

EDIT:
This would still use celery-beat but it would mean that we would not need to check through all users for the has_paid_sand permission every x hours to send the emails.

EDIT 2:
No need for celery-beat as the async scheduling of non-recurring tasks can be done using celery .apply_async().

@SamWinterhalder
Copy link
Contributor Author

SamWinterhalder commented Apr 11, 2021

NOTE: When running celery, --pool=solo is a necessary command line arguement for Windows in order to use the scheduled tasks (have not yet tested on Linux).

Relates to #246

EDIT:
Windows is no longer supported by Celery.
https://docs.celeryproject.org/en/stable/faq.html#does-celery-support-windows

@SamWinterhalder
Copy link
Contributor Author

NOTE FOR WINDOWS: There needs to be another worker process/thread available to call a task from within another task. This may cause issues when running on Windows as the only way I could get my version to work was by limitting workers using --pool=solo.

@SamWinterhalder
Copy link
Contributor Author

@jamesgeddes Please can we either meet up at some point or can I have a list of exactly what needs to be done on member deletion (to comply with GDPR, to keep payments anonymous, etc)?

@jamesgeddes
Copy link
Contributor

@SamWinterhalder I am free in an hour, let's jump into the GZ dev channel at 1730

@jamesgeddes
Copy link
Contributor

I will take a look at the CircleCI config to ensure that it is pulling in the correct env

@jamesgeddes
Copy link
Contributor

logged #271

@SamWinterhalder
Copy link
Contributor Author

I am not sure the best conditions to use, to determine whether to force the member into payment.

One scenario already mentioned is a payment that might take an hour, this will not be payed but the user has done all they can so it might be incorrect to just use whether they have paid or not.

@jamesgeddes
Copy link
Contributor

Do we get a "payment processing" from stripe?

@SamWinterhalder
Copy link
Contributor Author

Should do, I am not sure how I am going to be able to differentiate between Sand payment and any other payments for stripe_customer_id. Need to find a way of making sure I am looking at the correct payment but shall look into this later today or Saturday.

@SamWinterhalder
Copy link
Contributor Author

SamWinterhalder commented Apr 17, 2021

I think that instead of making more requests than we need to, we can store the most recent event of the payment in the database (not every event but the significant ones that will help with knowing what is happening with the members payment).

This would work best as a field in the membership model (payment_status).

EDIT:
membership is not created until payment process is started so if membership does not exist then payment has definitely not begun (user has not started checkout)

@Freshrojek
Copy link
Contributor

The CircleCI error is stating that nothing has been written to the console in 10 mins so it timed out. Check here.

@SamWinterhalder
Copy link
Contributor Author

The CircleCI error is stating that nothing has been written to the console in 10 mins so it timed out. Check here.

I think this is because we do not have Celery or RabbitMQ installed on ther CircleCI instance. (I have got @jamesgeddes working on this 😄)

@jamesgeddes
Copy link
Contributor

It does occur to me that we don't actually have any tests that ask circle ci to run anything in rabbit. I'm not saying that we should not have the right testing environment but that does seem kind of odd.

@SamWinterhalder
Copy link
Contributor Author

It does occur to me that we don't actually have any tests that ask circle ci to run anything in rabbit. I'm not saying that we should not have the right testing environment but that does seem kind of odd.

I think we need circlieci to be able to know what rabbitmq is first 😄

@Freshrojek
Copy link
Contributor

when running manage.py test I get an assertion error in test_stripe_webhooks.py on line 122 "self.assertEqual(1, payments.count())" where is says 1!=0, and CircleCi says that manage.py test is what's causing an issue so could be something to do with that?

@Freshrojek
Copy link
Contributor

and when changing 1 to 0 the test works

@SamWinterhalder
Copy link
Contributor Author

when running manage.py test I get an assertion error in test_stripe_webhooks.py on line 122 "self.assertEqual(1, payments.count())" where is says 1!=0, and CircleCi says that manage.py test is

Yeh it is not behaving, I have somehow broken something to do with Stripe somewhere becuase I keep getting 500's back from every Stripe event.

@Freshrojek
Copy link
Contributor

sounds promising!

@SamWinterhalder
Copy link
Contributor Author

Fixes #271

@SamWinterhalder SamWinterhalder linked an issue Apr 20, 2021 that may be closed by this pull request
@jamesgeddes
Copy link
Contributor

@SamWinterhalder convert this and add me as a reviewer so I can approve 😄

@SamWinterhalder SamWinterhalder marked this pull request as ready for review April 20, 2021 21:04
@SamWinterhalder SamWinterhalder requested a review from a team as a code owner April 20, 2021 21:04
Copy link
Contributor

@jamesgeddes jamesgeddes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job 👍

@Freshrojek
Copy link
Contributor

Well done, big effort!

@SamWinterhalder SamWinterhalder merged commit 42d3abc into master Apr 21, 2021
@SamWinterhalder SamWinterhalder deleted the ret-policy branch April 21, 2021 09:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update CircleCI config Retention policy
3 participants