In preparation for allowing TUs to change their votes on proposals,
we need a way to track what users vote for.
Without this, the vote decisions are stored within the related
TU_VoteInfo record, decoupled from the user who made the vote.
That being the case meant we cannot actually change a vote, because
we can't figure out what TU_VoteInfo decision columns to decrement
when the vote has changed.
You may be wondering why we aren't removing the decision columns out
of TU_VoteInfo with the advent of this new column. The reason being:
previous votes are all calculated off of the TU_VoteInfo columns, so
without a manual DB rework, relocating them to the user-related vote
records would break outcomes of old proposals. So, the plan is:
we'll solely use this column for votes from this point on to track
what decision a user made internally, which will open up TUs changing
their decision.
In addition, this migration resets all running proposals:
- all votes are deleted
- time is reset to Start when migration is run
This was necessary to put running proposals into a state that can
take advantage of the new revote system.
Signed-off-by: Kevin Morris <kevr@0cost.org>
