docs: add summary to group endpoints for openapi docs📝

[shivamvijaywargi]

No description provided.

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (2)

src/modules/group/group.handler.ts:342

• [nitpick] The error message 'Some or all the Users you are trying to add already exists in group' is unclear. Consider rephrasing it to 'Some or all of the users you are trying to add already exist in the group'.

message: "Some or all the Users you are trying to add already exists in group",

src/modules/group/group.handler.ts:327

• Ensure that the new behavior introduced by 'usersExistsInGroupRepository' is covered by tests.

const usersExistsInGroup = await usersExistsInGroupRepository(

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (2)

src/modules/group/group.handler.ts:332

• The condition should check if usersExistsInGroup is not empty to handle cases where the array is undefined or null. Use if (usersExistsInGroup && usersExistsInGroup.length) {.

if (usersExistsInGroup.length) {

src/modules/group/group.handler.ts:333

• [nitpick] The variable existingUserIds should be renamed to existingUserIdsInGroup for better clarity and consistency with the function name.

const existingUserIds = usersExistsInGroup.map(user => user.userId);

[sub1120]

@shivamvijaywargi @NiteshSoma after seeing this PR, i have one doubt - Do we have a route which will return users of a particular group, because in frontend users adding screen, we have to hide users which are already part of that group so this validatation will not fail. If possible we can return users details in GET /api/v1/group/:id​ itself.

[NiteshSoma]

@shivamvijaywargi @NiteshSoma after seeing this PR, i have one doubt - Do we have a route which will return users of a particular group, because in frontend users adding screen, we have to hide users which are already part of that group so this validatation will not fail. If possible we can return users details in GET /api/v1/group/:id​ itself.

@sub1120 I am actually working on that issue where we get back user details in getGroupById

[sub1120]

@shivamvijaywargi @NiteshSoma after seeing this PR, i have one doubt - Do we have a route which will return users of a particular group, because in frontend users adding screen, we have to hide users which are already part of that group so this validatation will not fail. If possible we can return users details in GET /api/v1/group/:id​ itself.

@sub1120 I am actually working on that issue where we get back user details in getGroupById

Ooh nice.

@shivamvijaywargi @NiteshSoma after seeing this PR, i have one doubt - Do we have a route which will return users of a particular group, because in frontend users adding screen, we have to hide users which are already part of that group so this validatation will not fail. If possible we can return users details in GET /api/v1/group/:id​ itself.

@sub1120 I am actually working on that issue where we get back user details in getGroupById

Oh Nice! Then we are good.

[sub1120]

Looks good to me.