Skip to content
This repository was archived by the owner on Jun 9, 2022. It is now read-only.

Home

Jump to bottom
smk edited this page Sep 13, 2010 · 4 revisions

Invite 3.x Roadmap

1. Use cases
Invitations are typically used to “spread the word”, grant access to extra contents, or grant user registration only to select users. In all cases invitations are used to connect (track) inviter and invitee accounts.
Invites need to be separated by type, for example, an e-mail invitation requires a different data structure than offline invitations. A specific implementation may depend on another base type.

1.1. Email invitation
Invitations are typically used to get new users to register on a site. Users may be forced to enter a registration code.

1.1.1. Details

  • Site is open for user registrations
    • Registration code is optional and solely used to track invitations
  • Site is closed to user registrations
    • User is granted access to a site only with a registration code
    • Registration code is required

1.1.2. Details

  • User should receive a notification by e-mail to register

1.2. OG invitation
Invitations are typically used to get new or existing users into open or closed groups.

1.2.1. Details

  • Group is open
    • Invitation is optional to get more users into a group
  • Group is closed
    • Invitation is required to gain access to a group

1.2.2. Details

  • Registered users may be invited by their user name or email address
    • User should receive a notification by e-mail to /log-in/
    • After logging in, the user should be notified by a message whether to join the group (without entering a registration code)
  • Unregistered users may be invited by email address
    • User should receive a notification by e-mail to /register/
    • After registering with the site using the registration code, the user should be notified by a message whether to join the group (without entering a registration code)
    • What happens if a site is closed for registrations (requires an invitation to register) and the user receives an invitation for a group? Does it count for both?

1.3. Offline invitation
A site admin may generate a batch of registration codes for offline use. Invitations are typically used to grant access to extra contents (based on roles).

1.3.1. Details

  • Printed (books, CDs, tickets, etc.)
  • SMS (texting URL)

2. Database schema

2.1. {invite}
The left hand part, stores created registration codes.
The module currently also stores a canceled timestamp (but the cancel logic is currently borked anyway). Why can’t we just delete canceled invitations? Plus, a resent count. But, I think an automated reminder solution would be nicer in the long run. For example, based on actions (“email invite” is older than “1 week” → send reminder email)?

  • iid: Int. Internal invite id. Primary key.
  • code: Char. Registration code. Unique key.
  • type: Char. Class handling the invitation.
  • limit: Int. Number of allowed uses of the registration code, decremented on each use until zero. -1 for no limit.
  • inviter: Int. User id of inviter.
  • created: Int. Timestamp when the invitation was created.
  • expires: Int. Timestamp when the invitation expires.
  • data: Blob. Auxiliary implementation specific data to persist.

2.2. {invite_accepted}
The right hand part, stores accepted invitations.
Should we delete the original invitation and just copy any useful fields over here (ie. code, type, inviter, data minus subject/message, and remove iid)? It doesn’t make sense to store this data after a user accepted an inivtation.

  • iid: Int. Invite id. Non-unique key, since invites may be used more than once.
  • invitee: Int. User id of invitee.
  • accepted: Int. Timestamp when invitation was used.

2.3. {invite_user}
Only used by invite classes providing invitations to existing users.

  • iid: Int. Invite id. Key.
  • uid: Int. User id.

2.4. {invite_email}
Only used by invite classes delivering notifications by email and wanting to identify users by email address.

  • iid: Int. Invite id. Key.
  • email: Char. Email address the invitation has been sent to. Non-unique key, as it has been requested to send invites from multiple users to a single recipient email.

2.5. {invite_og}
Only used by invite_og to store the group. This must not be stored in auxiliary data in order to provide Views integration.

  • iid: Int. Invite id. Key.
  • gid: Int. Group id.

2.6. {invite_blocked}
Invitees may choose to opt-out from future invitations. Stores blocked recipient information (email address, mobile number). Alternatively add this to {invite_email} for email support only. This way allows us to remove the rows from the other tables, so the inviter cannot execute any follow-up actions (resend).

  • type: Char. Class handling the invitation.
  • recipient: Char. Recipient information, for example an email address or a mobile number. Unique key. Maybe we should reuse above type-specific tables

3. Observations

  • Invite API – core module
    • The API will only spawn objects of a specific type (class) and handle CRUD stuff.
    • The API at least integrates with the login form. Also the registration from?
  • Invite classes – submodules
    • Classes need to become separate modules, to be able to handle hook_user() etc. themselves.
    • Classes probably completely implement their own UIs (or maybe not…).
    • Invites may store custom information. In D7, invites should be made of fieldable entities.
  • All user and administrative overviews should be Views generated.

Further ideas

  • Get rid of overly complicated invite management screens for end users. That is,
    • remove the multi-tabbed interface
    • add support for managing (also sending?) invites from a popup using one og the available modules (Modal Frame API)
  • Synchronize invite block with page, i.e. add subject and message fields (optionaly) using a DHTML slide-out. Alternative solution: submit just e-mail, open popup allowing to enter subject and message (see above).
  • Invite campaings, i.e. instead of (or, additionally to) invites expiring, add the possibility for admins to associate sent invites with a certain campaign (subject) and also be able to expire sent invitations en block (unlike the per invitation expiry).
    Requires an additional campaign field in the database and every limit, sent counts, etc. need to be specific for a campaign. The default campaign will be automatically created on installation.
  • Introduce invite_stats database table, avoid attaching invite counts to user objects. Additionally to absolute count store extra, joined, pending, expired counts (will the latter two really be required? I’d say no, they’re only used on admin pages).
    Absolute count is often requested (for user profile output etc.), but we also need the remaining count, which should be adjustable on a per user base (it now is using the extra field).

Clone this wiki locally