Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

☂️ Handle all Zulip events to keep our data up to date #135

Open
22 of 72 tasks
gnprice opened this issue May 26, 2023 · 2 comments
Open
22 of 72 tasks

☂️ Handle all Zulip events to keep our data up to date #135

gnprice opened this issue May 26, 2023 · 2 comments
Labels
a-api Implementing specific parts of the Zulip server API a-model Implementing our data model (PerAccountStore, etc.)
Milestone

Comments

@gnprice
Copy link
Member

gnprice commented May 26, 2023

We'll want to handle essentially all the events that can appear through the Zulip event system:
https://zulip.com/api/get-events#events

Some of these are correctness issues in the early prototype: we're tracking the data they would update, but are not handling the update, so our data goes stale. Others are not correctness issues because we're not yet tracking that data in the first place, but are for data we do intend to track before launch. Both those categories are in scope for this issue.

Out of scope for this issue: A few event types are for data that is only needed for areas of UI that we don't have in zulip-mobile and don't intend to have in zulip-flutter before launch. E.g., attachment, which is for web's #settings/uploaded-files screen.

Event types

  • Edit this description to have a complete list of event types. (Include the types that are already handled or are out of scope; just mark them as such.)

For alpha

For beta

For launch

For post-launch

Post-launch other than realm settings UI

  • has_zoom_token
  • realm/deactivated
  • subscription/peer_add
  • subscription/peer_remove
  • attachment/add
  • attachment/update
  • attachment/remove
  • drafts/add
  • drafts/update
  • drafts/remove
  • scheduled_messages/add
  • scheduled_messages/update
  • scheduled_messages/remove

For realm settings UI

  • default_stream_groups
  • default_streams
  • realm_playgrounds
  • realm_domains/add
  • realm_domains/change
  • realm_domains/remove
  • realm_export
  • realm_user_settings_defaults/update
  • invites_changed
  • realm_bot/add
  • realm_bot/update
  • realm_bot/remove
  • realm_bot/delete

Never

Obsolete

  • update_display_settings
  • update_global_notifications

Specific to web

  • hotspots
@gnprice gnprice added the m-beta label May 26, 2023
@gnprice
Copy link
Member Author

gnprice commented May 26, 2023

I've given this the "beta" milestone, but there may be specific events we decide can wait for launch or even beyond. What's needed for beta is really just that we should look at the list and make any such choice explicitly. -> Filed #308 for this part.

@gnprice gnprice added the a-api Implementing specific parts of the Zulip server API label May 26, 2023
@gnprice gnprice added this to the Beta milestone May 27, 2023
@gnprice gnprice added a-model Implementing our data model (PerAccountStore, etc.) and removed m-beta labels May 27, 2023
chrisbobbe added a commit to chrisbobbe/zulip-flutter that referenced this issue Aug 1, 2023
Now, as demonstrated in the new test, if the author of a message
changes their avatar, we'll see the update in the message list as
soon as we get the event.

While we're at it, comment out the property on [Message] to guide
future consumers to [User].

Related: zulip#135
chrisbobbe added a commit to chrisbobbe/zulip-flutter that referenced this issue Aug 1, 2023
Now, as demonstrated in the new test, if the author of a message
changes their avatar, we'll see the update in the message list as
soon as we get the event.

While we're at it, comment out the property on [Message] to guide
future consumers to [User].

Related: zulip#135
chrisbobbe added a commit to chrisbobbe/zulip-flutter that referenced this issue Aug 2, 2023
Now, as demonstrated in the new test, if the author of a message
changes their avatar, we'll see the update in the message list as
soon as we get the event.

While we're at it, comment out the property on [Message] to guide
future consumers to [User].

Related: zulip#135
chrisbobbe added a commit to chrisbobbe/zulip-flutter that referenced this issue Aug 2, 2023
Now, as demonstrated in the new test, if the author of a message
changes their avatar, we'll see the update in the message list as
soon as we get the event.

While we're at it, comment out the property on [Message] to guide
future consumers to [User].

Related: zulip#135
chrisbobbe added a commit to chrisbobbe/zulip-flutter that referenced this issue Aug 3, 2023
Now, as demonstrated in the new test, if the author of a message
changes their avatar, we'll see the update in the message list as
soon as we get the event.

While we're at it, comment out the property on [Message] to guide
future consumers to [User].

Related: zulip#135
gnprice pushed a commit to chrisbobbe/zulip-flutter that referenced this issue Aug 3, 2023
Now, as demonstrated in the new test, if the author of a message
changes their avatar, we'll see the update in the message list as
soon as we get the event.

While we're at it, comment out the property on [Message] to guide
future consumers to [User].

Related: zulip#135
@gnprice gnprice modified the milestones: Beta, Launch Sep 22, 2023
@gnprice
Copy link
Member Author

gnprice commented Oct 31, 2023

I've just gone through the list of all events in the server API, triaged them, and updated the issue description.

That was as of Zulip feature level 219, commit zulip/zulip@37b261e, for reference if updating the list for future server API changes.

For entertainment and future convenience, here's the pair of commands I used to get the list:
python -c 'import yaml, json; print(json.dumps(yaml.safe_load(open("zerver/openapi/zulip.yaml"))))' >tmp.json

<tmp.json jq '.paths["/events"].get.responses["200"].content["application/json"].schema.allOf[1].properties.events.items.oneOf[] | {type: .properties.type.allOf[1].enum[0], op: .properties.op?.enum[0]} | .type + if .op == null then "" else "/" + .op end' -r

The first command converts zerver/openapi/zulip.yaml (from the zulip/zulip tree) from YAML to JSON. The second command pulls out the event types. It gets tripped up on a couple of entries which use allOf differently, printing blank lines instead, so one can fix those up by hand. (Namely reaction/add and reaction/remove.) A robust version of this would have the allOf handled up front before trying to use jq.

And here's a complete list of the events, reordered lightly to group them logically, before triage:

All event types, grouped logically
Infra:
heartbeat
restart

Realm/server settings:
has_zoom_token
custom_profile_fields
default_stream_groups
default_streams
realm_linkifiers
realm_filters
realm_playgrounds
realm_emoji/update
realm_domains/add
realm_domains/change
realm_domains/remove
realm_export
realm/update
realm/update_dict
realm/deactivated
realm_user_settings_defaults/update

User settings:
alert_words
update_display_settings
update_global_notifications
user_settings/update
hotspots

Users, groups:
realm_user/update
realm_user/add
realm_user/remove
invites_changed
presence
user_status
muted_users
user_group/add
user_group/update
user_group/add_members
user_group/remove_members
user_group/add_subgroups
user_group/remove_subgroups
user_group/remove
realm_bot/add
realm_bot/update
realm_bot/remove
realm_bot/delete

Streams, subs:
stream/create
stream/delete
stream/update
subscription/add
subscription/remove
subscription/update
subscription/peer_add
subscription/peer_remove
muted_topics
user_topic

Messages:
message
reaction/add
reaction/remove
attachment/add
attachment/update
attachment/remove
submessage
delete_message
update_message
typing/start
typing/stop
update_message_flags/add
update_message_flags/remove
drafts/add
drafts/update
drafts/remove
scheduled_messages/add
scheduled_messages/update
scheduled_messages/remove

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-api Implementing specific parts of the Zulip server API a-model Implementing our data model (PerAccountStore, etc.)
Projects
Status: No status
Development

No branches or pull requests

1 participant