Referral Feature (Invite a Friend)

[qisforq]

Objective

Enable users to share access to their player cards with others via email invitations, allowing invited users to create an account and view the shared cards. The original user should have the ability to revoke access for invited users at any time.

Tasks

This feature has been broken down into the following tasks:

• [ ] Task 1: Frontend (Next.js) - Invite a Friend: #238
• [x] Task 2: Backend (AWS) - Invite a Friend: #239
• [x] Task 3: Database (Postgres) - Invite a Friend: #240
• [ ] Task 4: Frontend (Next.js) - Revoke Access: #241
• [ ] Task 5: Backend (AWS) - Revoke Access: #242

[qisforq]

@pm-moyanor the back-end component of this task seems pretty major - and I also am not quite sure how to implement it. That part might need to wait until user login is complete. I'd say start doing what you can with this task, and we'll assess once we hit a roadblock.

[qisforq]

@pm-moyanor for the email component of this task, we might be able to use Strapi. @HectorAgudelo and I have already implemented a few automated emails so we can work with you on that part

[HectorAgudelo]

To implement the feature you described, where users can share cards via email and manage access through your application, you'll need to integrate several components, including your Next.js frontend, AWS backend, PostgreSQL database, and potentially an email service like Strapi. Let's break down the steps to achieve this:

1. Database Schema Design

You'll need to adjust your PostgreSQL schema to manage the relationships between users, cards, and shared access. Here’s a basic schema idea:

• Users Table: Stores user details including email, password (hashed), and other relevant info.
• Cards Table: Stores details about the cards.
• Shared Cards Table: Manages which cards are shared with which users.

CREATE TABLE users (
    user_id SERIAL PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    password VARCHAR(255) NOT NULL
);

CREATE TABLE cards (
    card_id SERIAL PRIMARY KEY,
    creator_user_id INTEGER REFERENCES users(user_id),
    card_data JSONB
);

CREATE TABLE shared_cards (
    card_id INTEGER REFERENCES cards(card_id),
    recipient_user_id INTEGER REFERENCES users(user_id),
    access_granted TIMESTAMP DEFAULT NOW(),
    PRIMARY KEY (card_id, recipient_user_id)
);

2. Backend Logic with AWS and Strapi

• User Account Creation & Authentication: You'll need endpoints for user registration, login, and authentication. AWS Cognito is a good choice for handling user authentication and management.
• Sharing Cards: Create an API endpoint to insert a record in the shared_cards table and trigger an email to the recipient. For sending emails, you can use AWS Simple Email Service (SES) directly or continue with Strapi if it's already integrated for other purposes.
• Access Management: Implement endpoints to check if a logged-in user has access to a card and to delete entries from the shared_cards table if the sharer revokes access.

3. Email Handling

When a card is shared:

• Send an Email: The email should include a link that the recipient can follow to register or log in to the application. After logging in, they should be directed to the shared card.
• Handling New Accounts: If the recipient does not have an account, redirect them to a signup page. Upon account creation, associate the shared card with their new account automatically.

4. Frontend Implementation with Next.js and TypeScript

• User Interface: Create components for sharing cards, viewing shared cards, and managing access.
• Routing: Ensure that the link in the email correctly routes to the appropriate page, handling both authenticated and unauthenticated states.

5. Revoking Access

• Frontend Option: Provide a UI for users to manage who has access to their shared cards.
• Backend Handling: An API to delete a record from shared_cards when access is revoked.

6. Using AWS Effectively

• Consider using AWS Lambda for serverless API endpoints.
• Use Amazon RDS for PostgreSQL to manage your database.
• Utilize AWS SES for email sending if you decide against Strapi for this purpose.

By integrating these components, your feature should be robust and scalable. AWS offers a comprehensive set of tools that can handle authentication, database management, serverless computing, and email services, making it a suitable full-stack solution for your application.

[qisforq]

The only thing not accounted for in this diagram is if we want to add timestamps for when an invitation is sent, accepted, and revoked

[qisforq]

Backend - Hector / Paula (emails) / Louis Database - Quentin / Hector Frontend - Paula / Hector

[chef-louis]

Bug details:

• Given we have dev and prod cognito instances hooked up to the same postgres database, it is possible to have multiple users with the same email address. Also there does seem to be an unknown bug where sometimes a user's details are input into the users table twice (this bug has not yet been fully fleshed out).
• Using the email for invite lookup is not unique however we use the first entry in the lambda function below to associate the invite with a specific user's account if that email exists within our users database.

Snippet from referralInvite lambda function

if (action === 'invite') {
      // --- Invitation Creation Logic ---
      const { guest_email, card_image_id} = requestBody;
      // Check if guest_email is already a user
      const userRes = await client.query(
        'SELECT user_id FROM users WHERE email = $1;',
        [guest_email],
    );

    let inviteId;
    let emailParams;
    let userExisted = false;

    if (userRes.rows.length > 0) {
      // a user already exists with the guest_email!
      const userId = userRes.rows[0].user_id;
      userExisted = true;

      // Insert invitation with existing user as guest
      const inviteRes = await client.query(
        'INSERT INTO invitations (guest_email, card, guest, status) VALUES ($1, $2, $3, $4) RETURNING invite_id;',
        [guest_email, card_image_id, userId, 'pending'],
      );

[chef-louis]

Another bug:

• Need to handle the scenario where a user does not yet have any owned or guest cards.
• The application should not proceed with a GET request on a dashboard card endpoint (see screenshot below)

[chef-louis]

Another bug:

• User logs in with invite_id; the user gets the following modal even though the invite was in a pending state and proceeds to accepted as expected for the normal flow.