Avoid repeating request.client = get_client(foo) 5 times, and
decouple the logic for determining the client name from how
we represent the client as an ORM object and piggyback it on the
Django request.
(imported from commit efdf81cbaf9599a5606da18e06d7ffe9b88aaf6f)
The "else" branch used to execute when it was not the case
case that HTTP_USER_AGENT was not in request.META. Now
it's more readable.
(imported from commit ea0664e89d8b3d94cd1c0f8667047461b149ba41)
Validators are similar to converters, but they don't have
to parse JSON, and they are told the name of the request
variable to help format error messages.
(imported from commit 3c33e301892519c67e70675006d5686d9f013353)
All of our other API arguments use "_" as the delimiter, so we're
migrating this to do that as well (except for the legacy send_message
usage, which we're just hoping will eventually shrink to nothing).
(imported from commit 40964cc08e0f94ba439a61e4f68ed500f74a554f)
Now that we've debugged the memory leak, I don't think we need this
anymore.
This reverts commit 1bdc7ee2f72bdebb1cdc94601247834a434614d6.
Conflicts:
puppet/zulip/files/cron.d/rabbitmq-numconsumers
puppet/zulip/files/supervisor/conf.d/zulip.conf
(imported from commit ff87f2aebcbc71013fa7a05aedb24e2dcad82ae6)
One quirk here is that the Request object is built in the
message_sender worker, not Tornado. This means that the request time
only counts time taken for the actual sending and does not account
for socket overhead. For this reason, I've left the fake logging in
for now so we can compare the two times.
(imported from commit b0c60a3017527a328cadf11ba68166e59cf23ddf)
I added the @wraps decorator, and I point request._query at the
function name to override the URL, since some of the internal
URLs have realm names and domain names in them. I basically
prefer the function names in most cases, so I just made this
automatic for zulip_internal functions, rather than having to
remember to address URL-vs.-function-name for every new endpoint.
(imported from commit 5583607f395be4dfae0bac31e1cdbffdf51fb3e8)
Here we introduce a new Django app, zilencer. The intent is to not have
this app enabled on LOCALSERVER instances, and for it to grow to include
all the functionality we want to have in our central server that isn't
relevant for local deployments.
Currently we have to modify functions in zerver/* to match; in the
future, it would be cool to have the relevant shared code broken out
into a separate library.
This commit inclues both the migration to create the models as well as a
data migration that (for non-LOCALSERVER) creates a single default
Deployment for zulip.com.
To apply this migration to your system, run:
./manage.py migrate zilencer
(imported from commit 86d5497ac120e03fa7f298a9cc08b192d5939b43)
If request._query is set in the call to update_user_activity(),
we will use that instead of request.META['PATH_INFO'] for
the query field of the UserActivity row we write.
(imported from commit fcee30098e1c7c5cb4195a1e5905fc7b88af804f)
This is for webhook API endpoints that only get passed in an api_key,
not an email. An example would be api_jira_webhook, and some of
the code is borrowed from there. The rest of the code is from
authenticated_api_view().
(imported from commit b5b2a4ea52f9b317f00357ef3142c76534fabf20)
This needs to be deployed to both staging and prod at the same
off-peak time (and the schema migration run).
At the time it is deployed, we need to make a few changes directly in
the database:
(1) UPDATE django_content_type set app_label='zerver' where app_label='zephyr';
(2) UPDATE south_migrationhistory set app_name='zerver' where app_name='zephyr';
(imported from commit eb3fd719571740189514ef0b884738cb30df1320)