Tapestry

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

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.

* There is always at least 1 month between "start prompting for safety questionnaire" and "deactivated".  During this time, the participant should be reminded of the conditions for, and consequences of, deactivation.

* The distinction between "private" and "public" parts of a participant's profile should be very obvious to the user.  (Perhaps all we need is a suitable note at the top of the "profile" and "my account" pages.)

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

Rationale:  Better to reward users for being active than to punish them for being inactive.  Don't come across as demanding, unappreciative, etc.

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. 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 (e.g., the list of public profiles).  Users can become suspended by:

* manual intervention by admin

* withdrawing and selecting "remove profile data"

*Withdrawn* users are deactivated _and_:

* _cannot_ change and _do not see_ their designated proxy, shipping address, ...

* _cannot_ be self-reactivated by filling in SQs etc

* _can_ be reactivated by an admin (e.g., after a forged or accidental withdrawal)

* are not necessarily suspended (only if they ask for data removal)

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