[FIX] Revert breaking change to groups.list API: 404 vs. empty list

[nmagedman]

The commit 21b81e9a9 "Chore: Update Meteor 2.7.3 (#25991)" introduced a breaking change to two API endpoints, incidental to the task of updating Meteor.

• /api/v1/groups.list
• /api/v1/channels.list.joined

These two endpoints return the list of rooms a user is a member of. If the user is not a member of any room, it used to return an empty list, that is

{groups: [], total: 0}

RC v5.0.0 changed that behavior to return 404, which raises an exception in the wrapper library (as it should).

Requesting the list of private group memberships of a user who is not a member of any private groups should properly return an empty list, exactly as it used to. It is normal, not exceptional, for a user not to be a member of any private groups. An example of an appropriate use of HTTP status code 404 would be if we requested the list of private groups of a user who doesn’t exist.

Proposed changes (including videos or screenshots)

API calls that request a list of groups which meet some criteria should return an empty list when appropriate, rather than 404. This was the pre-v5.0.0 behavior.

[nmagedman]

test-ee has failed twice, with /licenses.isEnterprise returning false instead of the expected true.

From https://github.com/RocketChat/Rocket.Chat/actions/runs/3474403532/jobs/5807938967

  1) licenses
       [/licenses.isEnterprise]
         should pass if user has user role:

      AssertionError: expected { isEnterprise: false, success: true } to have property 'isEnterprise' of true, but got false
      + expected - actual

      -false
      +true

How can we move this PR forward?

[sampaiodiego]

hi @nmagedman , the changes are looking good. do you mind adding test cases for this behavior? if we had them in the first place, this breaking change would not happen :(

or if you can give us write access we can do it from here.. thx

[nmagedman]

@sampaiodiego @debdutdeb

hi @nmagedman , the changes are looking good. do you mind adding test cases for this behavior? if we had them in the first place, this breaking change would not happen :(

or if you can give us write access we can do it from here.. thx

I've been trying to get a local dev environment going so that I can work on test specs, however I have not been successful. I can't give you write access to the corporate repo from which I originally opened this PR, so I created a new PR (#27587) from a personal repo.

[nmagedman]

The new PR (mentioned above) has been merged. Closing this one.