feature: direct referral system

[AvilaAndre]

• Implement HashId to encode and decode referrals
• Store referral code in the cookies on website visit
• Create ReferralController ReferralService for giving points
  • Have a way to differentiate different user types
  • Create points field in the database
• Implement functionality to give points to the users

Referrals are only applied after the user buys a ticket.

[limwa]

Preview available at: https://enei-pr33.limwa.pt/
Deploy previews are kept up-to-date with the latest commits.

[AvilaAndre]

@limwa should I merge ParticipantProfile and ParticipantInfo?

Also, the referred_by_promoter_id field just shows which users were referred by a promoter, do we need store who referred in the first place too? For example, if participantA used participantB's referral code and participantBs was referred by a promoterC, then the referred_by_promoter_id field on participantA will be the id of promoterC.

I could have a field referred_by which stores the id of the user who referred, whether it is a participant or a promoter (it can double as a check for if the user used a referral or not). However, for attributing points, I need the referred_by_promoter_id field as well to be able to avoid having to check who referred who recursively.

[limwa]

@limwa should I merge ParticipantProfile and ParticipantInfo?

Yes, but the migrations need to be 100% correct. We're dealing with a production system and we need to ensure that everything is perfect.

Also, the referred_by_promoter_id field just shows which users were referred by a promoter, do we need store who referred in the first place too? For example, if participantA used participantB's referral code and participantBs was referred by a promoterC, then the referred_by_promoter_id field on participantA will be the id of promoterC.

Yes, the alternative would be to have recursive queries, which I'm not a big fan of 😅

I could have a field referred_by which stores the id of the user who referred, whether it is a participant or a promoter (it can double as a check for if the user used a referral or not). However, for attributing points, I need the referred_by_promoter_id field as well to be able to avoid having to check who referred who recursively.

Yeah, exactly!

[AvilaAndre]

Yes, but the migrations need to be 100% correct. We're dealing with a production system and we need to ensure that everything is perfect.

The good news is that the participant_info table does not have anything that participant_profile is missing. The bad news is that sqlite3 does not support dropping foreign keys, so, renaming the table and columns is proving to be a complicated task.

[limwa]

You can try on 1 migration to drop the foreign key constraint and on the next add it back
Alternatively, since the PR hasn't been merged yet and the models have the exact same information, you can simply use the other model and delete the old one, no migration needed