Allow to revert check-ins
pc-coholic opened this issue · 6 comments
Add a button to the GUI that removes the checkin-mark on a position after scanning a barcode.
Useful when you accidentally scanned someone's Merch-voucher instead of the admission-voucher.
So you mean, you check a "reverse" checkbox and every code that is scanned will become valid and usable again?
Sounds useful. I would however implement it as a butten "make valid again" that appears after it has been scanned, instead of having a persistent checkbox that someone might forget to uncheck again.
Exactly what rami is saying: Just an additional button after a ticket has been scanned.
Bad news: After #15 is landed (probably today) this will get harder as reverting actions makes asynchronous APIs complicated…
I was thinking about this... Of course, the asynchronous checkin mode makes things a little more complicated... But I'm not really sure, if that's really an issue...
The usecase for this feature is (at least for me) to revert an accidental check in of a ticket. So it will likely occur within a few seconds or minutes and probably on the same device that I used to do the original check in.
Of course we may run into race-conditions if the ticket is scanned on different devices - but that's already the case when async-mode.
My proposal would be to extend the TicketCheckProvider with an revertCheckin-functionality which either calls a corresponding API-call (for OnlineCheckProvider) or sets the ticket to unused and inserts a QueuedCheckOut (for the AsyncCheckProvider).
Generally speaking, perhaps we should display a warning-message when activating async-mode to explain what might cause problems...
Or - and that would be even easier: Only implement this whole thing just for the OnlineCheckProvider. It is my understanding, that this one should also be the preferred way to use pretixdroid...
The usecase for this feature is (at least for me) to revert an accidental check in of a ticket. So it will likely occur within a few seconds or minutes and probably on the same device that I used to do the original check in.
- We have no guarantee that it is not yet synced
- Nope, that's not the only usecase. People asked me about this feature because they want to scan tickets at both entrance and exit of the building to keep track of who is inside (and how many).
Of course we may run into race-conditions if the ticket is scanned on different devices - but that's already the case when async-mode.
There's a difference here: Currently, race-conditions are not relevant for the final state of the order. If we have two devices, A and B, and the internet is down, both scan it and mark it as valid, the server has an easy job merging the uploads: That's a double-scanned ticket, it doesn't matter which device scanned first.
If we have this feature, especially in the use-case "scanning at every entry and exit" outlined above becomes more difficult, because the scan order starts to matter and we can't really rely on the local time of the devices being correct. Also, we'd need to construct the UI in a way that allows you to "revert a scan" even if your device thinks it hasn't been scanned before.
My proposal would be to extend the TicketCheckProvider with an revertCheckin-functionality which either calls a corresponding API-call (for OnlineCheckProvider) or sets the ticket to unused and inserts a QueuedCheckOut (for the AsyncCheckProvider).
Yep.
Generally speaking, perhaps we should display a warning-message when activating async-mode to explain what might cause problems...
That's already the case.
Or - and that would be even easier: Only implement this whole thing just for the OnlineCheckProvider. It is my understanding, that this one should also be the preferred way to use pretixdroid...
Not sure, the async mode is a very valid use case, as it not only helps with missing internet connection but is a very efficient way to handle slow internet connections and speed up the process, especially if you expect very little dishonest participants.