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.
This commit refactors the `CommunityProfilePopup` to use `StatusModal`. Since it's made of
various popup content components, it also updates the memberlist, the overview and the
invite friends view, so it doesn't break the UI along the way.
Closes: #2885, #2887, #2888
There are two regressions introduced in 080767c338 where
the `CreateChannelPopup` isn't properly centered when triggered in edit mode,
and that the channel name field isn't hydrated with channel data.
This commits fixes both bugs.
This bug is happening if you have more than one private chat in the contacts column. How many chats
you have that many same notifications you will get. That's happening cause connection is made
between chatsModel.messageView and ChatsMessages component for each private chat, and for each of
them ChatsMessages component is maintained in StackLayout component what means all of them are
exist but only selected instance is visible. When new messageNotificationPushed signal is emitted
each qml component triggers its slot (regardless component is not currently visible it exists in
the background, it's not deleted) and that's why we see more than one OS' notification bubble for
the same notification.
That is fixed moving slot from ChatMessage component to ChatColumn component.
Fixes: #2551
The chat navbar tab button renders an indicator when there's unread messages
in any of the chats. It also renders a message count, which prior to this commit
equals to the number of total unread messages.
This however is not the desired behaviour. Instead, the count should be the total
number of unread one on one messages (DMs), plus the total number of mentions in any
chats the user is participating in.
This commiit ensures the correct message count is rendered. It also adds an "unread messages"
indicator to community buttons.
Closes#2869
Also fixes a bug where if the search was cleared, messages would after that appear all on top of each other.
Also leaves the popup live after closing so the search can be gone back to
The issue is happening randomly. I managed to catch it few times and hopefully fix it. Problem was
in leave proc in src/status/chat.nim cause we were sending activeChannelChanged signal from it what
started setting activeChannel to the value of the backToFirstChat variable, and while that process
was in progress setActiveChannelByIndex was called from activeChannel what caused another emit of
activeChannelChanged signal while the previous one was not completed. That caused new setting of
activeChannel with active channel index 0, what caused an app crash.
This is fixed by setting active channel to the first one from the list when we get a signal that
any channel from the list is removed. This way activeChannelChanged is broadcasted to the other
parts correctly.
Fixes: #2825
This issue is being happened randomly, no general rule, in my case it happens often when you accept
first contact from the list immediately after the app start, but the ticket says that it happens
when you click accept while context menu is opened.
Two places were threat for this crash and both are fixed here:
- getChannel proc, direct access by index to Chat element of the chats sequence,
- setChatItem proc, where we actually were setting chatItem and accessing its property without
checking if it is an empty object.
Fixes: #2837
A crash is happening not only when you click on a notification bubble with mentions, but on any
chat notification displayed in macOS' notification center. Discussion and details how we can
overcome this may be seen on zenhub, in issue 2819. So far this commit is just a simple solution
to avoid an app crash.
Fixes: #2819
This commit replaces the `TopBar` components with StatusQ's `StatusChatToolBar`
and touches a few other things as part of this refactoring, namely:
1. `ChannelContextMenu` has been renamed to `ChatContextMenu` and is now a `StatusPopupMenu`
2. Leftover components have been removed: `StatusChatInfo`, `StatusChatInfoButton` and `TopBar`
3 `ActivityCenter` has been moved into `ChatColumn.qml` because `StatusChatToolBar` doesn't provide it
4. `Share chat` option in `ChatContextMenu` has been removed as it wasn't doing anything.
Closes#2746
This commit replaces `CategoryList` and `ChannelList` with `StatusChatListAndCategories`,
`StatusPopupMenu` etc. provided by StatusQ.
It also removes components that lived inside Status Desktop but are no longer used
anywhere after the refactor.
Since StatusQ components are decoupled from UI model logic, we also needed to introduce
a new API retrieve a community category from within QML.
Closes#2805
A reason why the crash is happening is actually previous step, when an user who is about to receive
a transaction clicks "confirm and share address" button. In that moment instead of his address an
empty js object is shared. After that clicking on the "sign and send" button, by sender, causes an
app crash because transaction cannot be made using invalid address of the recipient.
Fixes: #2718
Andrei Smirnov
Alexandra Betouni
Sale Djenic
Richard Ramos
Pascal Precht
Anthony Laibe
Jonathan Rainville