[FIX] UI was not disabling the actions when users has had no permissions to create channels or add users to rooms

[chuckAtCataworx]

Closes #10508
Closes #10200

This fix will
-Hide + icon in the top right of the directory to users who don't have permission to create channels and groups.
-If the user has only one of the two create room permissions (create-c, create-p), it will prevent user from changing between both room types. Only display the room type they can create.

-Hide addUser Icon in the flexTabBar if user doesn't have the permission to add user to any channel, or add user to joined room when in channels.

• Hide addUser Icon in the flexTabBar if user doesn't have the permission to add user to any private group, or add user to joined room when in private groups.

-When the icon is removed the additional tab bar buttons are kept in their place, and not duplicated

[gdelavald]

Does this happen on create-channel as well? Need to make sure the room is created before he is able to add-user-to-joined-room.

[chuckAtCataworx]

Yes. I think your comment on the createChannel.js file looks like you saw where that happens. I could take a look at how we use the add-user-to-joined-room permission. In this implementation the user needs the permissions 'add-user-to-any-c-room'('add-user-to-any-p-room' for groups) or 'add-user-to-joined-room' to view the 'add users' button. Perhaps it should only rely on the 'add-user-to-joined-room'? It is as simple as deleting the two const 'canAddToChannel' and 'canAddToGroup' then removing them from the if statement on line 202 and 206.

[gdelavald]

Yep, checking the permissions page show that users do not have the add-user-to-any-p-room (same for c) by default, and only admins do. Also there could be cases where users don't have the add-user-to-joined-room permission (which would be weird, but could happen) and the former permission should overrule this one.
I'm doing some tests on the PR deployment to check for edge cases.

[chuckAtCataworx]

I had a slight mistake in my comment in describing the behavior, I edited the comment to reflect the actual behavior of what is coded. Which is what I think should correctly handle the expected behavior. The mistake was saying you need both permissions to view, but corrected to say one or the other.

[gdelavald]

👍

[ggazzo]

use

this.type = new ReactiveVar(RocketChat.authz.hasAllPermission(['create-p']) ? 'p' : 'c')

[ggazzo]

@chuckAtCataworx could you change this code to

<input type="checkbox" class="rc-switch__input" name="type" value="p" checked="{{helperTestingIfTypeEqualtoP}}" disabled="{{cantCreateBothTypes}}"/>

[ggazzo]

you dont need this variable

[chuckAtCataworx]

Removing this variable creates a potential issue. When the add users button isn't displayed, then files list gets duplicated. It stays in it's original more section and takes the place of the add users button

[ggazzo]

remove ;)

[ggazzo]

remove ;)

[ggazzo]

remove ;)

[ggazzo]

instead of {{#if canCreateBothTypes}} use
<input type="checkbox" class="rc-switch__input" name="type" value="p" checked={{testIfTypeEqualP}} disabled="{{cantCreateBothTypes}}">

[ggazzo]

use

this.type = new ReactiveVar(RocketChat.authz.hasAllPermission(['create-p']) ? 'p' : 'c')

[ggazzo]

@chuckAtCataworx hey thanks for contribute!! could you fix this items? its done after that :)