Tapestry

h1. Account suspension, deactivation, withdrawal -- desired behavior

h2. Clarify definitions/implications of various states participants can be in.

*Active* users are enrolled and

* were enrolled less than 4 months ago; _or_

* have submitted enough safety questionnaires recently, i.e.,

** submitted one SQ in the last 4 months; _or_

** submitted three SQs in the last 12 months.

* note: this can still result in: Jan1-enroll, Apr1-SQ, Aug1-deactivate.

*Not active* = *deactivated*.

*Deactivated* users cannot "access" their accounts.  The word "deactivation" is defined in the consent doc.  Specifically, they:

* _can_ log in

* _can_ change their email addresses

* _can (?)_ change their designated proxy, shipping address, (?)

* _cannot_ upload genetic data

* _cannot_ alter their public profiles

*Suspended* users are not included in public data releases.  The most obvious example: they do not appear in the list of public profiles.

h2. Help participants understand what to expect.

* A suspended user's home page should specify very clearly what "not in public data release" means.

* A deactivated user's home page should explain why (and how) email address etc. can still be updated; hide all stuff that can't be changed; and, if the account is not suspended, provide a link to the public profile page.

* It should be clear why/when your account was deactivated, reactivated, etc.

* Active users should receive a visual cue about "active"ness

h2. Encourage researchers/browsers to look at "active" participants

* Display "active PGP participant" indicator, in glowing green pulsating aura or whatever, on public profile pages

* Allow browsing of both "active" and "inactive" public profiles, but make "active" the default choice

h2. Rules for email contact

Currently, Jason pulls email lists out of Tapestry using whichever criteria are appropriate for the message at hand.

Tapestry also needs to know whether it's appropriate to send email to a given participant/user.  Examples:

* users deactivated for SQ-lapse should still get SQ reminders

* ...but should not(?) receive other participant communications

* users deactivated by admins should not receive SQ reminders

* deactivated users should(?) be able to send themselves password-reset emails

* withdrawn users should(?) be able to send themselves password-reset emails

h2. Use cases to review

* Auto-deactivate due to SQ lapse

* Auto-reactivate by submitting SQ

* Admin suspend+deactivate in response to "please remove my data" email, or PGP decision that participant might not have provided proper consent and review is needed

* Admin reinstate suspended/deactivated account

* Participant withdraws without requesting data removal

* Participant withdraws and requests data removal