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`.
Updated community popup menu btn style. Fixes#1961
Updated community popup menu btn style. Fixes#1961
Updated community popup menu btn style. Fixes#1961
Updated community popup menu btn style. Fixes#1961
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
Pascal Precht
Iuri Matias
Jonathan Rainville
Richard Ramos
ace-smart