- UI simplified, made independent from the backend
- dedicated model created, filtering on the level of model instead of
per delegate
- using ListView instead of mutliple Repeaters
- UI models removed from ProfileSectionStore
Closes: #16675
- use the same approach as status-go to detect the image type, relying
on "magic" type matching instead of looking at the file extension (now
using C++ and QMime*)
- add a little error popup when the user tries to upload an unsupported
image type while creating/editing a community
- expose all the image related properties from the C++ backend instead
of constructing and duplicating them in QML
- cleanup some unused/dead code
Fixes#16668
* perf(contacts): make initial contacts fetching async
Fixes#16509
* fix: don't fetch contact if we don't have it in cache
Fixes#16509
* feat: add a visible loading indicator when the chats are not ready yet
Fixes#16602
This was broken when we refactored the members to use a single model for public channels. Those public channels then didn't have any members in their model they used for suggestions.
This is fixed by putting the logic in the UsersStore and reusing that store whenever we need a list of the members.
There are a few things improved in this commit:
- the account the username was bought with is selected for releasing
- if the account was removed in meantime, we warn user displaying a popup message
- ETH token is selected
- 0 value is set
Fixes#16611
* chore: remove old code about ID verification
* refactor(trust): remove untrustowrthy and isVerified from items and use trustStatus
* chore(status-go): up status-go to get fix for trustStatus reseting
Fixes#16392
* chore: remove verified/trusted profile showcase category
- this adds direct access to sending invitations to new ppl (aka adding
members), instead of going thru the secondary nav context menu
- the new community context menu will be tackled in a separate
task/issue
Fixes#16597
ChartStoreBase -> ChartDataBase
TokenBalanceHistoryStore -> TokenBalanceHistoryData
TokenMarketValuesStore -> TokenMarketValuesData
Those components store data without any interaction with the backend.
Therefore they are not stores.
Closes: #16295
- legacy Style and ThemePalette removed
- moved and deduplicated font definitions into `Theme` (unrelated to a
color palette)
- `Style.current.foo` -> `Theme.foo`
- `Style.current.fooColor` -> `Theme.palette.fooColor`
- upgrade the imports to 5.15
- removed some mode dead components
Fixes#16514
- enable the Next button, and delay the validation after it's been clicked
- visually display required fields also for logo, banner, and tags (min
1 tag is required now)
- when pasting over limit, chop the text to the maximum length, instead
of just leaving the text field empty
- do not let the popup autoclose on clicking outside or pressing Esc
- add a StoryBook page
- minor cleanups and alignments to the latest Figma designs/flows
Fixes#13966Fixes#16479Fixes#14902
Fixes#16288
Introduces a new instance of the users module, but managed by the section module.
This user module is managing the "public" community members list. Meaning that everytime we have a public channel in a community, we use that module instead.
The channel's user module is empty for public channels to reduce the amount of processing and memory used.
If the channel becomes private, we update the member list and populate it.
There were two version of plainText - one exposed from the backend,
another, backend-independent in StringUtils. The latter one is now
used in all cases.
- fix a refactoring bug in the stores
- disable the context menu since it's not really usefull and we're still
missing like a dozen of stores needed for MessageView anyway
- propagate and set `requiresPermissions` + `locked` from the
`chatContentModule.chatDetails`
- set the icon accordingly for community chats
Fixes#16502
* fix: force focus on search inputs in permissions and sort members
* fix(admin): fix freezes when community gets updated
* fix(airdrop): use FastExpressionFilter to speed up
Iterates #16043
When the community gets updated by any means, we reconstruct the section item, which is already bad, but we also re-fetch all tokens and all shared addresses, which in turn re-updates models for no reason.
Instead, I make sure to only fetch those on first section build, then, I get the new shared addresses when members join using the request to join response that comes from status-go
Implementing the user-story for sign request expiry and add qml tests
+ other minor fixes
## Acceptance Criteria
```
//Always show the expiration
Given the sign/transaction request dialog is shown
When request has an expiration date
Then the user sees a 1 minute countdown in the dialog
```
```
// Show 1 minute timer
Given the sign/transaction request dialog is shown
When the request has 1 minute or less before expiring
Then the user sees a 1 second countdown in the dialog
```
```
Given the sign/transaction dialog is open
When the request expires
Then the Accept button is removed
And the only option for the user is to close the dialog
```
```
Given the sign/transaction request dialog is open
When the request expired
Then the `Sign` and `Reject` buttons are removed
And the `Close` button is visible
```
```
Given the sign/transaction request expired
Then a toast message is showing
And it contains the "<dapp domain> sign request timed out" message
```
```
Given the sign/transaction request dialog is open
When the request expired
Then the sign/transaction request dialog is still visible
```
```
Given the sign/transaction request expires
Then a console message is shown
And it contains 'WC WalletConnectSDK.onSessionRequestExpire; id: ${id}`'
```
- do not allow DND when the StatusChatInput is disabled
- remove `Global.dragArea` variable from the Global singleton
- move the `DropAreaPanel` into `StatusChatInput` and handle its
enabling from there
Fixes#16451
This commit brings a separation of concerns for the UI components involved in dApp interactions.
Issue: The UI components depend on the WalletConnectService and also on its dependencies like DAppsRequestHAndler. As a result the UI components have a hard dependency on the WalletConnect specifics and are incompatible with BC. This results in duplication of logic.
Issue: The UI components operate on WalletConnect specific JSON object. E.g. session objects, session proposal etc. As a result the UI is built around the WalletConnect message format.
Issue: The UI components operate on ListModel items received through functions and stored internally. Any change in the model would result in a crash.
Solution: Remove the WalletConnectService dependency from DAppsWorkflow. The DAppsWorkflow now operates with models, signals and functions. This is the first step in the broader refactoring. Moving the logic into the service itself will allow us to further refactor the WC and BC.
How does it work now:
Dependencies - The UI components have a dependency on models. SessionRequestsModel and DAppsModel.
Pairing - The pairing is initiated in the UI. On user input a pairingValidationRequested signal is emitted and the result is received as a function pairingValidated. If the url is valid the UI requests a pairingRequested. When the WalletConnectService is refactored we can go further and request only pairingRequested and to receive a pairingResult call as a function with the result. In the current implementation on pairingRequested we'll receive a connectDApp request.
Connecting dApps - The flow is initiated with connectDApp function. This call currently contains all the needed info as args. In the next step it could be replaced with a ConnectionRequests model. The connectDApp call triggered a connection popup if we're not currently showing one to the user. If we're currently showing one it will be queued (corner case). The connection can be accepted with connectionAccepted and rejected with connectionDeclined. Once the connection is accepted we're expecting a result connectionSuccessful or connectionFailed. The connectionSuccessful also expects a new id for the established connection.
Signing - The signing flow orbits around the SessionRequestsModel. Each item from the model will generate a popup showing the sign details to the user. Sign can be accepted or rejected using signRequestAccepted or signRequestRejected. No response is currently expected. The model is expected to remove the sign request item.
- hide the permission from the `PermissionsRow` when it's set to private
and the conditions are not met
- display a tooltip "(Not) eligible to join" over the lock icon
- show the same info in both community portal and profile dialog's
community showcase tab
- speedup searching/filtering in the community portal
- fixup and extend the SB pages to demonstrate the new behavior
Fixes#14747
Based on changes done in this PR https://github.com/status-im/status-go/pull/5807
we can simplify our client logic a lot.
This results in the removal of many lines of code that are no longer needed
Closes 2nd part of #16336
Lukáš Tinkl
Anthony
Michał Cieślak
Dario Gabriel Lipicar
Sale Djenic
Jonathan Rainville
Anastasiya Semenkevich
Khushboo Mehta
Cuteivist
Alex Jbanca