index correspondent: comes from: examine; move-to-contact; invitations; their-answer; answer (sometimes)

Co:?; Enq:?; Loc:?; Q:?; ETy:?; iVis:?;

Correspondent number [CoNo]

For enquiry: [EnqName]

Of type: [ETypeLabel]

Date they registered: [CoRegDate]

Date listed as correspondent: [CoListDate] (appearing on examine list or inviting)

Contact status on both sides:

(if they are inviting) consider invitation

questions I askedtheir short answer
[QTitle][CoAns]
[QTitle][CoAns]
[QTitle][CoAns]
[QTitle][CoAns]
questions they askedmy short answer
[QTitle][MyAns]
[QTitle][MyAns]
[QTitle][MyAns]

Optionally, what I want to call this correspondent: (never shared with anyone)

Optionally, what I want them to call me, if contacted: (only shared when contact established)

(if so) This correspondent also corresponds for my enquiry/enqiries:

move to establishing contact (if contact not yet established and not blocked by them)

(else if already invited by me)

(if not established and not already blocked)

(if blocked)


look at other correspondents instead

show info

Diagnostics: ?

Information required and sources

Key: {CoNo};


Pre-processing


What the user is doing

My correspondents are those who:

  1. I have found through my enquiries
  2. have invited me from their enquiries

Someone does not become my correspondent just through my appearing on their list. I may be one of 9 to them, but they may be one of a thousand to me. It is when they invite me that I become special.


Post-processing


Information output


Issues

Listing dates

The date of being listed as a correspondent on this enquiry is not necessarily the date of being listed as a correspondent, because another listing may have previously happened. Need to keep track of listing dates separately.

If one Enquirer Enquiry fits two or more Enquiries from the same Respondent

Simply aggregate the answers. The point here is that there is no need to distinguish different correspondent enquiries: the point is to find fit.