-
Notifications
You must be signed in to change notification settings - Fork 242
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
Bug: Fix view&post token-permitted channel input not locked #5023
Conversation
Jenkins BuildsClick to see older builds (20)
|
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.
Does the Edit shared addresses flow still work with this?
Let's say you had all accounts selected at first, go in the edit popup and unselect the address with ETH, does the popup show correctly that we do not have ETH?
Yes, here is a video recording Screencast.from.2024-04-08.07.59.35.AM.webm |
3c52df5
to
caf512a
Compare
In the video, we can see that it didn't work as intended. The Account with 0.15 ETH was unselected, and still, all the channel were marked a |
Oh right, I misread your sentence. I think while preparing the code for testing I inadvertently changed something, let me double check. This flow should already work. Screencast.from.2024-04-08.02.28.18.PM.webm |
caf512a
to
c126eb3
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.
Ok, seeing the new video, the behaviour seems correct now. The fact that the chat content in the background updates at the same time is known and will be addressed in another issue
ce29cce
to
e532b61
Compare
We are now able to lock consistently the channel if we do not have permission to view&post. This PR fixes status-im/status-desktop#14117
e532b61
to
21cccbe
Compare
We are now able to lock consistently the channel if we do not have permission to view&post. This PR fixes status-im/status-desktop#14117
We are now able to lock consistently the channel if we do not have permission to view&post. This PR fixes status-im/status-desktop#14117
Description
In previous version of status-go, we failed to compute the permission for communities with token permitted channels. This caused the UI to display the wrong UI when displaying the channel UI. Indeed, the user was enable to view the channel and couldn't send messages.
In this PR, we are now able to lock consistently the channel if we do not have permission to view&post. This PR fixes #14117
The change consists in adding a retrieval of the Revealed accounts for cases when the addresses are not shared, and where the purpose isn't to have all accounts considered for the calculation of permissions on channel.
Testing
Multiple tests already cover the functions
CheckAllChannelsPermissions
andCheckChannelPermissions
, making sure all tests are passed. If any strong opinion on the testing side, I can allocate a bit more time.I have also checked the flows :
-[x] Restore write when channel is unlocked
-[x] Set the channel permissions at boot
-[x] Detect changes when user
-[x] edit permissions
-[x] create permissions
-[x] delete permissions
Demo
Screencast.from.2024-04-08.12.18.14.AM.webm