You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Owned by an organization
This is really an incident
It will need a field for "created by" at some point
All objects, unless explicitly specified, should have a "created date" that is populated by the datastore.
Model: {
id: org-specific identifier (NOT NetEOC id), for paperwork
title
location (lat, long, elevation; can be POI or other already-defined datatype)
startDate (best format for search, can be reformatted at intake or extake)
endDate (best format for search, can be reformatted at intake or extake)
dutyLevel (always positive integer, will probably work as a byte)
staffNeeded (unsigned int)
staffMax (unsigned int)
attachments (file array),
}
Attachments can be one-to-many with a separate table, or a blob array column if you feel like it. As long as it's received and fetched sanely, I don't care.
Missions need to have one-to-one user relationships to determine if a user is in one (if any) of the following mission attendance states:
Eligible
Invited
Accepted
Attending / Deployed
All model items can have keys renamed to something more sane if desired
Owned by an organization
This is really an incident
It will need a field for "created by" at some point
All objects, unless explicitly specified, should have a "created date" that is populated by the datastore.
Model: {
id: org-specific identifier (NOT NetEOC id), for paperwork
title
location (lat, long, elevation; can be POI or other already-defined datatype)
startDate (best format for search, can be reformatted at intake or extake)
endDate (best format for search, can be reformatted at intake or extake)
dutyLevel (always positive integer, will probably work as a byte)
staffNeeded (unsigned int)
staffMax (unsigned int)
attachments (file array),
}
Attachments can be one-to-many with a separate table, or a blob array column if you feel like it. As long as it's received and fetched sanely, I don't care.
Missions need to have one-to-one user relationships to determine if a user is in one (if any) of the following mission attendance states:
Eligible
Invited
Accepted
Attending / Deployed
All model items can have keys renamed to something more sane if desired