An easy way to revise a match's result for host

[stash86]

Is your feature request related to a problem? Please describe.
When there is a wrong result that have been finalized, for example the host pushes the wrong result, the steps to rectify the mistake are not that clear.

Describe the solution you'd like
On the right side of Delete checkbox, add a "Fix result" checkbox to clear that match's result and show the result drop-down box again

Describe alternatives you've considered

Additional context

[bakert]

This could result in a round re-pair which sounds fraught. Also consider what happens if the last result is submitted during this edit.

…

On Fri, Sep 14, 2018 at 4:07 AM Stefano Ariestasia ***@***.***> wrote: *Is your feature request related to a problem? Please describe.* When there is a wrong result that have been finalized, for example the host pushes the wrong result, the steps to rectify the mistake are not that clear. *Describe the solution you'd like* On the right side of Delete checkbox, add a "Fix result" checkbox to clear that match's result and show the result drop-down box again *Describe alternatives you've considered* *Additional context* — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <PennyDreadfulMTG/gatherling#147>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAGBbBOmY3UWNEPv1MhIesSv_wxvFMsks5ua43cgaJpZM4WpE2x> .

[stash86]

If a result from previous round is wrong and fixed, I do intend of making the code to re-pair the current round based on the revised result. Regarding what if the last result of the round is submitted in almost the same time as the host asking to revise a result, it would depend on who hits the db first. - If the revise request hit the db first, then by the time the last match's result hit the db, the code would see that there is 1 unreported match (the gonna-be-corrected match) and the code won't pair the next round until the host enter the result for that wrong match - If the result of the last match hit the db first, then the code would pair the next round. At the same time the code would let the host to fix the match's result. After the host finished entering the correct result, the code would re-pair the round. The host must explicitly ask the players not to play first and wait for their announcement

[bakert]

That latter case sounds like something the host won't know about until they hit save. Might be better to have that fail and prompt them?

…

On Fri, Sep 14, 2018 at 7:10 AM Stefano Ariestasia ***@***.***> wrote: If a result from previous round is wrong and fixed, I do intend of making the code to re-pair the current round based on the revised result. Regarding what if the last result of the round is submitted in almost the same time as the host asking to revise a result, it would depend on who hits the db first. - If the revise request hit the db first, then by the time the last match's result hit the db, the code would see that there is 1 unreported match (the gonna-be-corrected match) and the code won't pair the next round until the host enter the result for that wrong match - If the result of the last match hit the db first, then the code would pair the next round. At the same time the code would let the host to fix the match's result. After the host finished entering the correct result, the code would re-pair the round. The host must explicitly ask the players not to play first and wait for their announcement — You are receiving this because you commented. Reply to this email directly, view it on GitHub <PennyDreadfulMTG/gatherling#147 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAGBQZ0d7EN9gmDs8nX-cFHnU8g9VrQks5ua7jtgaJpZM4WpE2x> .