Not sure where this works, but it doesn't seem to work on my
browser. Achieved the same by forEaching through the array
returned by querySelectorAll instead.
Signed-off-by: Kevin Morris <kevr@0cost.org>
In addition, this patch brings in display for the vote decision
you cast on it. This is only viewable by the request user; your
vote is not being shared with others.
Signed-off-by: Kevin Morris <kevr@0cost.org>
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>
Somehow, many aur.al records of PackageVotes do not have a valid VoteTS
value. This migration fixes that issue by setting all null VoteTS
columns to the epoch timestamp.
Signed-off-by: Kevin Morris <kevr@0cost.org>
The previous behavior was carried over from PHP. It has been requested
that we use the true defaults when rendering the default form, making
search a bit more sensible.
Closes#269
Signed-off-by: Kevin Morris <kevr@0cost.org>
These were being produced with the db state before the flag was set,
which is not what should be done for flag notifications, as the
notification contains data about the comment and the current flagger.
Closes#292
Signed-off-by: Kevin Morris <kevr@0cost.org>
We were redirecting in some error-cases, which this commit sorts out:
- package count == 1 and package base name != package name
- was redirecting to {name} and not the only associated Package
Now, when we have a package base name that mismatches its only
package, we display the package base page. Otherwise, we redirect
to the first package's page.
Closes#282
Signed-off-by: Kevin Morris <kevr@0cost.org>
