Differences between revisions 2 and 3
Revision 2 as of 2020-251 19:05:47
Size: 1792
Editor: d50-92-76-47
Comment: (ossguy) add initial "registere" section describing different ways to handle each case
Revision 3 as of 2020-251 19:31:16
Size: 2990
Editor: d50-92-76-47
Comment: (ossguy) add extra "registere" notes giving more details on how we'll handle each case
Deletions are marked like this. Additions are marked like this.
Line 18: Line 18:

Note that the "list of payment/referral options" will include two options to get a trial account:

* enter a referral code provided by an existing JMP user, or
* wait for an administrator to manually approve the trial account request

The payment/referral step (i.e. after 1. and 4. above) should populate the appropriate "payment-plan_as_of_#{current_month}-#{jid}" key in the database, and then direct the user back to the registere step. From here the signup will occur as it would in 2. above.

We will need to add a couple trial plans to the production payment plan list, one for the initial trial month and another for the second trial month (so the rollover script knows it can drop and/or notify the trial users after the second month). This is not ideal, but we had intended for users without a payment plan key to be assumed to be trial users, whereas it is cleaner for all of the above if we make a payment plan key for trials too, so it's easier to see which JIDs are associated with active JMP numbers. However, there are ways around the limitation, such as running the rollover script each day and having it take into account the usage_start_day-#{jmp_number} value too.

As described in https://gitlab.com/ossguy/jmp-register/issues/18 we are aiming for a new series of signup steps that will let users upgrade to a paid account prior to signup, and offer other options for those who don't want to pay before signing up. Since paying at signup and paying later involve a lot of similar steps, this document will describe both of them, noting where the two flows join/separate.

registere

At the registere step of the JMP signup process (in jmp-register) we have the JID verification code and JID. So we know at this point whether the JID is verified and we can proceed accordingly. There are several possibilities here:

  1. the JID has never signed up before, nor has a payment/referral been made for this JID
  2. the JID had trouble registering (e.g. since the requested JMP number disappeared mid-signup) but a payment/referral was made already
  3. the JID is fully registered already (has a JMP number) and the payment/referral is active (unlikely to get here as dupes checked earlier)
  4. the JID is fully registered already (had a JMP number) and the payment/referral has expired (either they stopped paying or trial is over)

The above cases can be handled in a fairly straight-forward way:

  1. present the user with a list of payment/referral options - after they've entered (on the next screen) the following screen signs them up
  2. proceed directly to signing them up, using the requested JMP number (it may fail again, and then can go back and pick a new number, etc.)
  3. note that the JID is registered and show them their JMP number (we know it's them since they verified their JID) plus some extra info
  4. note when the account expired and offer the payment/referral options (similar to the first option, but with different top text)

Note that the "list of payment/referral options" will include two options to get a trial account:

  • enter a referral code provided by an existing JMP user, or
  • wait for an administrator to manually approve the trial account request

The payment/referral step (i.e. after 1. and 4. above) should populate the appropriate "payment-plan_as_of_#{current_month}-#{jid}" key in the database, and then direct the user back to the registere step. From here the signup will occur as it would in 2. above.

We will need to add a couple trial plans to the production payment plan list, one for the initial trial month and another for the second trial month (so the rollover script knows it can drop and/or notify the trial users after the second month). This is not ideal, but we had intended for users without a payment plan key to be assumed to be trial users, whereas it is cleaner for all of the above if we make a payment plan key for trials too, so it's easier to see which JIDs are associated with active JMP numbers. However, there are ways around the limitation, such as running the rollover script each day and having it take into account the usage_start_day-#{jmp_number} value too.