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
}
]
```
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#2448.
Currently, if a wrong password is entered when generating a wallet account, the app will crash due to attempting to decode a `GeneratedAccount ` from an rpc response containing only an error.
With this PR, we are detecting if an error is returned in the response, and if so, raising a StatusGoException. This exception is caught in the call chain, and translated in to a `StatusGoError` which is serialised and sent to the QML view, where it is parsed and displayed as an invalid password error in the input box.
refactor: remove string return values as error messages in wallet model
In the wallet model, we were passing back empty strings for no error, or an error as a string. This is not only confusing, but does not benefit from leaning on the compiler and strong types. One has to read the entire code to understand if a string result is returned when there is no error instead of implicitly being able to understand there is no return type.
To alleviate this, account creation fundtions that do not need to return a value have been changed to a void return type, and raise `StatusGoException` if there is an error encountered. This can be caught in the call chain and used as necessary (ie to pass to QML).
refactor: move invalid password string detection to Utils
Currently, we are reading returned view model values and checking to see if they include a known string from Status Go that means there was an invalid password used. This string was placed in the codebased in mulitple locations.
This PR moves the string check to a Utils function and updates all the references to use the function in Utils.
Fixes: #2364
The Send Message button click event was erroring due to a refactor that had been done to allow for changing app sections.
This has been updated to follow the current way to change app sections.
fix: “Send Message” button crash in communities
This required switching from communities to normal view.
fix: crash when clicking channel link in community message
When a message in communities contains a link to another channel (ie #otherchannel), the search for this channel needed to be updated to also search for the channel by name, allowing for switching between channels within a community by message link. Additionally, when in a community, if the channel was located in a normal chat, it will switch the view to the normal chat after being found.
Fixes: #2257.
If a user had selected a watch-only address in the wallet, the backend `walletModel.currentAccount` property would also change. When loading a transaction modal, this property was used to set the `selectedAccount` value for the “from” `AccountSelector`, regardless if the account was a watch-only address.
This PR updates the logic for `selectedAccount` such that it will only allow the account to be selected if it is not a watch-only account.
This commit introces global settings that apply across accounts used
inside the application. This is useful when settings like the selected
locale should b the same across all accounts.
Closes#2144
Alright, this is an interesting one:
As described in #1829, when the profile popup is opened within the chat view,
users are still able to click *through* the popup on message, which then puts them in
an active state.
I've done a bunch of debugging as described [here](https://github.com/status-im/status-desktop/issues/1829#issuecomment-804748148) and after doing some
further debugging, I found out that `isMessageActive` isn't really the culprit here.
What causes this effect is the `HoverHandler` that's attached to the `CompactMessage` item.
`HoverHandler` is a standard QML type that emits `hoverChanged` signals so one can do things like
applying hover effects on elements, which is exactly what we do:
```
HoverHandler {
onHoverChanged: {
root.isHovered = hovered // `root` being the message item
}
}
```
I assume we went with this handler because putting a `MouseArea` in there instead, which fills
the entire message component pretty much eliminates all existing mouse handlers attached to
other child components, such as the profile image or the username of the message, which also
open a message context menu.
It turns out that, having a `HoverHandler` as described above, actually activates it when the
user clicks with the left mouse button as well (not just on hover). That's what causes the "click-through"
effect. This can be verified by setting `acceptedButtons` to `Qt.RightButton`, basically telling
the handler that only right clicks will activate it.
I then tried using `Qt.NoButtons` instead so that no button clicks and only hovers will activate
the handler, but that didn't seem to have any effect at all. It still defaults to `Qt.LeftButton`.
So the last resort was to disable the `HoverHandler` altogether, whenever either the profile popup,
or the message context menu (for emojis etc) is open.
Unfortunately, we don't have access to the profile popup in the compact message component, because it's
detached from the component tree. Therefore, I've introduced a new property `profilePopupOpened` on
the chat layout, which we can read from instead.
Fixes#1829
When the communities code was moved into its own view in https://github.com/status-im/status-desktop/commit/b38d1df59
it broke the functionality to join communities again.
Qt complains that the Nim API in use `chatsModel.communities.joinCommunity`
expects two parameters, when it's call with just one.
This is unexpected because the API in question set a default value
for its second parameter.
To make this work again, we have to make sure the `setActive`
parameter is supplied every time we call the API from
within QML.
Also, worth noting that this is not the first time we're running into
a scenario like this.
For an unknown reason, when the `chatLogView` ListView uses
a `verticalLayoutDirection: BottomToTop`, it prevents the application
from successfully rendering during login and crashes.
From debugging this, we know that this only happens when the above
condition applies *and* when a `DelegateModel` is used.
The delegate doesn't even need proper data, it application would still
crash.
We found out that the crash can be avoided when another `ListView` exists
in this component (however it's unclear why).
For now this commit adds such a placeholder `ListView` until it
we know more about what's going on.
In some cases inside of 1-on-1 chats, the fake messages added to
the beginning of the message list, wouldn't determine the correct
username of the contact in question.
This commit explicitly calls `chatsModel.userNameOrAlias()` instead
of relying on `activeChannel.name` which tries to do the same.
This commit adds a menu item to the message context menu to
copy links that may exist inside of a message.
There are three possible scenarios:
1. There's no link in the message, which causes the menu to not
render the dedicated menu item at all
2. There's one link in the message, which renders an additional
`Action` with a copy-to-clipboard functionality
3. There are multiple links in a single message. This adds a
nested `PopupMenu` in the existing menu with menu items for each
link extracted from the message
To make this work there were some changes in the `PopupMenu` component
needed, as it wasn't take the sub menu's `enabled` state into account
properly. This makde it always render nested menus even when they
should've been invisible.
Closes: #1733
This was missing in one of our previous PRs and causes the
channel context menu to not function properly e.g. when deleting
chats, it currently always deletes the first chat in the channel list
instead of the active channel.
redesigns the compact mode to have a nice hover, easier replying and adding reactions and more
Missing parts are aligning chat command, images and unfurlings, redesigning mentions and the channel list and also trying to find a way to re-enable link hovers in the text
This commit does a bunch of things:
- First and foremost, it removes the active channel dependency.
This is needed to have it operate on the correct channel object,
without forcing us to change the active channel (e.g. right-clicking
on a channel item that's not active, will make it active eventually)
- To make that work, this commit changes the `ChannelContextMenu`
to receive a `ChatItemView`, so it can be used for things like determining
what menu options are shown, what members are in a group, whether
someone is admin of a group etc.
- This also required a new `QtProperty` called `contextChannel`.
The reason this is required, is because in some cases, like receiving
members count of groups, we need a complete `ChatItemView` object
as we don't have access to certain APIs otherwise.
- Unfortunately, we can't pass down `activeChannel` every where for that
because sometimes the context menu should not actually operate on
the active channel.
Fixes: #1755
This commit introduces a new `ChannelContextMenu` component that can be reused
in different places, such as the channel list, as well as the chat bar.
At the moment we use two different pop up menus that also show two different
set of menu options. By using `ChanelContextMenu` in both of these places,
we get the same menu and same experience.
Closes#1711
fixes#935
A bug occurs when someone requests a large amount of funds from you since the gas estimation will fail and there isn't a way of handling errors in the source yet.
This PR handles the error appropriatley for both `estimateGas` and `estimateTokenGas` where the response is only converted from hex to int if the RPC call was successful. Otherwise return the error message as the response and let the UI decide how to display it.
Currently the error for gas estimation in transaction bubbles is displayed in a popup however, ive come to realize that 2 popups open instead of one. This is a new bug of which I can't pinpoint the root cause at the moment and have opted to file a separate issue for it.
This commit makes reactions in the status timeline work.
There are two things prior to this commit that are broken:
1. The logic that opens the reaction context menu always expects
and instance of `chatsView` because it tries to calculate a users
nickname. Such an instance isn't always available in that context, so
the nickname logic has been moved to `appMain` for now, removing that
dependency and therefore making it work in both, the chat view as well
as the status view.
2. While 1) makes the context menu work, it turns out that adding and
removing reactions inside the status timeline is still not working.
The reason for that is, that the reactions component maintains its own
`messageList`, which isn't aware of the fact that reactions for messages
coming from chats of `ChatType.Profile`, need to go into a dedicated
message list for `ChatType.Timeline`.
In other words, reactions are sent and removed from message in messagelists
that don't actually exist.
This commit fixes both of these things by ensuring the message lists
maintained by reactions are timeline aware. Also ensuring updates are
done correctly.
Prior to this commit, the function was expected on a `chatView` QML object.
This has worked out so far because the places where the API is used were always
living inside `ChatLayout`.
With the new timeline however, this is no longer the case so we have to make sure
that the API is available to other views as well.
Jonathan Rainville
Eric Mastro
Richard Ramos
Pascal Precht
Iuri Matias
ace-smart
Malik Al-Jabr
staked-smart-ace