Schema / Groups

[bentona]

Should Groups belong to a specific User or should they be global?

i.e. will we ever want to expose a group to multiple users?

[jbratton]

I think a Group should belong to a single Account because of opting in and all that. Maybe an Account can have multiple Users? Then an Account's Users would have access to all of the Account's Groups. In that case, an Account should probably have at least one User designated as an admin. The admin would be able to add/remove Users and designate other Account admins. Possibly also restrict Users' access to Groups/Recipients and ability to send messages based on time, quantity, etc...but that should probably all happen later.

[bentona]

Group

• belongs_to :account

Account (What about calling a recipient group a RecipientList and calling this a Group or an Organization?

• has_many :users

User (can a user belong to multiple Groups/Organizations?)

• belongs_to :group

[jbratton]

I'm rethinking how all this should be organized now. Let's say we'll have Users, Groups, Recipients, and RecipientLists. Then I think a User can create a Group/Groups which will have Recipients and RecipientLists (so Recipients will opt-in to receive messages from a Group). So a User can create multiple Groups and invite/add other Users.

So here is my guess:

User

• has_and_belongs_to_many :groups

Group

• has_and_belongs_to_many :users
• has_many :recipients
• has_many :recipient_lists
• has_many :messages

Recipient

• belongs_to :group
• belongs_to :recipient_list

RecipientList

• has_many :recipients
• belongs_to :group

Message

• belongs_to :group

[bentona]

So can Recipients be directly subscribed to a Group, not through a RecipientList?

IMO they should have to be part of a List to be subscribed, in which case I think maybe it's Group

• has_many :recipients, through: :recipient_list or something like that

[bentona]

I bet @chamblin knows.

[jbratton]

I was thinking about that too. Probably just automatically give a Group an 'All Recipients' RecipientList.

I think has_many :through is for many-to-many. So probably

Group

• has_and_belongs_to_many :users
• has_many :recipient_lists
• has_many :messages

Recipient

• belongs_to :recipient_list

RecipientList

• has_many :recipients
• belongs_to :group

[chamblin]

Can you provide a use case for User, Group, Recipient, and RecipientList?

[jbratton]

Okay, so Sue Bob is the leader of a roller derby team and sometimes needs to send them notifications of practice cancellations and maybe reminders of board meetings.

She goes to TextWorker and registers as a User. Then she creates a Group called CGRG of which she is the owner/admin. She invites another board member to register as a User and adds her as another owner of the Group, possibly as an admin.

The CGRG Group is created with a RecipientList called "All Recipients". Sue Bob adds all the league members' names & TNs (& possibly phone providers) as Recipients to the "All Recipients" RecipientList.

Then she creates a new RecipientList called "Board Members" and adds the Recipients from "All Recipients" who are CGRG board members to it.

(I hope that is what you were asking for. I don't pro computer so good.)

[chamblin]

Yeah that's what I wanted. I think I would rename Group to Account or Organization, since Group is fairly ambiguous (and partially why I asked) and I was kind of confusing it with RecipientList.

I agree with having an "everybody" mechanism, in fact, I think this would be the most typical use case, so you want it to be seamless. I feel like it would be best to not maintain a data structure of everyone for this purpose, since it will be special-cased in a lot of places anyway (adding/removing users from the account, not editable, etc). You can use single-table inheritance to define a subclass of RecipientList for which the recipients are all of those on the list's account. That's one option (easier than it sounds, you pretty much just add a type column to the recipient_lists table).

I think the hard part is Message actually. Are messages transient, or are they stored indefinitely? If they are stored indefinitely, who can see them, and what can they see? Is a Message associated with a recipient list or individual recipients? If it's a list, what happens if the list is updated in the future? Is it the User who sends a message, or the Organization, or does it matter?

[jbratton]

Okay, then let's go with Organization since I started with Account and Ben wanted Group or Organization instead of Account.

Single-table inheritance sounds good for the default/everybody RecipientList.

Initially I was thinking Messages could be saved per Organization to be reviewed or resent, but given the point of this thing - typically brief SMS reminders - I don't think it's worth the extra complexity on the developers' or users' side.

The messages will be sent from the Organization by a User - which User won't really matter. Assuming free (email SMS) and paid (Twilio) tiers, free will be sent from something like noreply@textworker.com so no replies will be allowed. Paid messages will come from a Twilio number and replies will be directed to some or all of the Organization's Users according to notification settings.

I'm still not sure about how Users and Organizations should work either. I think it would be useful to have more than one login (User?) for an Organization. It seems wrong to have to register and then create an Organization as another step, but not all Users will need their own Organization so creating one automatically doesn't seem right either. Maybe don't create an Organization automatically when registering via an invitation, but otherwise do?

[chamblin]

Ben is stupid sometimes, Group is the worst possible name. Account was way better.

A common pattern is to use invite links. An admin sends these to new-to-the-org users, then they go to a sign up page where they can optionally login with an existing account, in either case, the new account will be affiliated with the org, and not a new one. On Mar 6, 2015 5:08 PM, "Jeremy" notifications@github.com wrote:

Okay, then let's go with Organization since I started with Account and Ben wanted Group or Organization instead of Account.

Single-table inheritance sounds good for the default/everybody RecipientList.

Initially I was thinking Messages could be saved per Organization to be reviewed or resent, but given the point of this thing - typically brief SMS reminders - I don't think it's worth the extra complexity on the developers' or users' side.

The messages will be sent from the Organization by a User - which User won't really matter. Assuming free (email SMS) and paid (Twilio) tiers, free will be sent from something like noreply@textworker.com so no replies will be allowed. Paid messages will come from a Twilio number and replies will be directed to some or all of the Organization's Users according to notification settings.

I'm still not sure about how Users and Organizations should work either. I think it would be useful to have more than one login (User?) for an Organization. It seems wrong to have to register and then create an Organization as another step, but not all Users will need their own Organization so creating one automatically doesn't seem right either. Maybe don't create an Organization automatically when registering via an invitation, but otherwise do?

— Reply to this email directly or view it on GitHub https://github.com/jbratton/text-worker/issues/2#issuecomment-77664182.

[chamblin]

So yeah, basically what you said. On Mar 6, 2015 5:26 PM, "Cory Chamblin" c@chambl.in wrote:

Ben is stupid sometimes, Group is the worst possible name. Account was way better.

A common pattern is to use invite links. An admin sends these to new-to-the-org users, then they go to a sign up page where they can optionally login with an existing account, in either case, the new account will be affiliated with the org, and not a new one. On Mar 6, 2015 5:08 PM, "Jeremy" notifications@github.com wrote:

Okay, then let's go with Organization since I started with Account and Ben wanted Group or Organization instead of Account.

Single-table inheritance sounds good for the default/everybody RecipientList.

Initially I was thinking Messages could be saved per Organization to be reviewed or resent, but given the point of this thing - typically brief SMS reminders - I don't think it's worth the extra complexity on the developers' or users' side.

The messages will be sent from the Organization by a User - which User won't really matter. Assuming free (email SMS) and paid (Twilio) tiers, free will be sent from something like noreply@textworker.com so no replies will be allowed. Paid messages will come from a Twilio number and replies will be directed to some or all of the Organization's Users according to notification settings.

I'm still not sure about how Users and Organizations should work either. I think it would be useful to have more than one login (User?) for an Organization. It seems wrong to have to register and then create an Organization as another step, but not all Users will need their own Organization so creating one automatically doesn't seem right either. Maybe don't create an Organization automatically when registering via an invitation, but otherwise do?

— Reply to this email directly or view it on GitHub https://github.com/jbratton/text-worker/issues/2#issuecomment-77664182.

[jbratton]

Okay, I think I've got enough to make a decent start. I'm working on some initial models and migrations.