This broke during the modal refactoring because we're no longer relying
on `chatsModel.contextChannel`.
Passing the channel item to the popup ensures it's properly hydrated again.
Closes#3050
Bug is easily reproducible if you try to buy some stickers, in that case suggestion text
overlaps divider and buttons, and if you don't enough balance warning about that will overlap
all that also.
Fixed by increasing hight of the appropriate modal.
Fixes: #2994
Allow to click enter when generating a new account and clicking enter
Error was:
qrc:/onboarding/CreatePasswordModal.qml:53: Error: Insufficient arguments
This also updates StatusQ as the underlying StatusListItem component wasn't able
to handle multi-line subtitles very well. Also it didn't support tertiaryTitle, which
is needed in this UI.
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
- The arrow in select chat name was not
from StatusQ
- The text in case of password missmatch
was wrongly displayed
- The loading icon color was not from StatusQ
Closes#2762
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
* Text copied from clipboard that included images
and other rich content was not visible in text
box when pasted, modified to keep only plain
text instead and removed unnecessary funtions
* Also removed unecessary Rectangle in Input
Closes#2650
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.
Anthony Laibe
Pascal Precht
Iuri Matias
Sale Djenic
Richard Ramos
Jonathan Rainville
Alexandra Betouni
Andrei Smirnov
B.Melnik