Previously, our docs had links to various versions of the Django docs, eg https://docs.djangoproject.com/en/1.10/topics/migrations/ and https://docs.djangoproject.com/en/2.0/ref/signals/#post-save, opening a link to a doc with an outdated Django version would show a warning "This document is for an insecure version of Django that is no longer supported. Please upgrade to a newer release!". This commit uses a search with the regex "docs.djangoproject.com/en/([0-9].[0-9]*)/" and replaces all matches inside the /docs/ folder with "docs.djangoproject.com/en/3.2/". All the new links in this commit have been generated by the above replace and each link has then been manually checked to ensure that (1) the page still exists and has not been moved to a new location (and it has been found that no page has been moved like this), (2) that the anchor that we're linking to has not been changed (and it has been found that this happened once, for https://docs.djangoproject.com /en/1.8/ref/django-admin/#runserver-port-or-address-port, where /#runserver-port-or-address-port was changed to /#runserver).
1.8 KiB
Clients in Zulip
zerver.models.Client is Zulip's analogue of the HTTP User-Agent
header (and is populated from User-Agent). It exists for use in
analytics and other places to provide human-readable summary data
about "which Zulip client" was used for an operation (e.g. was it the
Android app, the desktop app, or a bot?).
In general, it shouldn't be used for anything controlling the behavior of Zulip; it's primarily intended to assist debugging.
Analytics
A Client is used to sort messages into client categories such as
ZulipElectron on the /stats page. For more information see,
Analytics.
Integrations
Generally, integrations in Zulip should declare a unique User-Agent, so that it's easy to figure out which integration is involved when debugging an issue. For incoming webhook integrations, we do that convenentialy via the auth decorators (as we will describe shortly); other integrations generally should set the first User-Agent element on their HTTP requests to something of the form ZulipIntegrationName/1.2 so that they are categorized properly.
The webhook_view auth decorator, used for most incoming
webhooks, accepts the name of the integration as an argument and uses
it to generate a client name that it adds to the request_notes
object that can be accessed with the request (Django
HttpRequest)
object via zerver.lib.request.get_request_notes(request).
In most integrations, request_notes.client is then passed to
check_send_webhook_message, where it is used to keep track of which client
sent the message (which in turn is used by analytics). For more
information, see the incoming webhook walkthrough.