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.
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.
* refactor: rely on canPost and canView instead of checking permissions
Fixes#14983
* chore: remove all Light permission checks that are no longer needed
When channel has view-only permission not requiring any holdings, the
channel is not encrypted and should be presented to non-members in
read-only mode.
Closes: #14439
- implement the eligibility check in C++, returning the highest possible
role the user would be allowed to join under
- enable/disable the "Share" button based on the above permissions check
- remove all the locally placed components, access teh popup only via
Global/Popups
- calculate the `accessType` internally based on the permissions present
- update the eligibility as the async check for permissions is finished
- fix the permissions panel background color
- partially revert the share/finish/cancel buttons behavior; it must be
one button due to StatusStackModal limitations
- fix some other minor UI issues or differences to current Figma designs
- adjust SB, add the possibility to play around with different
permission models
Fixes#14100
* fix(JoinCommunity): Add missing state ONLY private permissions and NOT MET
- Modified `becomeMemberModel` in store to provide all member permissions.
- Modified permissions model filter to only discard permissions that are private and NOT met.
- Updated `storybook/PermissionsModel` with new only private permissions and added new model option in corresponding pages.
Closes#14104
* fix(JoinCommunity): Text position when all channels hidden
Updated text position when `allChannelsAreHiddenBecauseNotPermitted` in community join process
- Change text and remove existing icon.
- Removed unnecessary property `loginType` on different files.
- Renamed signals to be more accurate with existing requirements.
Closes#14098
* feat(@desktop/communities): Hide channels if the user is not permitted to view and hideIfPermissionsNotMet is set
Extend chats model with channel permissions info and hideIfPermissionsNotMet.
Visibility of chat item is based on: member roles, channel permissions, hideIfPermissionsNotMet.
If all channels from category are hidden, category item is also hidden.
If all chats in community are hidden, infomration label is displayed.
Issue #13291
* chore(@desktop): Upgrade status-go
Issue #13291
Fixes#13779
The problem was that the permission update some times takes time to get propagated and get back, or even the control node is offline, so the TM would not be able to post, because the backend would detect that there is a permission and that we don't have the key for it.
The solution is to block the UI when a permission update is pending, since we can't post correctly while it is not processed by he control node.
- extend `isUserAllowedToSendMessage` to also cover
`Constants.chatType.communityChat`
- let `admin` always satisfy the permissions
- hide the add emoji/reaction button instead of disabling it when the
permissions are not met
- adjust the error msg to better reflect the reality (tokens vs.
permissions)
Fixes#13777
Changes:
1. Make PermissionsView/EditPermissionsView configurable to support channel permissions config
2. Adding channel permissions support in the create/edit channel popup
3. Connect the channel permissions to backend
4. Cleaning unneeded emojiPopup
- Button from community column.
- Button from community overview.
- Updated storybook pages (settings overview related) according to new components requirements.
Part of #12174
- Renamed main `CommunitiesPortal` folder to `Communities`.
- Created new `layouts` folder.
- Moved layout files from chat to communities.
- Created new `helpers` folder.
- Moved helpers files from chat to communities.
- Moved `controls/community` files from chat to communities `controls`.
- Moved `panels/communities` files from chat to communities `panels`.
- Moved `popups/community` files from chat to communities `popups`.
- Moved `views/community` files from chat to communities `views`.
- Moved `CommunityBanner` file from shared to `Communities/controls`. Only used in communities context.
- Moved `CommunitySettingsView` and `CommunityColumnView` files from chat to communities `views`.
- Moved `PermissionsStore.qml` file to `shared/stores`.
- Updated imports.
- Updated storybook.
Part of #6204
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.
- CommunitiesPortalLayout was the last piece still unconditionally loaded
on startup -> fixed
- extract the `communitiesStore` into AppMain to be able to reuse it from
other components
- move the import/create community dialogs to `Popups` (reusability)
- cleanup and remove some dead code, fix warnings
Iterates #6204
the button to (un)install would be either greyed out or result in a crash:
- we were passing the popup a wrong store (w/o networkConnectionStore)
- the condition to `greyedOut` was inverted
Lukáš Tinkl
Michał Cieślak
Jonathan Rainville
Sale Djenic
Khushboo Mehta
Seitseman
Patryk Osmaczko
Mykhailo Prakhov
Noelia
Noelia
Michał Iskierko
Alex Jbanca
Pascal Precht
Igor Sirotin
MishkaRogachev