Successive feedback from the same team does not unconfirm prior submissions

[philipbelesky]

Currently it seems that latter feedback submissions from the same team on a panel don't un-confirm the earlier ones. So people who are doing the things #812 is trying to prevent end up having a series of submissions that all affect the scores of the panel.

Haven't had time to dig into the exact cause but I assume its related to some of the changes made in #708. If its not we should make sure to check whether there is a similar regression for adj submissions.

[philipbelesky]

Oh wait, it turns out it never worked like this so there's no link to #708. Sorry!

This is worth considering as a behaviour, perhaps in conjunction with #812.

If this behaviour isn't implemented it seems like there is a need for a view that highlights these 'duplicates' since they seem somewhat inevitable at larger tournaments and each feedback ends up affecting adj scores and then requires cleaning to correct. I'd rather avoid doing that in favour of implementing this change as a self-correcting behaviour.

[czlee]

Are we talking about feedback from the same team on the same adjudicator, or from the same team on different adjudicators on the same panel? The former's definitely meant to unconfirm previous ones and it's been there from the beginning, so if it doesn't work that's a regression.

The latter's indeed never been the behavior, and is more complicated than it sounds. Since some tournaments expect to receive feedback on all adjudicators, not just the orallist, this behavior needs to be sensitive to the "feedback paths" preference. Furthermore, some teams might do this deliberately under the mistaken belief that they are allowed to, so if we do implement this and it's an automatic unconfirming of previous feedback, we should probably have suitable messages to make teams aware of their error.

[philipbelesky]

This is regarding feedback from the same team on different adjudicators on the same panel. Agree that this needs to respect the feedback paths preference, and I've already added messages to the page that explains the expected quantity of feedback given the tournament's path setting.

[czlee]

Okay. To give some idea, the current unconfirming is done at the model level because it's done through the generic version numbering system. Since unconfirming different adjudicators is preference-dependent, I think it's not appropriate for the model level; it should be done at the view level instead.

This makes things pretty messy: at this point there's probably an argument to be made that the common versioning system I wrote a long time ago for both ballots and feedback was a mistake, and ballots and feedback instead should have distinct versioning systems. In particular, one could probably argue that all confirming/unconfirming of feedback should be done at the view level, not the model level. But I don't really think I'm up for all that refactoring, for the feedback system.

[philipbelesky]

Yea, that's more than fair. The underlying problem here can be mitigated either the model level or the UI level (i.e. #812) so it would be enough to solve it with whatever is going to be the cleanest/easiest implementation. If the problem persists I could maybe see the place for a simple cards-style feedback page that shows these 'extra' submissions for easy unconfirmation but that's a future consideration.