Since `src/status` was Qt dependant part because of the following foundation files:
- /src/status/tasks/marathon/mailserver/controller.nim
- /src/status/signals/core.nim
- /src/status/tasks/marathon/mailserver/events.nim
- /src/status/tasks/qt.nim
and because logic related classes like:
- /src/status/chat.nim
this commit made that part Qt independant.
New layer `src/app_service` is introduced and above mentioned foundation files
are moved there. As well as corresponding logic for requested services.
Communication between logical parts on the high level is as follows:
- `src/app` => `src/app_service` => `src/status` => `src/app`
- `src/app` => `src/status` => `src/app`
Fixes: #3376
As we keep a local list of contact request and contact added
we should not need to query this data each time we switch chat as
we already have this data in memory.
This data should be maintained each time there is a change
fixes#1642
Also: Remove what seems to be duplicated and dead code about
getContactById
Removed all computation of suggestion from qml
Reuse user list in order to populate the suggestion box
As a side effect, the suggestion are not serialized from qml to
nim
Remove InputArea which seems not used anymore
App is responsive to the OS theme change event.
Now we're following system set theme when the app is started.
Corresponding part on the side on nimqml is added.
Corresponding part on the side on dotherside is added.
On the side of dother side we had kind of a memory leak, cause objects added to
the filter were not deleted ever. When the app is closing, it just removes
filters, but doesn't delete them.
I faced a logical issue, that we were sending qmlengine pointer to the
installEventFilter method, instead object which may or may not rely on the
qqmlengine instance, that is fixed also.
Fixes: #1725
Counting mentions for community seems was not developed yet. That's added here in this commit, but
instead of using "mentionsCount" we introduced on the side of nim, I found that we're receiving
"unviewedMentionsCount", but only for new messages. I used it for this fix.
Counting mentions and requests per community added.
Fixes: #2972
A crash leaving chat is fixed.
The issue was very hidden cause everything looks ok, at first glance, but not, the thing is that
"messages" exposed to qml were deleted from ChatsView and signals beginRemoveRows and
endRemoveRows were emitted for CatsView abstract list model instead for MessageView abstract list
model. That results in an app crash in some moments (not always reproducible, but often).
Fixes: #3005
Feature added. Firstly we check if the searched message is already displayed and if yes simply jump
to it, if not then we are loading new 20 messages in the past using cursor and check if the
searched message's id is among those received messages. We do that in a loop till we find the
message we are searching for.
Fixes: #3005
Changes made here were necessary in order to have good base to requested develop feature.
- duplicated methods are removed
- loading messages either on start (initial loading) or loading more messages requested by
scrolling in the chat view is now done in separate thread (asynchronous) instead as it was earlier,
done in the main thread
- new file is added for storing async tasks for chat part only
- ChatModel (from status/chat.nim) is QObject instance now, so it may handle async job in a slot
- a job requested from the view is done in separate thread and view is notified about the changes
using signal/slot mechanism
This is not refactoring, but minimal update to have clear situation for further changes
Fixes: #3005
Searching messages by some term for a specific channel is added on the side of status-go and an
appropriate part on the side of nim is developed accordingly.
Fixes: #2912
Current code adapted to handle future changes on message search (like searching message in multiple
channels).
Memory leak which was happening in qml assigning (copying) MessageItem to qml variable messageItem
(where that qml variable messageItem was never deleted) is fixed.
Fixes: #2912
Searching messages by some term for a specific channel is added on the side of status-go and an
appropriate part on the side of nim is developed accordingly.
Fixes: #2912
Current code adapted to handle future changes on message search (like searching message in multiple
channels).
Memory leak which was happening in qml assigning (copying) MessageItem to qml variable messageItem
(where that qml variable messageItem was never deleted) is fixed.
Fixes: #2912
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.
add getSettings methods to src/status
fix issue with calling getSettings; document issue
remove most direct references to libstatus; document some common issues
remove most references to libstatus wallet
add mailserver layer to status lib; remove references to libstatus mailservers
remove libstatus accounts references
move types out of libstatus; remove libstatus types references
remove libstatus browser references
refactor libstatus utils references
remove more references to libstatus stickers
remove references to libstatus constants from src/app
remove more libstatus references from src/app
refactor token_list usage of libstatus
refactor stickers usage of libstatus
refactor chat usage of libstatus
remove libstatus references from the wallet view
remove logic from ens manager view
fix issue with import & namespace conflict
remove unnecessary imports
refactor provider view to not depend on libstatus
refactor provider view
refactor: move accounts specific code to its own section
fix account selection
move collectibles to their own module
update references to wallet transactions
refactor: move gas methods to their own file
refactor: extract tokens into their own file
refactor: extract ens to its own file
refactor: extract dappbrowser code to its own file
refactor: extract history related code to its own file
refactor: extract balance to its own file
refactor: extract utils to its own file
clean up wallet imports
fix: identicon for transaction commands
Fixes#2533
Fixes: #2601.
Kicking a user and re-inviting them now correctly redisplays the join/decline options. Other combinations of User B leaving or declining an invitation are not handled. Please see the notes below for clarification.
Additionally, the group invite popup (that shows the list of members belonging to the group) correctly shows when a user is kicked or when a user leaves the group in real time. Previously, the popup needed to be reopened to display this.
fix: decline invitation crash
Declining a group invitation was crashing the app. This has been fixed.
### NOTES
1. In the case where User A invites User B to a group, but User B declines (or User B joins, then leaves), then from a status-go standpoint, User B is still part of the group, but the chat is marked as `active: false` for User B. This creates a situation where User B cannot re-join the group once s/he has declined the invitation. @cammellos mentioned there possibly will need to be a refactor of cab6281dc5/protocol/messenger.go (L1710) (which, by retaining User B as a member, effectively prevents the re-invitation) once “swipe to delete” is implemented on mobile. There is an activity center notification received for User B that is meant to allow re-joining of the group when the notification is accepted. The activity center notification received from status-go looks like the following:
```json
"activityCenterNotifications": [
{
"id": "0x0e342d33",
"chatId": "e342d33f-dd05-4d7b-b14e-b5335e1a3ee9-0x043bf46aa874c377a34946eab67a32cf36c15907b328216dfce375d169fed7d81c21cada3229db1fd37c762d2c02702111a646657feca6621e2e948febcf378fb4",
"name": "test-22",
"type": 2,
"lastMessage": null,
"message": null,
"timestamp": 1623305612000,
"read": false,
"dismissed": false,
"accepted": false
}
]
```
Fixes: #2539.
Transaction history is now correctly being fetched from status-go as per mobile. Firstly, when accounts are added (ie as watch accounts), `wallet_checkRecentHistory` must be called first so that the status-go db is populated. After that, `wallet_getTransfersByAddress` can be called. On app load, when we run the `initBalance` logic, we are calling `wallet_getTransfersByAddress`, asking for the last 20 transactions with the `loadMore` parameter set to false. When the user navigates to the Wallet > History tab, they can then click “Load More” to fetch more transactions from status-go. Once the number of transactions returns false below the expected amount, the remaining transactions to fetch have been exhausted and the “Load More” button is disabled.
feat: add non-archival node warning to the UI to indicate to the user that they may not have complete results
feat: set active account to the added account
Once an account is added to the wallet, that newly added account is selected as the active account.
1. The “load more” button is active when new transactions that aren’t already displayed are returned from `wallet_getTransfersByAddress`. This is the only way to enable or disable the “Load more” button as status-go is not able to return information regarding whether or not there are more transactions to be fetched. The downside to this is that lets say the last page of transactions is returned, but there are no more pages left. These returned txs are not currently displayed, so the “load more” button will still be enabled. However, the next click of the button will return 0 results, thus disabling it. It’s effectively an extra click to get to the disabled state.
2. For more information on how the `toBlock` parameter operates for the `wallet_getTransfersForAddress` RPC call, see https://notes.status.im/XmENTrVRRaqhwE4gK0m8Mg?view.
Closes#2344.
Add ability to edit name, description, and private fields of a community channel.
feat: Display community channel description
Ensure the width of the description does not surpass the context menu and instead wraps to the next line.
feat: After channel is created, set it as the active channel
Fixes: #2618.
The main culprit was that `self.pinnedMessagesList` did not contain the `self.activeChannel.id` because it was correctly upserted in `upsertChannel`.
To fix this, when calling `upsertChannel`, `self.pinnedMessagesList` was checked if it contained an entry for the upserted channel first before adding it to the list.
Nil checks were added to parsing the messages RPC response in case specific fields were not returned in the response.
In addition, a copy/paste error was fixed in `asyncMessageLoadTask`.
Fixes: #2318.
Currently, when exiting the app and the sticker packs task is being run, the app will wait for the sticker packs task to completely finish before exiting the app. This causes a beachball to be displayed and can cause a long delay while waiting for the task to finish.
This PR passes an interrupt signal to the sticker pack loading task in the threadpool thread. The task loads the interrupt on each iteration of its loop (each sticker pack to load) and also during the processing of each sticker pack (getting of sticker pack data). This allows the application to exit neatly.
fix: Handle shutdown of long-running (marathon) task before login
Currently, we wait for the “loggedIn” message to be passed to the marathon task runner before initialising the mailserver model. We were, however, blocking the thread until “loggedIn” was received, meaning that if “shutdown” was received (as it is when cmd+q is pressed), this message would be ignored and the application would have to be forced to quit.
This PR adds logic that not only listens for the “loggedIn” message, but also for the “shudown” message. Once the “shutdown” message is received, the marathon worker thread exits.
Prior to this commit, loaded channels and chats would always be
sorted by date of last message received, with the latest one being
moved to the top of the list.
When new channels or chats are joined, they are added on top of the
list as well, however, when the application is restarted,
those new joined chats would not necessarily show up at the top anymore
becaue nothing keeps track of when a channel was joined, which should
be taken into account when preserving the order.
The changes introduced in this commit solve this by introducing a
new `joined` property on the `Chat` type which gets updated with
the current timestamp whenever a channel is joined.
It also depends on the changes made to the `status-go` client, which
have to land first: https://github.com/status-im/status-go/pull/2158Closes: #1832
There is an unknown state that the data dir seems to get in that causes the application to crash when checking pending transactions. This is fixed by checking if the pending transactions RPC result has a `”result”` field first before attempting to read it.
### NOTE:
Clearing the data directory fixed the issue for me, however I do not know what caused it in the first place. While the crash was happening, there was also an error appearing in the logs:
```
ERR 2021-05-18 15:40:47+10:00 rpc response error topics="rpc" tid=3893906 file=core.nim:24 methodName=wallet_getPendingTransactions payload=[] result="{\"jsonrpc\":\"2.0\",\"id\":0,\"error\":{\"code\":-32000,\"message\":\"no such column: transaction_hash\"}}"
```
After clearing the data dir, this error also went away.
Richard Ramos
Anthony Laibe
Andrei Smirnov
Sale Djenic
Pascal Precht
B.Melnik
Iuri Matias
Khushboo Mehta
Alexandra Betouni
Jonathan Rainville
Eric Mastro
Michael Bradley, Jr