-
Notifications
You must be signed in to change notification settings - Fork 322
Description
Identified as an issue while working on #440 - the Zulip server will automatically mark messages as read for their authors if the client that sent the request is internally identified as a human-powered client (in other words, the message came from an app of some sort rather than a python script).
See sent_by_human
in https://github.com/zulip/zulip/blob/main/zerver/models.py#L3238
The name of the client is pulled from the User-Agent header. An initial PR to close #440 was proposed in #450, but that only added a hardcoded User-Agent string as crafting an appropriate one (to match https://github.com/zulip/zulip-mobile/blob/main/src/utils/userAgent.js ) was fraught inside of lib/api/core.dart
. Pulling the necessary information out of package_info_plus
there broke over a hundred tests as the infrastructure for calculating those values wasn't set up yet.
I think there are a couple options here:
- Continue the work of dynamically crafting a User-Agent at
send
inlib/api/core.dart
, figure out the tests. - Craft the User-Agent at a higher level layer, and send that through into the api (such as how we pass
zulipFeatureLevel
orrealmUrl
when creating anApiConnection
).
From a cursory look there doesn't appear to be any other use of sent_by_human
with other api endpoints, so perhaps this is something that we only need to send when creating a message?
Also see related links:
- PR against zulip to add
zulipflutter
to whitelist: Add "zulipflutter" to the whitelist insent_by_human
zulip#28198 - CZO discussion: https://chat.zulip.org/#narrow/stream/378-api-design/topic/zulip-flutter.20user.20agent/near/1702186
Additionally, there is a PR in zulip/zulip#28204 that proposes a read_by_sender
flag in the API. We could take advantage of this, but will still need a User-Agent for legacy servers.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status