Add strict rules about upgrading to next versions of colony/OneTxPayment #1181
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
area
force-pushed
the
maint/voting-reputation-upgrade-help
branch
from
4d67870 to
4f8933c
Compare
kronosapiens
force-pushed
the
maint/voting-reputation-upgrade-help
branch
2 times, most recently
from
691ccac to
f4f7e11
Compare
kronosapiens
reviewed
Nov 7, 2023
area
force-pushed
the
maint/voting-reputation-upgrade-help
branch
2 times, most recently
from
2f34380 to
907f74c
Compare
kronosapiens
reviewed
Nov 8, 2023
area
force-pushed
the
maint/voting-reputation-upgrade-help
branch
from
907f74c to
19e10f9
Compare
kronosapiens
approved these changes
Nov 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the merging of #1150, we are presented with a bit of a dilemma in terms of the user experience we want and the practicalities on the contracts, at least in combination with the restriction of putting as little extra dev work on the frontend team as possible. This comes around because the next version of OneTxPayment needs an additional permission to work, and the next version of Colony won't support old OneTxPayment versions.
The top-level requirement is that users of the frontend shouldn't be able to (with regular usage) get in to a state where OneTxPayment doesn't work, with as little work on the frontend as possible. Some work will be required (to award the new permission required) but that should be a trivial change in both frontends, and so is acceptable.
The approach I've taken here is to (if OneTxPayment is installed)
upgradeExtension).If OneTxPayments is not installed, the colony can upgrade 13->14 as normal. If OneTxPayments is installed, but doesn't have permissions in the root domain (the implication being non-standard use exclusively in subdomains), then the same restrictions apply to the upgrade, but the extension won't be awarded the arbitration permission in the root domain. In this scenario, the user will have to award the new permission manually to OneTxPayments - but to get in to that state, they've had to do that anyway, so it has been deemed to be acceptable.
Placing these restrictions in the contracts means that (hopefully) helpful messages will bubble-up to the frontend with no extra work from them.
This PR also changes the upgrade tests that were in #1150 to use the deploy-old-colony-version functionality that I had to add here to test this functionality as I wanted.