Re-focuses on the compose box after a send, but only if
the compose-box was opened by responding to the message
at the cursor (by hitting "r", enter, or clicking on the message)
(imported from commit 8e7560c8ea31397b57b2bc3e2e7d9dd996226a6f)
Modified files need to be copied into the right place. The checkout
on git.humbughq.com also needs to be updated.
(imported from commit dbe9e05a0512e1f59c7819dd8d44c2c4e9c83bcf)
We let supervisor create the socket for us by making humbug-django a
fcig-program. Unfortunately, supevisor doesn't support putting
fcgi-programs in groups (see
https://github.com/Supervisor/supervisor/issues/148), so we have to
restart tornado and django separately.
To deploy, copy the config files over and restart nginx and
supervisor (via stopping and then starting it because restart is
broken). I believe the automated restart as part of
update-deployment will fail because of the way supervisor treats
programs in groups. If so, after restarting supervisor, you will
also need to run restart-server manually to fill the caches and then
delete the lock directory in humbug-deployments.
(imported from commit bfb5db7dd42dcbc4bfefa2944355b3cbb2ef9104)
The amount of process downtime during a supervisord-mediated restart
appears to be linear in the number of processes that are being
restarted. Therefore, restarting just Django and Tornado causes less
downtime than doing them at the same time as the other worker
processes.
(imported from commit 1fa9ef547bcd88caeec49800664e37d5f2fcb7a8)
Currently our test database is backed by sqlite; this commit moves
us to using postgres for our all database needs. This, in conjunction
with the patched django on github, allow us to have fewer hacks and
more true-to-life tests. It also sets the stage for testing the bulk_create
and schema search_path patches made to django.
Developers will need to run:
./tools/postgres-init-test-db
./tools/do-destroy-rebuild-test-database
this is assuming that they have already run:
./tools/postgres-init-db
./tools/do-destroy-rebuild-database
at some point on this pg_cluster. (The ordering is important; it will other-
wise complain about the south_migration table).
(imported from commit c56c6f27e13df7ae10b2e643e65d669dde61af3d)
This change will make it so that processes related to the app.humbughq.com
server are run under supervisord, which uses a state machine model to ensure
that programs are running. It also ensure process startup order.
We will need to manually switch the old way of running server (in screen) into
this new way of doing things, on both staging and prod (app_frontend.pp has been
updated appropriately). This means:
1) cp servers/puppet/modules/humbug/files/supervisord/conf.d/humbug.conf /etc/supervisord/conf.d
2) installing the supervisor package.
3) killing those while loops in that screen session
4) mkdir /var/log/humbug (as root)
5) /etc/init.d/supervisord start
6) check that nothing broke
(imported from commit 055269a70973db89acd69049e01b185fabdc8f90)
Most of the model logic pertaining to unread counts had been in
zephyr.js, along with a couple global variables. Now the code
is encapsulated in unread.js. It was a pretty straightforward
extraction with some minor method name changes. Also, a small
bit of the logic had also been in stream_list.js.
Conflicts:
tools/jslint/check-all.js
(imported from commit f0abdd48f26ab20c5beaef203479eb5a70dacfff)
The only known outstanding bug with this is that it doesn't properly
handle the updating of a message's highlighting/presence in a narrowed
view (e.g. in theory, a message should disappear if it is edited such
that its subject doesn't match your narrow or it no longer matches
your search). I think I'll just open a trac ticket about that once
this is merged, since it's a little hairy to deal with and kinda a
marginal use case.
Also it's not pretty, but that should be easy to tweak once we get the
framework merged.
Conflicts:
tools/jslint/check-all.js
(imported from commit 2d0e3a440bcd885546bd8e28aff97bf379649950)
South doesn't properly deal with removing the Django User model, so
this commit redoes our South history to instead start after that
migration has already been applied. This allows us to get rid of some
annoying hacks.
Note that developers and staging will need to run
./manage.py migrate --delete-ghost-migrations zephyr
in order to clear out the old versions of the migrations.
(imported from commit 7f45ea601b809dde33720f76e7dfb0ab348b0e65)
This is a prefactoring to eventually eliminate the home_unread_messages
global variable. More commits to follow.
In order to set up process_loaded_for_unread() not to modify
global variable to get its job done, we want to pull it out of
add_messages(), so that add_messages() doesn't have to pass back
state to the 9 different places in the codebase where it's called.
There are only 2 places where process_loaded_for_unread() get
called after this commit.
In order to facilitate pulling up process_loaded_for_unread(), I
made it so that the contract for add_messages() was to accept
already-hydrated messages. This way I could hydrate the messages
before calling process_loaded_for_unread() without have to
worry about double-caching them in add_messages. This will
slightly improve performance, but it was mostly done for code
clarity.
(imported from commit ad5aaad5b1f22c31647370f4c9dcb5f89d7d99a7)
The default is 50, which we believe was causing too much CPU
contention in prod during restarts. This commit lowers the max to 20.
The django-command-line script needs to be restarted manually to pick
up this change.
(imported from commit c2d097d2141be50b6222efb4a34142108c241cce)
The String.localeCompare function is really slow, at least partially
because it creates a locale-aware collator object each time. So now,
when we can, we create and cache a locale-aware collator object.
However, this is not supported on most browsers, so we fall back to a
non-locale-aware comparison. This is not ideal, but for now we are
mostly working with English-speaking customers.
(imported from commit 51aa02e3b9fe4a0ef0cb084874fe26e91c57f65e)
The previous version ended up being (at least sometimes) wrong after
the recent deployment system changes.
(imported from commit dec3beb1b1bf8b9c9ad6820b93b0a5d730d020e8)