Fixes#10501
The problem was that didn't have access to the updated contact from status-go after banning or unbanning, so we just changed the banned property, but there is more that gets changed in the backend, like `removed` being set to `true` as well.
With this fix, when you unban someone, you go back to a fresh start, as **non** contact, so you need to send a request again. That was the state you got if you restarted the app, so "re-sync" the state with status-go.
Another issue was on the frontend (QML). When banned, and after restarting to get the right state, the unban button would be disabled and the Add contact request button would show, which is not good. We only want to send requests when unbanned.
Fixes#10523
The problem was that the CreateChatView now uses an isolated Chat RootStore, since we can't be sure if the personal chat section will be loaded yet.
To fix that, I created a new store that is only for storing the properties needed for that new chat. That way we are sure that it is created and shared to necessary components.
- do not hardcode width of child elements (impossible to propagate
setting the width from the toplevel/parent component)
- made both the community and non-community chat item look the same and
according to the Figma designs (including margins, scrollbar positions,
spacing etc)
- cleaned up some hardcoded values and dead code
Fixes#10469
Also:
test(suite_communities): Fixed community related tests
- A new intermediate popup is now displayed when user clicks on `Create New Community` button from `Community Portal`.
- Reformulated `tst_communityPermissions` since now it is a default option without the need of activating it from experimental feature's section.
Closes#10115
Implement the UI part of Profile/Settings/Showcase:
- Communities/Accounts/Collectibles/Assets tabs
- drag and drop of items between "hidden" and "in showcase" sections
- ability to set individual items' visibility
- persistency (showcase saved across restarts), not exposed yet due to
missing backend API
Closes#9936
There's a bug that all requests to join a community require the user to
authenticate themselves. This should only be needed for community that
are token permissioned.
This commit fixes it by only performing auth when requesting from the
tokengated community view.
Fixes#10010
Users that request access to community that are token permissioned
need to authenticate and enter their password, so they can reveal
their wallet addresses
- Refactored minting components store access, since some panels were accessing stores directly. Now `CommunitySettingsView` is the single place where stores are accessed.
- Renamed store `CommunitesStore` to `CommunityTokensStore` for handling minting / airdrop actions / request models.
- `NetworkFilter` refactored to prevent direct access to store inside the component.
Closes#9663
This does a few things:
- It integrates with the latest `CommunityTokensMetadata` to access
community specific ERC721 token
- It changes `ChatLayout` such that it conditionally loads either
`ChatView` or `JoinCommunityView`. `JoinCommunityView` has been
specifically designed for token-gated communities
Here's what works (in terms of token permissions):
1. If a community has token permissions and the the current users is not
a member of that community, we show `JoinCommunityView` instead of
`ChatView`
2. Any community token permissions of type "Become member" are listed in
the `JoinCommunityView`
3. There are different types of token critera a permission can have:
ERC20 token, ERC721 token, or ENS (which is also ERC721 but we have
a type for that nonetheless)
Only ERC20 token balances are checked for the known wallet accounts.
This happens every time the known token list has been updated (every
10 min atm).
We still need to add balance checks for any ERC721 tokens and ENS.
4. If token permissions are created, updated or deleted by the community
owner, the `JoinCommunityView` will update in real-time.
You'll also notice that the `Reveal my address and request access`
button will be enabled if any of the token permissions are fulfilled
(only ERC20 at the time being). Clicking that button will not yet send
a request.
This will be done in the next step as part of https://github.com/status-im/status-desktop/issues/9761
So far CP components (views, panels) were accessing stores directly.
Now `CommunitySettingsView` is a single place where stores are accessed.
Other components no longer depend on stores.
Moreover:
- dedicated store `PermissionsStore` created for handling permissions
in a single, separated place
- storybook pages fixed
Closes: #9784
This commit is the first of implementing community permissions.
**It is not implementing the complete feature**, rather does it
introduce the first pieces, such that we can get code reviewed and
merged before it grows too big.
To review these features, please make sure to
1. Enable wallet (Settings -> Advanced -> Wallet toggle)
2. Enable community permissions (Settings -> Advanced -> Community
Permissions toggle)
You'll have to restart the app after doing so.
The commit introduces the following:
**UI, API calls and view models to CRUD community permissions**
After creating a community, the user can go to the community
settings and create new token permissions. The user can also update
and delete existing permissions.
**Asset and collectible view models**
To create community token permissions, users have to select
the token criteria. This commit introduces the `assetsModel` for ERC20
tokens and `collectiblesModel` for `ERC721` tokens.
The latter only supports custom minted community tokens at this point.
**This commit requires:** https://github.com/status-im/status-go/pull/3207
LinksMessageView component will receive the urls from nim as string and it will only forward the string to getLinkPreviewData slot implemented in nim together with some settings (supported img extensions and unfurling preferences)
On nim side the urls will be parsed and validated using the settings received from qml.
Images are now validated before sending them to the UI using the HEAD request.
Add Community Tokens testing UI with minting button, enabled by a Advanced Settings toggle.
Add minting module,view and needed models.
Add community_tokens service to call collectibles smart contract functions.
Issue #8921
- all remaining global popup components moved into a separate Popups
entity
- removed some static objects from the Global singleton (appMain,
pinnedMessagesPopup, communityProfilePopup, sounds); rationale:
singletons should not contain any state
- fixed support for popups in storybook
- fixed some warnings (most of them broke the popups in one way or the other)
Adds the action to copy the right-clicked message's text.
It copies the unparsed text (no html).
For that, I had to add it in the MessageItem and expose it in the model.
I also fixed the copy MessageId action that didn't show + didn't work even if it would have shown.
Plus some small cleanups.
Status allows for importing communities via their private keys.
There's a requested feature that users should be able to import a community via
its public key as well.
This will behave differently as private keys won't give users ownership
of the communities. When importing via a (compressed) public key, Status
will try to fetch information about the community from the network. If it
finds such information, it'll load it into the app and create
a communitiy view from which users can then request access.
If it can't find a community or community information in the network,
the user will get a dedicated error message.
This commit also refactors the `ImportCommunityPopup` such that it uses
`StatusDialog` and updates the copy accordingly since importing via
public key is now possible as well.
Closes#8339
This adds support for receiving copied images from the clipboard
and pasting it into the chat input.
After pasting, chat input will recognize the image and render a preview
similar to how it would do it when selecting images via the file dialog.
**Also important to note**:
At the time of this PR, it seems that desktop only supports sending
jpegs to status-go. I'm not sure if this was deliberately done this way
because the protocol says it supports jpg, png, webp and gif.
Because of this, pasting for example pngs will work, however
transparency will be lost (which is also most likely the cause of #8820)
This PR operates on that assumption. So while it adds support for
copy/pasting images, it does not address the lack of file type support.
Closes#3395
Pascal Precht
Jonathan Rainville
Boris Melnik
Igor Sirotin
Anthony Laibe
Alex Jbanca
Lukáš Tinkl
Alexandra Betouni
MishkaRogachev
Patryk Osmaczko
Michal Iskierko
Khushboo Mehta
mprakhov
Noelia
Michał Cieślak
Richard Ramos
Dario Gabriel Lipicar
Pascal Precht