fixes#2826
When fetching communities, the chat attached to it are not complete.
In this commit, we ensure that everytime we fetch a community, we update
its chat with the chat being loaded which contains all the data we need
to properly display a chat
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
fixes#2659
1 - Change call from remove to deleteMessage
Remove were not updating the index and was causing the issue
2 - Erase the remove proc as the deleteMessage should always be used
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.
fixes#2637
When changing a contact, the notification about being able to chat was sent again.
Prevent this behaviour by ensuring the contact hasn't already been added
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
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
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
Mark all mention notifications as read is fixed. Also mark as read one by one notification removes "@" from the appropriate channel along with the marking as read last mention notification for that channel. hasMention field which was bool is switched with mentionsCount field which is int, so we have evidention how many mentions were for each channel.
Fixes: #2788
Fixes: #2725.
When clicking on the History tab for a wallet account, there was a QML error for `qrc:/app/AppLayouts/Wallet/WalletLayout.qml:113: TypeError: Property 'checkIfHistoryIsBeingFetched' of object HistoryTab_QMLTYPE_503(0x7fed35da2710) is not a function`. This must have been reintroduced when StatusQ objects were introduced. It has now been removed.
chore: change log level to warn for non-archival node
Previously, there was an error being logged for non-archival infura nodes being used (typically in dev). This log level has been reduced to a warning as the application still functions with non-archival nodes.
Validation check is updated, so user cannot enter zero or less than zero value for "gas amount limit" or "per-gas overall limit".
In gas.nim a crash prevention check is added.
Fixes: #2753
Validation check is updated, so user cannot enter zero or less than zero value in amount input field.
Also in utils.nim a crash prevention check is added so if we try to convert a less than zero float number to an unsigned number, app won't crash any more, but that casting will return a zero as unsigned int number.
Fixes: #2755
Fixes: #2686.
Previously, when using a new account, joining a chat then creating a community and then returning back to the chat would not show a chat at all and instead show the default chat view. This was due to the previous index not being set when there were no other channels in the chat.
This has been updated such that the previous channel index is set when switching from chat to community and no previous channel index has been set.
# Conflicts:
# src/app/chat/view.nim
Fixes: #2649.
Upon receipt of status-go signals which included communities that have been left (`joined: false`), those communities were being rejoined automatically when they should not have been.
fix(communities): Invitation bubble button state updates
The community state inside of the invitation bubble was not reactive to any community actions (such as joining, leaving, updating). In addition, requesting to join a community changed the button’s text to “Pending”, but upon approval, the button’s state was not updating.
The component was setting an observed community in the Component.onCompleted event, which was occurring for all invitation bubbles, but because the community wasn’t bound correctly to the bubble, once a bubble with a different community was encountered, the community in context of the bubble wasn’t updated and instead used a local copy. Once the community was bound correctly (to be reactive), the states started working correctly.
The invitation bubble has been simplied so that it has states instead of using lots of if/else statements inside of the property bindings. This simplified the component’s logic for things like onClick action and made it a lot easier to read and modify.
Richard Ramos
Jonathan Rainville
Sale Djenic
Andrei Smirnov
Anthony Laibe
Pascal Precht
Eric Mastro
Iuri Matias