fix: show only relevant userInfoActions for mentioned non-members

[abhinavkrin]

Proposed changes (including videos or screenshots)

This pull request addresses an issue in the user mention functionality within Rocket.Chat channels. Previously, when a user mentioned another user who was not a member of the channel, the User Info card still displayed options like 'Remove User', 'Set as Leader', 'Set as Moderator', etc., which were not applicable for non-members. This fix introduces a check to determine if the mentioned user is a member of the channel/group. If the user is not a member, it now shows an option to 'Add User' to the channel and omits inappropriate options for non-members.

1. Implemented an API to verify if the mentioned user is a member of the channel/group/dm.
2. Display 'Add User' option if the mentioned user is not a member of the channel.
3. Hide options like 'Remove User', 'Set as Leader', 'Set as Moderator', etc., for non-members.

add-user-2024-01-24_17.28.08.mp4

Issue(s)

When a user mentions another user who was not a member of the channel, the User Info card still displays options like 'Remove User', 'Set as Leader', 'Set as Moderator', etc., which are not applicable for non-members
Also
Fixes #31712

Steps to test or reproduce

1. Mention a user who is not a member of the channel.
2. Observe the options available in the User Info card.
3. 'Add User' option should be visible while options like 'Remove User', 'Set as Leader', 'Set as Moderator' should not be available for non-members.

Further comments

TC-1079

Justification for New Endpoint room.isMember

We considered using channels.members/groups.members with filters for membership checks but faced issues:

1. User Matching: Regex filters might return similar, not exact, usernames, causing inaccuracies.
2. Pagination: If results exceed LIMIT_PER_PAGE, the target user might not appear on the first page, requiring extra API calls.
3. Performance: Regex searches are slower than direct comparisons.
   To ensure precise and efficient user membership verification, we introduced the room.isMember endpoint, circumventing the limitations of existing endpoints and ensuring a more reliable and performant solution.

[changeset-bot]

🦋 Changeset detected

Latest commit: 22bd817

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 34 packages

Name	Type
@rocket.chat/rest-typings	Patch
@rocket.chat/meteor	Patch
@rocket.chat/i18n	Patch
@rocket.chat/api-client	Patch
@rocket.chat/core-services	Patch
@rocket.chat/ddp-client	Patch
@rocket.chat/ui-contexts	Patch
@rocket.chat/account-service	Patch
@rocket.chat/authorization-service	Patch
@rocket.chat/ddp-streamer	Patch
@rocket.chat/stream-hub-service	Patch
@rocket.chat/omnichannel-services	Patch
@rocket.chat/presence	Patch
rocketchat-services	Patch
@rocket.chat/mock-providers	Patch
@rocket.chat/web-ui-registration	Patch
@rocket.chat/omnichannel-transcript	Patch
@rocket.chat/presence-service	Patch
@rocket.chat/queue-worker	Patch
@rocket.chat/livechat	Patch
@rocket.chat/fuselage-ui-kit	Patch
@rocket.chat/gazzodown	Patch
@rocket.chat/ui-avatar	Patch
@rocket.chat/ui-client	Patch
@rocket.chat/ui-video-conf	Patch
@rocket.chat/uikit-playground	Patch
@rocket.chat/core-typings	Patch
@rocket.chat/apps	Patch
@rocket.chat/cron	Patch
@rocket.chat/model-typings	Patch
@rocket.chat/license	Patch
@rocket.chat/pdf-worker	Patch
@rocket.chat/models	Patch
@rocket.chat/instance-status	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 59.38%. Comparing base (c225451) to head (22bd817).
Report is 2 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #31525      +/-   ##
===========================================
- Coverage    59.38%   59.38%   -0.01%     
===========================================
  Files         2547     2547              
  Lines        63238    63227      -11     
  Branches     14224    14217       -7     
===========================================
- Hits         37557    37546      -11     
  Misses       22974    22974              
  Partials      2707     2707              

Flag	Coverage Δ
unit	75.84% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[debdutdeb]

could we not use subscription.getOne endpoint instead?

[abhinavkrin]

could we not use subscription.getOne endpoint instead?

Hey @debdutdeb, sorry for delayed reply.
The use-case is different here, I have created endpoints to check if another user is member of a channel/group/member or not.

[debdutdeb]

Right. But I don't think you need all these endpoints. Membership is a subscription. So one endpoint should be sufficient, like subscription.exists?uid=..&rid=.... Furthermore, nobody can leave a dm, so a case where you need to check for user exists in a dm or not shouldn't come up in this context.

[debdutdeb]

Rocket.Chat/apps/meteor/server/services/authorization/canAccessRoom.ts

Lines 55 to 62 in ed45125

	async function _validateIfAlreadyJoined(room, user): Promise<boolean> {
	if (!room?._id || !user?._id) {
	return false;
	}
	if (!(await Subscriptions.countByRoomIdAndUserId(room._id, user._id))) {
	return false;
	}

[debdutdeb]

also idk if client caches the memberlist, might be a good idea to utilize if it does.

[abhinavkrin]

Right. But I don't think you need all these endpoints. Membership is a subscription. So one endpoint should be sufficient, like subscription.exists?uid=..&rid=.... Furthermore, nobody can leave a dm, so a case where you need to check for user exists in a dm or not shouldn't come up in this context.

Thanks for the input @debdutdeb. I did not know about subscriptions earlier.
Indeed, I created an endpoint subscriptions.exists?roomId=...&username=.... to check a user's membership for which I am checking whether a subscription exists for them or not. I have applied appropriate validation so that unauthorized users cannot access this endpoint.

[abhinavkrin]

also idk if client caches the memberlist, might be a good idea to utilize if it does.

This was my initial approach, but the member list functionality does a search and receives a paginated result. So there is no guarantee that the required username would be present in the result or not.

stale