System stores Users

[ztbrown]

Description

Users can register and login to the system. We should probably use Devise to manage sign-in/register.

Properties

• name String [Optional]
• email String [Required, Unique]
• encrypted_password String [Required]
• phone_number String [Required]

[ztbrown]

We'll want to talk about how we deal with branch, MOS and years served. These should probably exist as their own models.

[BDS1400]

What do you guys think is the best way to deal with brainstorming and recording the fields we will need for the user, and later stories, mapping, etc.? A page on the wiki could work.

Ryan mentioned during our last meeting that he doesn't connect with reservist's the same way he does with someone who enlisted. Do we include enlisted/reservist as a user field? What do our other vets think? @dswingle @baroldgene

[lightmedium]

@BDS1400 @ztbrown @baroldgene Yeah, we should at least have models for MOS, Branch, and Theater, which should be properties (probably a belongs_to relationship) on a Tour model. The User model has_many Tours. It seems to me that dates served should be represented by a start date and an end date on the Tour model. These are the things that I want to describe visually with Gliffy. I'm working on these things now, I'll be creating some pull requests pretty soon.

[lightmedium]

@ztbrown How about Devise and OmniAuth?

[baroldgene]

@lightmedium I'm not sure about the data model you describe. I feel like it paints us into a corner as far as attributes for a user go and we're only going to keep finding more and more things to track. I've done well in the past using an Attribute table that belongs_to a user and has a "type" field and a "data" field. This way the attributes we record for a user can be entirely dynamic.

I'm not sure about the searching with this model, but in the past I've used things like elasticsearch to speed this up where performance became a problem.

[ztbrown]

@lightmedium Devise + OmniAuth is cool with me.

I'm interested in chatting with both @lightmedium and @baroldgene about data design. Because I'm sure I have a third idea of how the data should be architected. So, here goes:

User has_many Branches. Branches have a type enumeration (Army, Air Force, Navy, Marines, etc.). User has_many MOS through Branches.

User has_many Tours. Tours have a start_date:datetime and end_date:datetime. User has_many Theaters through Tours.

I think this is pretty flexible. From what I could tell from a few Google searches, some veterans served in multiple branches, some had multiple MOSs in a single branch, and often they served multiple tours in multiple theaters.

This is just my take on how data could be structured. I'd love to see a repo in this organization for UML. I've never worked collaboratively on UML and think it would be fun for us to propose some PRs and chat about the pros/cons of different design approaches.

[lightmedium]

@baroldgene @ztbrown I'm not a fan of attributes tables. Rails Migrations make it so easy to modify our data schema that the abstraction isn't worth everything that is sacrificed. If we need that kind of flexibility, I'd rather just use a document db like Mongo.

I agree with everything you said, Zack, but this is why I'd put Branch under Tour: My conversations with Doug during Startup Weekend led me to believe that the "Tour" represented the highest level unit of experience in the service. Chronologically, you join a branch Before you are sent on a Tour, but from the perspective of connecting veterans based on their experience, the Tour is the key. During a person's military career, whether they are deployed to a combat zone or not, the most impactful experiences consist of a series of tours. You complete a tour for a branch of the military, for a period of time, in one theater, in one or more locations, doing one MOS. So, a User has_many Tours, like you said, but the User has_many Branches through Tours and a user has_many MOSes through Tours.

The truth is, we're probably both wrong, we just need a starting point, and we need to evolve as our understanding of the domain we're modeling expands.

[baroldgene]

I can pretty confidently say that branch should not belong_to a tour. We're trying to bend the data model to fit our program, not accurately modeling real-world data. If anything you do a tour FOR a branch. The multiple-branch (for a vet) situation is an extreme minority of users.

We may very well end up weighing a tour higher for the purposes of matching users up, but that is business logic and should not influence how the data is modeled.

[ztbrown]

Looks like we've got some disagreement, and that's ok. Here were the assumptions I was working off:

• A Veteran will have belonged to one or more Branch
• A Veteran will have had one or more MOS under that Branch.
• Example: one user may have been a radio operator in the Navy and then a radio operator in the Army
• Tours represent a period of time served in a Theater
• A single tour may have multiple Theaters associated with it
• A veteran may have never served a Tour, and would thus have no Tours and no Theaters associated with him/her

@baroldgene @dswingle, could you validate these assumptions?

I saw the User model looking like this:

class User < ActiveRecord::Base 
  #devise stuff here
  attr_accessible :first_name, :last_name, :email, :phone_number, :password, :password_confirmation

  has_many: :branches
  has_many: :occupations, through: :branches

  has_many: :tours
  has_many: :theaters, through: :tours
end

Then, when we're doing queries for the phone calls, we can start with:

User.joins(:occupations, :branches).where(:occupations => {type: MosTypes::RADIO_OPERATOR}, :branches => {type: BranchTypes::NAVY}).uniq

to get someone in my branch with my MOS. That query can easily be modified to get either branch or MOS similarity.

[baroldgene]

A Veteran will have belonged to one or more Branch

True.

A Veteran will have had one or more MOS under that Branch. ..* Example: one user may have been a radio operator in the Navy and then a radio operator in the Army

This is true. Not only this, but MOSes are entirely different between branches. I was a 2844 in the Marine Corps, but no such MOS exists in the army.

Tours represent a period of time served in a Theater

True

A single tour may have multiple Theaters associated with it

I don't believe this to be true.

A veteran may have never served a Tour, and would thus have no Tours and no Theaters associated with him/her

True

[ztbrown]

OK, so this definitely doesn't work:

  has_many: :tours
  has_many: :theaters, through: :tours

[baroldgene]

Why not?

[ztbrown]

Because a single Tour may not have multiple Theaters, but a single Theater may have multiple Tours.

It may need to look something more like this (though I'm not sure this is right):

  has_many: :theaters
  has_many: :tours, through: :theaters

So, a User could have been in Iraq for two tours and Afghanistan for two tours.

[lightmedium]

I think this is more accurate (what you wrote the first time) - since Tour:Theater is a 1:1 relationship:

  has_many: :tours
  has_many: :theaters, through: :tours

[ztbrown]

Yep. Whoops. I don't know how I missed that. Good call.

[baroldgene]

I want to verify that Tour:Theater is always a 1:1 relationship. I am pretty sure I'm just curious if there are any random edge cases I'm unaware of.

[lightmedium]

Good call. Do you guys have any other thoughts about what we want to track about our veterans' and their service?

• First Name
• Last Name
• Screen Name
• Branches
• Civilian Occupation
• Current Location
• Watches (recurring dates/times that the user is willing to take calls)
• Tours
  • Start Date
  • End Date
  • Branch (We could create an Enlistment model to store Branch and a date range, then figure out the branch that a tour is associated with programatically?)
  • Theater
  • Occupation

[lightmedium]

We'll need to figure out how we want to handle anonymity. For the sake of flexibility, we should have per-object share settings, but we might also want a user-level preference that enables them to say "I want to be 100% anonymous by default."

[lightmedium]

Just thought of something. Devise gives us a regex to validate emails used for auth – can we require emails from a set of military domains in order to validate veteran status?

[BDS1400]

I think we need add Reservist: true|false under tours. The other consideration is how does the national guard play in? Is the reserve the national guard? I'm not sure.

We will need to store and validate the user's phone number before we send calls to it. I would store this separately from the user info because potentially someone may want multiple phone numbers. For example, receive watch calls on their mobile # during the work day and home # at night.

[baroldgene]

The regex to verify e-mails most likely won't work. @usmc.mil addresses are only given to those that need them (at least in the reserves). You will definitely exclude people this way, the question is how many. Also, you lose access to any such e-mail when you get out.

I don't think the is_reservist would be an attribute of a tour. It would be an attribute of a branch. And the National Guard == Army Reserves as far as I know. I believe the Air National Guard == Air Force Reserves as well. We should again verify that those are 100% true though.