Feature/referals #27
Feature/referals #27
Conversation
|
UHHHHHHH, what? I don't know what just happened lmao but will try a rebase. |
|
Yeah, you just need to pull the changes from main (git checkout main && git pull --rebase) and then rebase this branch on main Those commits got squashed and it caused some problems... The golden rule of rebase has its merit |
Naapperas
force-pushed
the
feature/referals
branch
from
876fd30 to
e329f52
Compare
database/migrations/2024_08_04_135449_create_student_associations_table.php
Outdated
Show resolved
Hide resolved
Naapperas
force-pushed
the
feature/referals
branch
from
e6e9446 to
159cd64
Compare
| // FIXME: This code is currently in the home page, | ||
| // where should the referral redirect to? | ||
| $referral_code = $request->input('ref'); | ||
| if ($referral_code != null) { | ||
| // XXX: Cookie is stored forever, the limit is 400 days, | ||
| // browsers seem to cap it later | ||
| Cookie::queue(Cookie::forever('link_referral', $referral_code)); | ||
| } | ||
|
|
There was a problem hiding this comment.
This stores a cookie with the referral code in it, it can be obtained with Cookie::get("link_referral").
Cookie::queue sends the cookie to the eventual response.
I researched a bit, and storing a referral code does not appear to require user permission, it is not a user's personal information. However, this cookie is not essential for the website to work.
This website (www.cookielawinfo.com/cookie-consent/) shows these bullet points as reasons to requiring permission:
- Cookies that are used for direct marketing;
- Cookies that are used to track users’ behavior across multiple websites;
- Cookies that are used to compile a profile of a user’s interests, habits and preferences;
- Third-party cookies, in other words, cookies placed on your website by someone other than the owner of the site you are visiting;
- Socially shared content, for example, if someone shares content from your website on Facebook, or tweets a link to it; and
- First-party cookies that are used for tracking.
There was a problem hiding this comment.
I might need a refresher on this but why did you choose to go with the cookie route?
There was a problem hiding this comment.
The idea was to store the referral in case the person does not register right away, once she comes back to the website we already have the referral code.
There was a problem hiding this comment.
I'll mention this in tomorrow's meeting, however, I do think if cookies are used, I should change this to the register route and use your logic.
There was a problem hiding this comment.
Hm, something doesn't sit quite right with me but I can't still figure out what it is so for now I'll just accept this solution. If something better comes up I'll open up a discussion.
Just a question: one of the requirements for this feature is associate the referrer of the link to an account it the person had a session open already or logs in after using the referral link. I'm not seeing any way to do this other than storing this information on the server. Thoughts?
There was a problem hiding this comment.
I think we store it on the server when the user registers, and just change that value if he already has an account, so, the cookies part would only be for someone who uses a referral link but does not register right away.
…ven edition they are in
Naapperas
force-pushed
the
feature/referals
branch
from
a25ce6d to
ef4dca0
Compare
|
The points in the test cases I added are not connected to those in the database. Are we supposed to keep the editions table? If so, do referral points mix with the other types of points that may exist in the future? The logic implemented isn't right yet as this part is still missing. |
Closes NIAEFEUP/enei#22.