-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: description in release step #3726
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well it does in fact do the job, but if we always want to display this, I think we should remove FinalizeByPaymentCreator
info so we get rid of some extra lines 😎
/> | ||
)} | ||
</> | ||
<ActionWithPermissionsInfo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm? :D Alright so we always display that the payment was released via permissions, if that's what we always need to do (even if the user used their temporary payment creator permissions), we can safely remove FinalizeByPaymentCreatorInfo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @adam-strzelec thanks for picking this issue up 🙌
However, I believe this is not working as intended.
If I release the advanced payment using Permissions
the right information is displayed
However, releasing the advanced payment using Payment creator
the same details as for the previously used decision method (Permissions
) is shown, which is not correct
@mmioana Where can i get decision method? From what I see, the |
The permissions vs payment creator selection never worked properly - the saga always uses payment creator if user is such: While we can tell if permissions or reputation was used, we lack details to tell if permissions were specifically chosen over payment creator. @arrenv How should we proceed with this one?
|
Thank you for the input on this. I think it is useful to be able to communicate the difference of how the payment was released. So, out of the two options provided, I would opt for the second one.
To add to that, I feel it would also be good to have the select field to auto select the option if there is only one. I do think a new issue should be created for this update. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
</> | ||
<ActionWithPermissionsInfo | ||
action={finalizingActions?.items[0]} | ||
statusText="action.executed.creator.description" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to show payment creator/permissions depending on the decision method used
d808b86
to
4592627
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your continuous effort on this one @adam-strzelec 🙌
Now the copy is the correct one for the Release
step as the Payment creator
Created another Advanced payment
And tried to finalise it as amy
, but it seems I can no longer do that. Is this as intended?
Yes, this is intended, there has to be an available decision method for a non-creator of the Payment to be able to release it. So, amy would need either the right permissions ("Payer" bundled or Arbitration), or, the Lazy consensus extension would need to be installed and there would need to be reputation in the domain. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @adam-strzelec @arrenv thanks for the clarification 🙌
The description correctly updates when releasing as a payment creator
Created another Advanced payment
Then after installing the Reputation
extension
And tried to release it as amy
, the Reputation
decision method was available in the dropdown
However @arrenv @adam-strzelec, if I assign amy
the Payer
bundled permissions, the permissions is not available to Release
the advanced payment ❌
@adam-strzelec It is correct that with "Payer" bundled permissions or "Custom - Arbitration" permissions. You should be able to "Release" the payment. |
@mmioana done 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for another round of changes @adam-strzelec
As leela (who created the payment), I can correctly see Payment creator as the only available decision method:
As a user without arbitration permission, I get an error as expected:
However, after being assigned Payer role, the newly available method reads "Payment creator" instead of "Permissions":
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your continuous efforts on this issue @adam-strzelec 🙌
Released a payment as Payment creator
✅
Released payment using Payer
permissions ✅
However the widget from the Release
step showed the payment was released as Payment creator
, which is not correct ❌
Gave fry
Custom-Arbitration
permissions
Released payment using Custom-Arbitration
permissions ✅
However, also here the same problem with the widget showing the payment was released as Payment creator
, which is not correct ❌
userRole?.role === 'payer' || | ||
(userRole?.role === 'custom' && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we please use here UserRole.Payer
and UserRole.Custom
instead of hard-coded values?
{selectedFinalizeAction && !selectedFinalizeMotion && ( | ||
<ActionWithPermissionsInfo action={selectedFinalizeAction} /> | ||
<FinalizeByPaymentCreatorInfo | ||
userAdddress={selectedFinalizeAction.initiatorAddress} | ||
/> | ||
)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we should perform a similar check for userIsCreator
to decide which description to actually show
@mmioana Do we have any designs for how it should look like when the user uses permissions? The main issue only says very generally that |
@adam-strzelec I believe that's the copy that should be used in case of permissions, it would be consistent with the cancel step: |
@bassgeta @jakubcolony @mmioana done 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for all the changes @adam-strzelec it all works as expected now 🥇
Released the payment as Payment creator
Gave amy
Payer
permissions and released the payment using Permissions
Now gave fry
Custom-Arbitration
permissions
And released the payment using Permissions
Removed fry
's permissions and installed the Reputation
extension
Created another payment as fry
and used the Reputation
decision method for releasing the payment
@adam-strzelec Regarding the wording I think @arrenv is best to provide an input to when releasing a payment using Permissions
we should use Member used permissions to create this action.
. Personally, I believe Member used permissions to release this payment.
would be a better fit. Either way, I'm happy to approve your PR 💯
Really nice work and thanks again for all the changes! 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adam-strzelec Regarding wording as @mmioana has raised, this is definitely the desired behavior, we want these descriptions to be as accurate as possible so, if it can be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot @adam-strzelec for your latest copy change as well as for all your efforts on this issue 🙌
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work on this PR, looks good to be merged. Thank you @adam-strzelec 👍
Releasing as another user with permissions:
@bassgeta Can you please take a look at this PR? We have 2 approvals already :) |
Description
Add
Permissions
forPayer
andCustom - arbitration
role andPayment creator
forOwner
Testing
Diffs
Changes 🏗
Resolves 3334