Candidate information structure

See pages: show-results; candidate;

The LSV holds an array of these, indexed by CanNum.

CanNum is stored and transmitted as a Key Variable, but CanNum is also stored in the structure in localStorage, as well as being used to create the name for that local storage. So there is some duplication, hopefully helpful rather than confusing.

• CanNum: the candidate's number for current user
• CanRegDate: date that the candidate registered on the system
• ContactStatus: contact status for that candidate for me (see below)
• ContactStatus: my contact status with that candidate (see below)
• for each for each Q asked by me and used in correspondence
• an answer (see their answer):

Candidate table on local server

• my LUID
• my candidate number
• my status for that candidate
• their GUID

When I am asking about a candidate, I send my candidate number (and my LUID) local server looks up their GUID to send to hub. When information comes via hub, local server translates to my candidate number.

Contact status

Before contact, contact status could be:

• UNKNOWN
• UNINVITED
• BLOCKED
• INVITEDBYME
• INVITINGME

After contact agreed, ContactStatus could be:

• CONNECTED
• THEYBREAK
• IBREAK
• BROKEN