The hope being that this is clearer that it's about inviting your
coworkers to your instance of the app, rather than about spreading the
love and telling your friends how great Humbug is.
(imported from commit 888576618cdb5469cbfa8964f2b53c7b5120627f)
This also has the property of fixing this for all forms-that-contain-modals
since the selector is more generic.
(imported from commit 18fd26dd94fe4f6f3fe9a01884b867a9d37993d0)
Since in the future we might want requests to add subscriptions to
include things like colors, in_home_view, etc., we're changing the
data format for the add_subscriptions API call to pass each stream as
a dictionary, giving a convenient place to put any added options.
The manual step required here is updating the API version in AFS
available for use with the zephyr_mirror.py system.
(imported from commit 364960cca582a0658f0d334668822045c001b92c)
Previously, it always failed because we had hooked up the API endpoint
to a function that doesn't exist.
(imported from commit b5269f6d8e385facae4362742fe69a422f6315b7)
This way we can return properties of the streams other than just their
names in future versions of the API without breaking old clients.
The manual step required is to deploy the updated version of
sync-public-streams on zmirror.humbughq.com when we deploy this code
to prod.
(imported from commit 42b86d8daa5729f52c9961dd912c5776a25ab0b4)
The previous API was very redundant, which meant that any refactoring
would result in lots of unnecessary changes.
(imported from commit e04f6cbd87c8f65d4eebbe6972d26998faa28a56)
I believe this should require no special work on deploy, since some
grepping of logs suggests we are not currently using this API query.
(imported from commit 240086f900c6680cbc90bf6a2f334a9e1f172df6)
Trying to check whether a Django model object is inside a set of other
Django models is not correct in general, e.g.:
UserProfile.objects.only("id").get(id=17) in set([UserProfile.objects.get(id=17)])
returns False.
This bug appears twice in the function, once when computing which
users were mentioned and again when pushing the flags through to
Tornado.
(imported from commit b09ed550258f9df2611e1b0a60f87c48a51830f8)
Previously, we were only checking whether the message was sent by you
for PMs, not for streams that you marked as notifiable.
(imported from commit 668e102e885aa347cceff376c1873c1c62aff997)
(Before it had been disabled only on prod/staging, but we are
removing it everywhere, motivated by making tests run faster.
In particular, the call to embedly_client.is_supported() was
expensive, as it went over the Internet.)
(imported from commit ea12bf6e7ae84ce7e8023a0d314ecc4c07cbc0a8)
This file is a dict mapping filenames like "min/api.js" to
"min/api.HEX_HASH_HERE.js". This will be useful later for figuring out
which hashed version of a generated file belongs to a specific deploy,
for reuse in future deploys with the same source files.
(imported from commit d03c408b37a4e2d494abd4b1577a70b5ff5c2e34)
Whereas `SITE_ROOT` referred to the directory where settings.py is
located, *all* actual uses of `SITE_ROOT` were joining it with `..` to
get the root of the git checkout, a much more useful value.
`DEPLOY_ROOT` now represents the root of the git checkout.
(imported from commit 351437f9a5801e5c7c08a3a97619e863144e5cc8)
Previously we had an issue that every other update_active_status
request for a particular realm would result in doing the expensive
query to compute the list of active users in that realm. It turned
out this was because on every update_active_status request, we'd queue
an event that would have the effect of clearing the cache, even if
nobody's tatus changed. This fixes that issue, by only clearing the
cache for a realm if someone's status actually changed (or the 60s
timeout expires).
(imported from commit d5b829fe255a31c8cecb58458738f1e72a2cf6de)
wget users report certificate errors on the API download, apparently
due to wget's lack of support for TLS SNI until recently. Adding www
to the download link should work around this problem. (Trac #1400)
(imported from commit 517375eb22532304a774d66549c50691504ecc93)
This improves the performance of the get_old_messages queries when
loading the home page by about a factor of 2.5x.
(imported from commit 581840a6ed7b391c9d9fde67f368fce816e567e2)
This is in preparation for having a case in which we query the
database directly to get the message flags, without going through a
UserMessage object.
(imported from commit d5218974680b0c4b028a84f3aae1c8242ceb08ce)
This decreases the average size of the message dicts in memcached by
about half, without any significant change in the overall performance
of the query. Since these message dicts are a significant fraction of
what we put in memcached, this seems like a worthwhile optimization.
(imported from commit 3896328074aa4344b8ac7c7ba7685f0a167ec7ad)
memcached stores objects sent to it using pickling, which is very
slow. We work around this by sending memcached strings (i.e. JSON
dumps); pickling doesn't slow things down too much if all it is
getting is a string.
(imported from commit 0f0e534182eccb76c5731198e05a9324a1cef316)
This saves something like 15ms on our 1000 message get_old_messages
queries, and will save even more when we start sending JSON dumps into
our memcached system.
We need to install python-ujson on servers and dev instances before
pushing this to prod.
(imported from commit 373690b7c056d00d2299a7588a33f025104bfbca)
Previously, if you were narrowed when we reloaded you, you'd be
kicked out to the home view.
(imported from commit c00f1b92c9a4f559998463e141a402b69873fd56)
This reverts commit 91b4577c20afaf3ee9f5bed7f4e3451020960cf5.
Upon discussing with acrefoot, my new conclusion is that
the page should only look this way if you're going through
the workflow outlined in Trac #1391 -- otherwise it should
remain the way it is.
(imported from commit 57a1989d73526a357b47a4ac68dc911e8f2531cf)