As described in #3015, when editing channels that belong to a category of a community,
after saving them, they'll get kicked out of the category.
This is because we haven't passed the category id along the API that performs the
save operation.
This commit ensures we have access to a category chats' `categoryId` and send it
over to `editCommunityChat` RPC API provided by status-go
Fixes#3015
There are a few issues with the popup's content when there are many channels in a community:
1. Channel items belonging to other categories would still take space in the list
1. Due to the longer list of channels, the delete button wouldn't be fully visible (scrolling down
helps here)
2. Scrolling down is hard because the `ListView` in use is `interactive`
3. Even when `interactive` is set to false, one would scroll the name input out of the viewport.
To solve these, this commit rearchitects the popup's content such that:
1. The name input is always static and in place
2. The scrollview starts with the channel list and ends with the channel list
3. The delete button is positioned below the scrollview
4. The scrollview has a max height of 300 so that the popup doesn't grow too big
5. Invisible channel items won't have a height anymore
The result is that the middle section of the popup becomes scrollable in case there's many
channel items, while both, the name input and the delete button stay in the viewport.
Fixes#3013
This was lost during the refactor to use StatusQ components because it wasn't
clear to me that community channel descriptions should be rendered there.
Fixes#2982
Fixes#2434. Modals that were affected by this issue were
- RegisterENSModal (for registeing an ens username)
- SetPubKeyModal (for changing the contact code of an already owned ens)
- StatusStickerPackPurchaseModal (for acquiring a sticker pack)
When right-clicking a community from the navbar and selecting "View community", Status Desktop
opens `CommunityMembersPopup` which looks like it was either never really finished or more of an
intermediate solution until a proper community profile popup was created.
That's why this commit replaces it with a `CommunityProfilePopup` instead.
In fact, this lead to changes in `CommunityProfilePopup` where the `activeCommunity` dependency
is entirely removed, which allows us to use this popup in various places given that it's hydrated
with proper data.
Because we're no longer relying on `activeCommunity` inside that popup, all of its children and
connected popups needed that same refactor as well, hence this PR introduces a few more changes.
Closes#2890
This replaces the modal popup with `StatusModal` in the `CreateCommunityPopup`
and also ensures that it adheres to the design.
There are still things to be refactored in here, primarily form control components.
Those will be tackled in future commits once they have been built in StatusQ
Closes#2882
There was a change in StatusQ that introduced dividers for modal footers
and headers, so we don't need to put them in the content manually anymore.
This commit removes the no longer needed ones.
Toast message is added when user access an existing community using community's private key. Toast
message with message that importing community is in progress is displayed while community is being
imported and once it is imported toast is closed and new one, which will be closed in 4 seconds,
with message that community is imported is displayed.
Fixes: #2467
The reason for this issue is a message where recipient accepted to share his address with sender.
In that message recipient's public key is set as a "from" property of a "Message" object and we
cannot determine which of two users has initiated transaction actually.
This is fixed checking if the "from" address from the "commandParameters" object of the "Message"
is contained as an address in the wallet of logged in user. If yes, means that currently logged in
user has initiated a transaction (he is a sender), otherwise currently logged in user is a
recipient.
We were just sending a transaction, without notifying message about that. Now we call
callPrivateRPC("acceptRequestTransaction".prefix, %* [transactionHash, messageId, signature])
and that notifies message about the change, but only on the sender side. Appropriate message
on the recipient side was not notified about the change. That need to be checked.
Pascal Precht
Anthony Laibe
Andrei Smirnov
Alexandra Betouni
Richard Ramos
Jonathan Rainville
Sale Djenic