This is literally a pure "move HTML" operation; no actual code
changes.
This will make them always visible, even when we're in skinny mode
(and will also make more room for our list-of-streams-and-people
sidebar on the left.)
This does have the side-effect that the errors cover up the rest of
the application (in particular, the floating narrowbar). I don't view
this as the end of the world, though the more robust solution would be
for navbar-spacer to grow when the navbar does, and for everything
else to be correspondingly pushed down.
You can visualize an extreme version of what this looks like with
$(".alert").show()
in the Javascript console.
This fixes Trac #720.
(imported from commit 7a3b12aebcca389465bd1e5852cef5d08fafe3e7)
Leo points out that if you type a stream name, we probably want
to offer to narrow you to that stream more than we should offer
to find that stream name in the page.
(imported from commit 803ac681ec2f759f4dabb68a40722a07b86a0cab)
On my laptop, this cuts search time from several seconds down to
a few hundred milliseconds.
If we want even more speed, we could store the ts_vector as a column
on the message database. The Postgres documentation says this will
make "searches [...] faster, since it will not be necessary to redo
the to_tsvector calls to verify index matches." Going this route
requires creating a trigger to automatically insert the appropriate
column when new rows are inserted.
Note that the full text index must be fully created before this
commit is deployed. Full text search without an index is actually
significantly slower than using the LIKE operator.
(imported from commit ae74083da20d33aa2425d3e44fcdc19b160002ba)
This schema migration is only for use in automated migrations. To
deploy on the production database (the migration only needs to be
done once for both of staging and prod because they share a
database), you should instead execute the following SQL manually:
$ ssh postgres.humbughq.com
$ psql
humbug=> CREATE INDEX CONCURRENTLY zephyr_message_full_text_idx ON zephyr_message USING gin(to_tsvector('english', subject || ' ' || content));
Note the addition of the "CONCURRENTLY" keyword. The problem is that
creating the index takes non-trivial time and requires a write lock
on the table while the index is being created. This would mean that
users would be unable to send messages while we were generating the
index, which isn't acceptable. We can't create the index
concurrently in the South migration because concurrent index
creations can't happen inside of a transaction and South forces a
transaction on migration functions.
Also note that this index must be created before Postgres full text
search is deployed to the app because full text search without an index
is actually much slower than plain search using the LIKE operator.
(imported from commit 8b9445c27d0e427278de997b22342bffe6d855b7)
This is for allowing us to do things more complex than returning a Q
expression, needed for doing Postgres full text search.
(imported from commit 669ec71417c04baaf8ed1774bee147079b05b03d)
Manual deployment steps: The same Nginx reload as for "Get rid of the
static-access-control mechanism". If deploying both commits at once,
just do it once.
(imported from commit dd8dbbf14b95fce0a4b6f66f462fa0a6b50bfb8c)
We will minify our code, rather than trying to restrict who can see the
un-minified code. Removing access control first simplifies things.
Manual deployment steps:
scp servers/puppet/files/nginx/humbug-include/app root@staging.humbughq.com:/etc/nginx/humbug-include/
ssh root@staging.humbughq.com service nginx reload
and then the same for app.humbughq.com once deployed to prod.
(imported from commit 63788aa3fa7ba5fd97fcf85b05760abb5e7cae4b)
Previously, our database was cleared between tests but the cache wasn't,
so old database data would end up in the cache and cause unit test
failures. This replaces our cache with a dummy that doesn't actually
cache any data. In the future, if we decide that our tests require an
actual cache, we can return to LocMemCache and simply empty the cache in
the tearDown method of our tests.
(imported from commit 9f4603789a225673a8394614416f201919710261)
1) Make the search hotkey (/) no longer clear the search box
2) Vertically center the "Search..." placeholder
(imported from commit 02dee6b72c4457e160f57d8604164e15e62f5f28)
Django doesn't use this setting, but South consults it when
inspecting tables for their constraints. The fact that we store our
tables in the 'humbug' schema was causing South to fail to find our
table constraints (it was looking in the 'public' schema) and
therefore throw an exception when we try to remove the unique
constraint in migration 0002.
(imported from commit 4230338a7b78329a759339b2f9fcd277137b7f32)