json_to_foo will raise a ValueError if the JSON passed to it is just a
string containing a number, e.g. "1".
Traceback (most recent call last):
File "/home/tabbott/humbug/zephyr/views.py", line 711, in extract_recipients
recipients = json_to_list(raw_recipients)
File "/home/tabbott/humbug/zephyr/decorator.py", line 289, in json_to_list
return json_to_foo(json, list)
File "/home/tabbott/humbug/zephyr/decorator.py", line 282, in json_to_foo
raise ValueError("argument is not a %s" % (type().__class__.__name__))
ValueError: argument is not a list
Fixes#776.
(imported from commit 0c123a610c009eda9004cf0b0b53d60695c4e8d5)
Right now the table is too wide for my screen and I have to scroll it
to see some stuff I'm actually pretty interested in seeing; this
rearranges things to make that less the case.
(imported from commit b06088c59d9ba21ecc24fa55367226a2aa09d907)
This should fix the symptoms of the problem we've been having where a
few API clients using the MIT Zephyr mirroring system sometimes seem
to end up with a too-old value of last.
(imported from commit 9f2426fa6a7e8365e8d3443bfd2cce3238cc9510)
Fixes#792. I'm really curious what (if anything) this change does to
our Tornado load numbers.
(imported from commit daf81d2dea81f36ec4a3eb19993169b58681e717)
This cuts the MIT Zephyr home page load time and also #subscriptions
database-sourced load time for me from about a second to about 50ms on
my laptop. The home page still takes about 600ms to load due to
templating.
(imported from commit 1cfd8c750301abe6b6a881be4b2857532be947ec)
The purpose of the validator is to ensure the user isn't active, so
let's correctly test for that here.
(imported from commit 772ddb901098f78750efab274405a10f36c49232)
Previously we checked and bailed when there was a user registered with
an email address, regardless of active status.
This meant that MIT users who had inactive accounts autocreated had
issues where they would be confusingly told they were signed up even
though they had never taken any action on our site directly.
Now we instead check whether there are any current *active* user
accounts with that email address, and proceed with generating an
activation link if the user lacks a corresponding active account.
Security implications of this commit come into play if we start
implementing removing users ability to sign in as deactivation. Since we
lack a user removal story here, this isn't terribly concerning yet and
we'll revist this code when we decide to add such functionality in the
future.
This resolves trac #581 and #631.
(imported from commit c3fb93ce065e63e19b41f63c1f27891b93b75f86)
(And to let you know that it's OK that you have no messages.)
This fixes Trac #850 for the case where you first log in.
(imported from commit 47741856e34f67bfc2cc91bdc21def75ab6fe09d)
The previous select_related didn't properly get the User object,
containing the email address, and thus would make one query per user
with presernce information.
(imported from commit 3341bc5a65387030fa8737b03ca43f79089ef56b)
On my dev machine this cuts /activity load time with lots of users by more than
2/3. I expect the gains will be even greater in production due to the greater
relative cost of database queries.
(imported from commit 0391cb29f66b618b4b99902d9fb9ab0a6cff0cb3)
I don't like monkeypatching in general, but this will give us logging
of how much time is being spent in total on database queries on our
staging and prod instances for each of the views we have -- which
should help a lot with debugging performance problems.
The code being patched is identical in Django 1.5, so I don't expect
any issues upgrading in the near future.
I may work on a patch to upstream Django to support this as well.
(imported from commit 08624c7a30f1fd192a972973e0380dd6a131d84e)
The previous commit stopped the mousewheel event at .bottom_sidebar,
which means it was never getting to our individual scrolling lists.
(imported from commit 92d32c21bb596d0e14d887ff779a857223d45342)
This isn't perfect, because if, e.g. the stream list is super short,
it still takes up lots of space that the user list might want to use,
but it's an acceptable first pass solution, in my view.
(imported from commit 669737d769258c089b40ffea4abee3229902e857)
When DEBUG=False, Django doesn't log the data at all. We can and
should add tracking of that at some point, but it requires patching
Django; so for now just log the data when DEBUG=True.
(imported from commit 2b9e6a4c68009733373724f38debe4e77313fdeb)
This should make it much easier to debug issues where a particular
user is hosing our API, for example.
(imported from commit cbea49fd1e11805cadf564bd9160d3d6bf7e0eca)
When deploying to prod, this will require a manual install of the
rabbitmq_* files to /etc/munin/plugins/ and an edit of
/etc/munin/plugin-conf.d/munin-node.conf
(imported from commit 4c10e634b04200dda1c4f4989e37fe232143240f)
Tim Abbott
Leo Franchi
Waseem Daher
Zev Benjamin
Keegan McAllister
Jeff Arnold
Luke Faraone
Reid Barton
Jessica McKellar