Wireframe: answer-change

This is where a change to an answer to a question is confirmed. It seems pretty important to have this confirmation page, as changing an answer to a property question is significant. Changing an answer to a relational question is not so significant, and needs to be treated differently.

The enquirer is considering a change already drafted to one of their answers. They see the previous and the proposed versions, together with notes about the consequences of going ahead with the change.

• my answer

• confirm → my answer
• back out of the change → my answer
• nowhere else, as this might confuse navigation

There are a couple of dependencies resulting in what is displayed.

• If changing this answer negates an invitation to a candidate, because the candidate required the existing answer, then that needs to be pointed out.
• If there are any questions dependent on the current answer, they will be removed.
• If the answer is now being refused, obviously no new value will be shown.

In each case, the appropriate information would need to be fetched and displayed.

• Explanation of what happens when an answer is changed.
• Key variables: QID
• The question title QTitle from MyLingo
• My previous answer MyAVal
• My proposed answer MyAVNew

• An optional explanation of the change, for property questions MyPropChNote
• Store the new answer → DEV
• A space to indicate that from now onwards the answer is refused

If the answer change is confirmed:

• cancel invitations where the candidate asked that question
• communicate to people who have agreed contact, so they can break contact if desired
• store new answer, date, time, and change notes in: DEV, LSV; change HUB

If the answer is withdrawn:

• change answer status to withdrawn in DEV, LSV, change HUB
• cancel invitations where the candidate asked that question

Should we have this page at all for relational questions? Probably not?