If you have a lot of subscriptions that you're trying to modify,
jumping back up to the top of the page is very disruptive. We still
show the success message, which has the effect of scrolling the page
and is thus surprising, but that's better than the user completely
losing their place.
We do need a story for informing users about failures to subscribe or
unsubscribe, though. We currently jump back to the top so they can
see the error, but that's not optimal.
(imported from commit 48d938ddc47f286a72e2147f4459b91ca5684e36)
This reverts commit a590bf6b8ee733893d3410ecb5eebe54141c48ea. This commit broke
the test suite because it was not tested after rebasing with Keegan's changes
to the tests.
(imported from commit 7248a55328609973c5303be6c85eeb5fbfc1475e)
This fixes a problem where if you were 1) running in development
mode, 2) had populated the database from production data, and 3)
tried to log in with an account that had changed its password, you
wouldn't be able to. The problem was that the password change
created a password change record with a PBKDF2 hash, not a SHA1 hash.
This change lets the dev server accept PBKDF2 hashed passwords, but
still use SHA1 password hashes for creating test users for speed.
(imported from commit 2840d266f93add1edbba7f93a7f1491372fc8cf1)
GetOldMessagesTest had test methods that weren't included in the test suite
generated by Runner because they did not have "test" in their names. A few
bugs in these methods that were overlooked because of this were also fixed.
(imported from commit a590bf6b8ee733893d3410ecb5eebe54141c48ea)
For debugging in case this is ever different from platform.node(). I
think this would happen when using a CNAME, for example.
(imported from commit 47f6c3490712a3ac1c6a16f9146c2ef3ca8fc5e8)
This was causing about 10% of the time, personals being forwarded by
tabbott/extra@ATHENA.MIT.EDU to get this error:
zwrite: Field too long for buffer while sending notice to
tabbott/extra@ATHENA.MIT.EDU
We don't fully understand the cause of the problem, but this fixes it.
(imported from commit 22c39a1061cde9ad6973ef07aee7227623a3d47d)
Sometimes the very first message we send isn't received by
python-zephyr; this could be because of our growing a 17-message queue
of zephyrs to service, so let's not do that.
(imported from commit 281bf1807442b6335b05c803b1a47e0a162bef4e)
This ensures that Humbug receives the verbatim text of the Nagios
body, rather than a slightly modified version. Tested by running
manually.
(imported from commit 7e0eea0b230fd8c5552860acfb7372099598f036)
This essentially reverts d900957e468815bcb99de67d570dfd7ce4413220.
This code was consuming up to 50-100ms per client recipient of a
message, so for any messages that would go to 50+ browser windows /
mobile devices, it would take several seconds to run, during which
time Tornado would be completely blocked.
In the future, we can re-fix #174 using a cache of recently delivered
messages, so that this code block doesn't go to the database and thus
can run instantaneously.
(imported from commit bdfa1664210429411737f70cde54ab5a56525341)
For whatever reason, specifying a percentage for bottom_whitespace
seems to cause issues in some browsers, including Firefox 17
and the Firefox Nightlies.
This is a bit confusing to me, since bottom_whitespace is basically
immediately resized by resizehandler initially anyway. But hey.
(imported from commit 93da101edeb6f16b01a92aed775e9117c0295086)
The refactoring that we did a couple weeks ago to make the zephyr
mirror script restart itself automatically (by splitting it into
zephyr_mirror.py and zephyr_mirror_backend.py) had a poor interaction
with our code for killing old zephyr_mirror processes (to prevent
double-mirroring). If you manually ran two copies of the outer
mirroring script (zephyr_mirror.py), then the second one would on
startup kill the first one's zephyr_mirror_backend.py children (for
being duplicate zephyr_mirror_backend.py processes that would result
in double-mirroring). However, importantly, it did not kill the first
mirroring script's zephyr_mirror.py parent process, so the first
mirroring script would then proceed to startup up new children. The
process then repeats, with the two scripts' roles reversed.
This issue didn't affect the sharded mirroring case, where I had been
doing the testing of the kill code with that refactoring, because we
don't have a version of the outer zephyr_mirror.py loop for that
situation (a consequence of it being hard to restart the threads
properly with the run_parallel API that we're using to spawn all the
children).
(imported from commit d4886ac77312a6b0ebd0d612f6fb084970bf23a2)
CSS height percentage was not working because parent div has an undefined
height, so instead it is set to 40% of the window height on resize (and initial
load) via JavaScript.
Fixes trac ticket #24.
(imported from commit 2c6a8489585c4bf70c44469ce8628264ec3fbc36)