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

Enquiry type: [ETypeLabel]

List of correspondents for [EnqName]

The correspondents are ordered by rank or number of desirables, or by geographical distance

Diagnostics: ?

Information required and sources

Key: {EnqID}; not CoNo and QID which are multiple

• {ETypeLabel} ← {ETypeID}
• {EnqName}
• For each in list of {CoNo}:
• {ContactB};
• {CoName}; {CoNick} (if contacted)
• {CoStatus}; {CoMyStatus}
• {CoEDistance}
• For each in list of QID
• {QTitle}
• {CoAns}

---

Pre-processing

• redo the enquiry processing to check on momentary correspondents and gather relevant info as above

---

What the user is doing

Comparing the different correspondents, as a first step to choosing one to look at in more detail.

---

Post-processing

• none

---

Information output

• CoNo to focus

---

Notes

People can prevent contact by:

• blocking the person
• deactivating the enquiry
• Changing their wants or answers so they no longer match

Breaking contact has its own process

Numbering of correspondents where contact is not established

Looks like a good idea to have fixed numbers for correspondents, to allow recognition across different enquiries. Propose: sequential numbering of correspondents as they come up in one's list, or as they issue invitations if they have not appeared in one's own list. This means that RegenCHOICE has to keep a personal list of correspondent numbers, tied to system IDs.

A nice consequence of this is that two users cannot cross-reference their correspondent IDs to find anything about a particular correspondent pre-contact.

When two enquiries from same correspondent match one from enquirer

This is really annoying, because it is plausible. On this page, not really a problem, as the same correspondent can be listed more than once.