Data Model for Staff and Partner user information

[einari]

Purpose:
Storage location for staff users (system user) information.

Conversation:
Required fields:

• User UID: Interger (GUID, System generated)

• FirstName: Free text

• LastName: Free text

• FullName: Combination of FirstName and LastName for type aheads

• Age: Integer (Birth year)

• Sex (Options: Male, Female, Others)

• National Society (Options: pull from FDRS)

• Preferred language (Options: English, French, but flexible for the addition of more languages)

• Country / Location / place / village: (Drop down admin boundary see Define new CBS project - form (page 2) #37) Required down to admin boundary 3. If not auto fetch then manually fill location names. OR assign lowest level administrative boundary based on GPS location.

• Mobile phone number: Validation rules for Mobile phone number should be applied - and localized.

• Email address: Normal email validation.

• Role: Dropdown list based on logged in user info (Options:System Admin, Data Coordinator (can create project, read, write, and remove submitted data, delete project, remove registered user, change user role), Data Manager (can't create a project, can assign role to a user except Data Coordinator, Data Verifier (can register data collector, read and update data in its admin boundary), Data Collector (Can read read and update its own data), Data Consumer (read only user), System Admin (can't create project, can't assign a role, can read, write, change, remove data, can't remove users)

• Escalation UID: references the User UID

• Assigned project: Updated from CBS project list

• Date of activation (Activate volunteer #65): System recorded

• Status (active, deactivated)

• Registered By: (logged in user from system

• Last updated: System recorded. Revision history for tracking changes in User data, especially GPS.

Constraints:
Users are automatically stored with role "Volunteer" with no authorisation/access to other information than their own.

When users are added as in definition of CBS project #37 their status is updated to reflect their location responsibilities. Assign administrative access based on geographic responsibility #58 (#62).

Example user data

Speadsheet: https://docs.google.com/spreadsheets/d/1voDFeLxiKjbNpKXtUE4se0-lNqMTZVdA6bv0lSDIwXg/edit#gid=335422100

Confirmation:
Pull User information for new CBS project - point of contact #37

[cathinkaw]

Agreed with business owners that we use birth year instead of age. Edit: we can't base birth year after all since not all countries have the same calender. => use age + date when it was saved = current age

[cathinkaw]

Comment from discussion with Inge in Admin:

I know that a frequent use-case is Data Collectors with multiple numbers. I think User Mgmt must discuss with Anine or other RC domain expert to determine, but we in Volunteer Reporting are happy with a primary number and possible secondary numbers. Maybe #team_alerts needs to also take this into account (We are considering the option for manual SMS sending to target only primary phone or all phones for a given data collector)

[hemm1]

Some thoughts on the creation of a data collector (a user in the system with no login), should probably be a separate thing from the system/staff user signup: A data collector model has a few different fields than a staff/system user, and those two would benefit from being kept as separate entities in the system. If a data collector is "promoted" to a data verifier, that person will need to sign up as a user in the system and be assigned the data verifier role. The two separate users can of course be linked in some way in the database to show the history of the user being "promoted" to data verifier, but they should probably still be two separate entities, because of their difference.

[karolikl]

Covered by other issues, and already implemented.