Remove deactivated users from groups

[gnprice]

For current servers starting with zulip/zulip#29498 (server-10, ZFL 303), deactivated users are no longer members of any groups.

On the client side, the change this requires is that when we get a realm_user/update event saying a user was deactivated, we should remove them from all groups. See API docs.

Chat thread: https://chat.zulip.org/#narrow/stream/378-api-design/topic/Groups.20events.20for.20deactivated.20users/near/1958907

[chrisbobbe]

I haven't read much of the chat thread, but I read the API changelog for 303 in main just now:

https://github.com/zulip/zulip/blob/9b7a4c89e/api_docs/changelog.md#changes-in-zulip-100
https://raw.githubusercontent.com/zulip/zulip/9b7a4c89e/api_docs/changelog.md

**Feature level 303**

* [`POST /register`](/api/register-queue), [`GET /user_groups`](/api/get-user-groups),
  [`GET /user_groups/{user_group_id}/members/{user_id}`](/api/get-is-user-group-member),
  [`GET /user_groups/{user_group_id}/members`](/api/get-user-group-members):
  Deactivated users are no longer returned as members of the user groups
  that they were members of prior to deactivation.
* [`POST /register`](/api/register-queue): Settings, represented as
  [group-setting value](/api/group-setting-values), will never include
  deactivated users in the `direct_members` list for settings whose
  value is an anonymous group.
* [`POST /user_groups/{user_group_id}/members`](/api/update-user-group-members):
  Deactivated users cannot be added or removed from a user group; they
  are now implicitly not members of any groups while deactivated.
* [`GET /events`](/api/get-events): User reactivation event is not sent
  to users who cannot access the reactivated user anymore due to a
  `can_access_all_users_group` policy.
* [`GET /events`](/api/get-events): The server will now send
  `user_group` events with the `add_members`/`remove_members`
  operations as appropriate when deactivating or reactivating a user,
  to ensure client state correctly reflects groups never containing
  deactivated users.
* [`GET /events`](/api/get-events): To ensure that [group-setting
  values](/api/group-setting-values) are correct, `realm/update_dict`
  and `user_group/update` events may now be by sent by the server when
  processing a deactivation/reactivation of a user, to ensure client
  state correctly reflects the state, given that deactivated users
  cannot have permissions in an organization.

and in particular that next-to-last bullet:

* [`GET /events`](/api/get-events): The server will now send
  `user_group` events with the `add_members`/`remove_members`
  operations as appropriate when deactivating or reactivating a user,
  to ensure client state correctly reflects groups never containing
  deactivated users.

We do have code that handles add_members and remove_members, and that code looks fine on a quick skim. Do we have to do anything else here?

[gnprice]

Hmm. I believe the outcome of that #api design thread was that there are circumstances where we do need to act.

I think the story may be:

• If we get a "user was deactivated" event, then we won't get corresponding "user removed from groups" events; the client needs to draw that inference for itself.
• But there are circumstances where we know the user's membership in groups, yet won't get an event saying they were deactivated. (In particular if we're a guest user that doesn't have permission to see that user's details.) So when that's the case, the server will send the "user removed from groups" events instead.

It looks like the notes added to individual pages in the API docs in that same PR:
https://github.com/zulip/zulip/pull/29498/files#diff-7d09c06f7ab16ed46eeff8eb6e1a342f75fc9f3c780c6f10643303145316581e
confirm that story.

Definitely that changelog entry is confusing, though. It should clarify that "as appropriate" only means when the client isn't going to get a "user was deactivated" event. So that'd be good to bring up on that #api design thread. (Or could be on #api documentation; but it should be a short followup, so might as well be on the thread with history.)

[chrisbobbe]

So that'd be good to bring up on that #api design thread. (Or could be on #api documentation; but it should be a short followup, so might as well be on the thread with history.)

Sure, makes sense: https://chat.zulip.org/#narrow/channel/378-api-design/topic/Groups.20events.20for.20deactivated.20users/near/1979327