Differences between revisions 8 and 9
Revision 8 as of 2020-257 16:29:00
Size: 4979
Editor: d50-92-76-47
Comment: (ossguy) clarify where the options1 step resides (after register3)
Revision 9 as of 2022-117 19:35:18
Size: 0
Editor: Singpolyma
Comment: Out of date, implementation long since complete and different
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
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.

== options1 ==

At the options1 step of the JMP signup process (in jmp-register, immediately after register3) 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:

# the JID has never signed up before, nor has a payment/referral been made for this JID
# the JID had trouble registering (e.g. since the requested JMP number disappeared mid-signup) but a payment/referral was made already
# the JID is fully registered already (has a JMP number) and the payment/referral is active (unlikely to get here as dupes checked earlier)
# 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 JID is registered for an active trial account

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

# present the user with a list of payment/referral options - after they've entered (on the next screen) the following screen signs them up
# 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.)
# 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
# note when the account expired and offer the payment/referral options (similar to the first option, but with different top text)
# present the user with a list of payment options (similar to 1., but the text of the final step should be different)

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 options1 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.

== Upgrading ==

To upgrade from a trial account to a paid JMP account, we can reuse much of the "options1" process. In fact, it is probably easiest if we just have the JMP account bot create a valid session ID and verification code when a JMP user wants to upgrade, and give them the link so they can then be sent directly to the options1 step (and have it handled roughly per step 5. above).

We'll have to update the https://jmp.chat/sp1a/upgrade1/ to note this (along with some other text) but this is definitely the right way to do it. Also, this solves the problem of an arbitrary individual being able to send a payment for a JMP account knowing only the JMP number or JID (but without verifying they control either) - that's fine for the old case (where you couldn't tell whether the account was paid or not anyway), but that did allow a person to double-pay, and it definitely doesn't work for the above new situation where the signup/upgrade system is aware of whether you've paid already (since we don't want to leak that information to someone who is not the JMP user).

== Implementation notes ==

There are a few specific items we should be careful to implement wisely and/or especially correctly:

* In the administrator panel for waiting/pending trial users, ensure that the administrator can configure different blocking parameters and/or see a summary of recent blocking results (correspondingly, the step after options1 to "wait for administrator approval" needs to read these parameters instead of hard-coding).
* The JMP account bot should be able to understand and properly provide status to the user for any of the above 5 steps (and possibly others), especially the state where the user has paid but they don't have a JMP number assigned to them yet.