When inviting contacts to a community, Status Desktop suggests a list of
all contacts, even if contacts of that list are already members of the community.
This commit introduces a new flag to `ExistingContacts` component that
allows for configuring whether community members should be hidden or not
Fixes#2502
Fixes: #2365.
Previously, suggestions for mentions were showing profile pics even for users who were not contacts. Now, profile pics are only shown for those users who are contacts. The user’s identicon is shown otherwise.
fix: user thumbnail not shown when no profile pic
When a user was a contact, but didn’t have a profile pic, an image would not be loaded and a ‘reload’ image would be shown instead. With this PR, if the user is a contact and they do not have a profile pic, their identicon will be shown instead.
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#2419
Makes it so the private key is elided by default so you can see it all from the get-go. If you focus the field, the key will "unfurl" and you can copy it manually.
Otherwise. the Copy button will always copy the whole key
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.
A `StatusIcon` that rotates infinitely and can be used for indicating
pending states.
Usage:
```
StatusLoadingIndicator {
width: 24 // default: 17
height: 24 // default: 17
color: "red" // default: loading asset color
}
```
This also removes `LoadingImage` component from `ui/shared`.
Closes#2360
Fixes: #2248.
Add a close button to the seed backup warning banner in the wallet. The banner will reappear upon application restart as long as the seed hasn’t already been backed up (`profileModel.mnemonic.isBackedUp`).
A new .svg with a white outline needed to be added as well because the original “close.svg” had a purple outline, which would show up when the ColorOverlay applied to the close button had an opacity less than 1.0.
The popup to invite friends to communities has so far always been a brand new
popup that's opened on top of possible existing popups.
The design however, expects that the same section should be shown as part
of a wizard-like process inside of the existing community profile overview
popup, when entered from there.
This commit extracts the invite friends popup section into component that
can be reused as stack view, as well as modal content, to implement both
scenarios.
This commit changes a bunch of things related to ui bugs in the community
profile popup. Fixes include:
- Removing the `Delete Community` option since this functionality isn't implemented yet
- Changing the color of the menu item's icons in dark mode to be blue
- Doing the same in the memberlist popup
There's a regression in the application where kicking members from communities
doesn't work anymore. This was due to UI logic being moved to a different model
without updating the corresponding view action.
Fixes#2274
Prior to this commit, only admins of a community could open up the community
profile popup from inside the community. However, normal members should be able
to do so too.
Normal members shouldn't be able to create channels, nor should "leave
channel" be an option of the context menu provided inside of a community.
This commit removes these.
As discussed in https://github.com/status-im/status-desktop/issues/2144#issuecomment-817791172 and https://github.com/status-im/status-desktop/discussions/2145, it's no longer desired
to have different appearance settings across multiple accounts.
Instead, the appearance setting should apply globally to all accounts,
essentially bypassing the individual setting stored in status-go.
This commit introduces a new global setting called `theme` which,
at the time of introducing this commit, can be either:
0 => Light
1 => Dark
2 => System
Because those enum values matches the `AppearanceContainer.Theme` enum,
this commit removes it completely and simply relies on QML's built-in
`Universal.[Light|Dark|System] variants respectively.
Closes#2144
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
Fixes#2050.
This PR contains changes to fix the name validation for new communities and new channels in communities. In the process of updating this, better validation was also added to both popups (create community and create channel), including the prevention of the "Create" button from being enabled until all form fields were valid.
During this process, it was noticed that the community image cropper was not actually cropping the image *in the preview*. Once the community was created, status-go was successfully cropping the image as the user intended. However, the preview thumbnail prior to creation was not accurately showing the cropped image preview and showing the entire image centred instead. *This is still yet to be fixed.* One solution is to upgrade Qt to `5.15` to take advantage of Image QML's `sourceClipRect`.
There was a bad merge in PR #2225 that caused the QML propery `activeMailserver` in `SyncContainer` to be stripped out. This was causing an error in the console: `qrc:/app/AppLayouts/Profile/Sections/SyncContainer.qml:16: Error: Cannot assign to non-existent property "activeMailserver”`.
This PR adds the property back in and resolves the issue.
Fixes#2143.
Methuselah is the a task manager for long-running tasks. It allows fo registration of workers that will each run in their own thead. Each worker can pass messages to and recieve messages from the main thread.
MailserverWoker was also introduced which moves all mailserver model logic to a MethuselahWorker. All communication to/from the model is done via a MethuselahTask. Results of the task are returned to the main thread by way of `signal_handler`, which calls the QtObject slot specified in the task.
Mailsever also provides a way for the model to emit events inside of the worker. These events are forwarded to the main thread via the `receiveEvent` slot of the `MailserverController`.
Co-authored-by: Michael Bradley, Jr <michaelsbradleyjr@gmail.com>
When the profile popup is opened inside the contacts list, it doesn't have
a surrounding window context (`Popup` types should usually be used within `ApplicationWindow`
or `Window` components as per https://doc.qt.io/qt-5/qml-qtquick-controls2-popup.html).
This is problematic when popup are nested, like it's the case with the
nickname popup that will be instantiated by the profile popup.
With no window context, such nested popup can't be opened by the application.
This commit ensures the profile popup is created with a proper context,
fixing the issue that the nickname popup won't open when visting via
contacts list.
Fixes#2216
Prior to this commit, we would only set the translation package for the
application's engine when `appSettings.locale !== "en"`.
This is problematic because it seems that `engine` is already provided with
a system default that may not be `en`. In practice, this means that, initially,
engine is loaded with, say `de`. `appSettings.locale` might be `en` but because
we're only loading the correct translation package when it's **not** `en`,
the application will stay in `de`.
Changing the language to `en` at runtime is fine, however once the application
is restarted, `engine` is again initialized with some other possible system default.
It seems that we should *always* load the translation packge when `appSettings` are
loaded.
When contract addresses that are not ERC-20 or ERC-721 were input, the token would be allowed to be added and would crash the app.
In addition, when an ERC-20 contract was deployed without a name and symbol, “Invalid ERC-20 address” would appear.
This PR adds error checking from the token detail lookup and reports the error back to the user in the modal. This prevents non-ERC-20/721 contracts from being able to be added to the app and prevents a crash.
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
This commit introduces a `reset()` function so that search results inside
the application can be easily reset. It also introduces a `resultClickable`
flag which allows consumers of this component to decide whether a search result
is clickable and emits a dedicated event.
This is useful when UIs should only allow actions via the result icon button
(as it's the case with the new add-to-contact modal).
This change aligns the member list's look & feel of the community profile popup
with the designs by implementing the proper member list items styles, hover effects
and fine-tuning the context menu.
This commit also comments some of the actions provided by the context menu,
which aren't implemented yet. There's no point in having UI components that don't or
can't function.
Those will be re-introduced once they are actually implemented.
Closes#1959
Since https://github.com/status-im/status-desktop/commit/93668ff75
we're hiding the setting to change appearance for compact normal mode
of the UI. For now, compact mode is the new default (reasoning is unclear
at this point).
Prior to this change, most likely many users are still using the
normal mode configuration, so we have to enforce compact mode for
those.
The designs for the membership request button look different now, so this
commit makes use of the `StatusSettingsLineButton` to implement that new
look & feel.
Prior to this commit, the community memberlist was represented in a nested modal
which doesn't adhere to the designs. Rather, the section should render inside the
existing modal, requiring it to be refactored using a `StackView`.
This commit refactors the community profile popup so that the different content
sections ("Overview" and "MemberList") are rendered inside of the popup and can
be pushed onto and popped off a stack view.
The content components (newly introduced in this commit) `CommunityProfilePopupMembersList`
and `CommunityProfilePopupOverview` need to define a `headerTitle`, `headerDescription` and
if needed `imageSource` so they can alter the modal's header.
The same pattern might be used in other places of the modal if required.
Partially fixes#1959
Allow up to 5 images to be dragged and dropped in to one-on-one chats and in the timeline. Can be combined with the existing upload button. The upload file dialog has been changed to allow multiple selections. Drag and dropped images adhere to the following rules, with corresponding validations messages:
- Max 5 image
- Image size must be 0.5 MB or less
- File extension must be one of [".png", ".jpg", ".jpeg", ".heif", "tif", ".tiff"]
Drag and drop and uploaded images are now also deduplicated.
This was hardcoded into `isAdmin` for some reason. It also seems that the
property isn't actually used anywhere in the profile popup, so we might
as well get rid off it.
The `communityProfilePopup` relies on the currently `activeCommunity` to
get its data. Unfortunately, once read, even when `chatsModel.setActiveCommunity()`
is called which triggers `activeCommunityChanged`, the data in the popup
won't be updated. The next time one would open a community profile page,
it'd have the data that was previously received from the model.
This commit ensures that the popup is hydrated with the most recent data
by explicitly updating its properties right before it's opened.
Prior to this commit there was a scenario where the application would
crash due a memory bug when attempting to (re)join a community.
The scenario is as follows:
1. User creates or has been invited to community with `ON_REQUEST` permissions
2. User leaves community
3. User decides to rejoin, so she selects the community she's been part
of and hits the "Join" button
At this point Status Desktop would send a new `RequestToJoin` request, as the
community has a corresponding permissions setting.
This would then result in an `already a member` error in status-go, because
status-go checks whether the requestee is already part of the members list of
the community. The error isn't handled inside Status Desktop which causes
a crash because we're trying to access data in memory that doesn't exist.
Why is this happening?
While this might be unexpected, when leaving a community (as done on step 2 of
the mentioned scenario), users don't actually lose membership but simply
"unsubscribe" from all channels in the community in question and their `joined`
flag is set to `false`.
From that point on, re-joininng a community is done by sending a `JoinCommunity`
request (instead of `RequestToJoin`), which will then set the `joined` flag to
`true` and doesn't actually check the membership in the database.
This commit ensures we're calling the right API by checking whether not only
whether the community is needs `ON _REQUEST` permissions, but also whether the
user isn't already a member of it.
Fixes#2017
In https://github.com/status-im/status-desktop/commit/a90a30af1 we've introduced the functionality to import
communities through the UI via a community private key.
That private key is being validated before it gets imported.
For some reason, validation has been removed in another refactor
later on in https://github.com/status-im/status-desktop/commit/534cb23e1, rendering the import
functionality broken.
This commit re-introduces the `validate()` method to make importing
communities work again.
Prior to this commit, communities without an image would render invisible
in the navigation bar of the application. To avoid this, we're now falling
back to our StatusLetterIdenticon component, which renders the first letter
of the community name with the color of the community.
When a user is part of a community, write access to any channel of
that community is granted. When the permission allows for it, a community's
channel `canPost` property is `true`, which should be relied on to
render the necessary component for writing into a channel.
This commit makes sure community members with proper access get the
chat input rendered so they can write to channels.
Fixes#1985
Very similar to #1986, we're trying to access the `activeCommunity`
property on the `chatsModel` object, which doesn't have such a property
anymore every since we've moved communities into its own view.
This causes errors when trying to create channels.
This commit fixes this bug by ensuring `activeCommunity` is accessed
from `chatsModel.communities` instead.
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.
Turns out in https://github.com/status-im/status-desktop/commit/81bb7fcc6 we've introduced a regression where
leaving a communities isn't possible anymore because we're trying
to call an API that doesn't exist on the `chatsModel`.
This commit fixes it by ensuring the API is called from `chatsModel.communities`.
Richard Ramos
Pascal Precht
Eric Mastro
Jonathan Rainville
Iuri Matias
B.Melnik
--replace-all