Request for feedback on invite code feature

[ayajaff]

Hey @elijh and @azul!

We're Aya and Anke from the Rails Girls Summer of Code and we've been working on the invite code feature for the past few weeks. We wanted to let you know what we've done so far and see if you're happy with the invite code feature as it is. We don't expect you to merge our changes yet because one important feature is still missing (as discussed with Azul).

Here is a list of the changes we made:

• added invite code field to the sign-up form
• added validation for invite code
• added rake tasks so the admins can generate invite codes
• using the coupon code gem to generate the invite codes

What's missing:

• allow provider to turn the invite code on and off (this feature is crucial before our code is merged as discussed with Azul)
• separating srp from our code so we don't have to make changes to srp
• add some nice-to-have features e.g. use multi-use invite codes, expiration dates for invite code, allowing admins to change code from the web interface

Here's a link to our github issues where we track what we're working on:
https://github.com/Alster-Hamburgers/leap_web/issues

Please let us know how you like it and if you have any feedback. We still have a few more weeks left to work on the missing features and implement changes.

Best,
Anke and Aya

[azul]

Yay! ✨

I'm really busy right now ⌚ ... but i'll make sure to go through it in the coming days. Happy to see the build is green 💚.

[ayajaff]

Okay! If you like we can split it up into smaller chunks? Maybe that's better? :)

[azul]

Hey @ayajaff,
Usually smaller chunks are better. Yes. If you find things you can easily isolate from the pull request that still make sense it might be a good idea to separate them out and deal with them before hand.

If that's difficult then we can go through the whole pull request at once.
Cheers,
Azul

[azul]

What IDE is this for?

Maybe this would better fit into a global gitignore on your machine?
If not it might be a minimal pull request on it's own as it's independent of the rest.

[ankonym]

It's for RubyMine.
True, we actual did add that to our global gitignore, so it doesn't really need to be here.
(Now we just have to find out how to remove it. :) )

[azul]

I bet there are a lot of different ways.
First you might need to know which commit changed it...
Then you can use an interactive rebase and edit the commit in question. Or you could add a new commit and then squash it with the old commit in an interactive rebase.

git log  -1 .gitignore
git rebase -i

[kaeff]

We updated the pull request:

• Removed the RubyMine-specific ignores as @azul pointed out
• made the history a little easier to process by squashing related commits

Sorry for the slight confusion of the broken build, I accidentally missed a commit.

[azul]

I had another look at the issue where find_by_invite_code(nil) returning the first record in the table. Turns out this was a couchrest model bug. Luckily it's fixed in the new version. #195 will fix this for leap_web.
So we can safely rely on this to not return an invite code even if the user somehow manages to make user.invite_code return nil. 😅

[azul]

As I already said in Hamburg, I am very happy with the approach. You are aware of the missing parts yourself. So I have nothing to add in terms of the big picture. This leaves different possibility for using the counter. We can decide upon that later. 🍹

Code also looks good to me. I will add a bunch of comments and questions about small things I noticed. They are meant as style suggestions. I'm not sure i follow them myself all the time 😉

[azul]

interesting. are we using this anywhere?

[ankonym]

Not anymore - we briefly played with the idea to use the id as the invite code but it didn't seem practical (for starters, printed out and then copied down, it wasn't as user-friendly as the coupon code we generate now).
Should we remove it?

[azul]

Yes. Please remove it. It's a quick change and it takes much longer to figure out why this is there later on.

[kaeff]

As of 3c13802, we saw sign up working with invite codes as well as without. We will apply more testing locally as well as running within the platform tomorrow. Since this is the last week of RGSoC for @ayajaff, we would like to get towards a merge soon given there are no concerns..

@azul Please let us if anything's missing functionally in order to integrate
@varac Let us know when you feel ready for the platform session :)

[azul]

@ayajaff @ankonym @kaeff @varac, this looks good to me. 👍
The only issue we still need to clearify is if we want to store the invite code used or not. But we can do that post merge.
Is this ready to be merged from your point of view?

[elijh]

I also have been sick lately, so I never got around to reading this PR. I am happy it is merged, although I would like to suggest some changes for the future:

(1) Remove the coupon gem and instead generate codes with something like this:

Base32.encode(SecureRandom.random_bytes).downcase[0..7]

or

Base64.encode64(SecureRandom.random_bytes).downcase.gsub(/[0oi1\+_\/]/,'')[0..7]

The first requires the gem base32, but the latter uses only built-in libraries (require 'base64' and require 'securerandom'). This seems better than depending on the coupon gem, especially since we don't use any of the "features" of the coupon gem.

(2) instead of making InviteCode have a "count" property, how about a "uses_remaining" property? This way, in the future, to support invite codes with multiple uses we just change the initial value to be something greater than 1.

(3) It has been useful for riseup.net to store the invite code that is used by a user, in order to shut down spammers. For privacy reasons, however, LEAP probably doesn't want to force providers to keep this information around permanently. How about a rake task that removes the invite_code from all users that were created longer than 3 months ago?

[ankonym]

@elijh Thank you for your comments!

Re: 1 - Understood about not depending on another gem. One thing I liked about the coupon code gem was the code format, which is easier to read and copy off paper for a human than a non-formatted string. This may be helpful should any providers print out codes and hand them off to new users?

Re: 2 - Yes, we were wondering about the best way to implement this.
The possible options we came up with were to either introduce an additional "maximum_uses" property and then count up until count equals maximum uses (this way admins could keep track of how often a certain code has already been used - not sure that use case is something that would come up), or to have a "uses left" property and count down as you described.
Also, the question came up if this could create issues for providers who already generated invite codes with the current system because all those codes would then become invalid - what would be the best way of avoiding problems there?

[kaeff]

On 1 Oct 2015, at 16:05, ankonym notifications@github.com wrote:

Also, the question came up if this could create issues for providers who already generated invite codes with the current system because all those codes would then become invalid - what would be the best way of avoiding problems there?

I’d say that if we implement this in the near future, is safe enough to assume that only pixelated’s wazokazi provider will have invite codes stored that use the old way

[elijh]

One thing I liked about the coupon code gem was the code format, which is easier to read and copy off paper for a human than a non-formatted string. This may be helpful should any providers print out codes and hand them off to new users?

Base64.encode64(SecureRandom.random_bytes).downcase.gsub(/[0oil1+_/]/,'')[0..7].scan(/..../).join('-')

=> "myk9-qjdb"

We may want the length configurable in the future, but I think anything longer than 8 characters is unnecessary.

[elijh]

The possible options we came up with were to either introduce an additional "maximum_uses" property and then count up until count equals maximum uses (this way admins could keep track of how often a certain code has already been used - not sure that use case is something that would come up)

Yes, I think that is better than uses_remaining. I retract what I said.

[ankonym]

Great, I implemented the maximum uses today (here). I'll send a pull request on Monday and then look at the other tasks.