This code adds a dependency on python-django-auth-openid, installable as
django-openid-auth from PyPI.
On prod, one needs to run a syncdb in order to create the required
tables. A database *migration* is not required, as these are new tables
only.
(imported from commit c902a0df8d589d93743b27e480154a04402b2c41)
After c1d98239 the function works in CasperJS as well.
Reverts some of 90f4d6ac3ddb387e74051b9af2c230698fa94479.
(imported from commit 3579df33930bb34dc081908b84900905eee6d270)
The idea here is: part of the onboarding tutorial is going to
be you talking to the tutorial bot and it talking to you, from
our Javascript.
The reason it's driven by Javascript is that then in principle we can
do nice stuff like making popovers appear in places to point things
out to you, whereas if we were to do it strictly server-side, doing so
would be a lot harder.
The downside to doing it in Javascript is that you don't get any of
the Markdown rendering, since that happens on the server. So instead
we add this call where you give it a message, and it responds by
having the tutorial bot send you that message.
I don't think there are any security concerns here because
(1) The bot only messages you -- so you can't use it to make someone
else think that the system is telling them to do something
(2) If there were an issue associated with having the server parse
arbitrary Markdown, you could just trigger the issue by sending
a message yourself.
(imported from commit b34f594dab6be6bcb81899278ae1cbe447404468)
This commit just moves time rendering logic to its own file, and does
not make any functionality changes.
(imported from commit d111d03c6abc8d9550fcf65e4f89eab8056d1ed4)
This makes it possible to point users back at the instructions they
followed originally in the event that their Zephyr mirroring bot has
died.
(imported from commit 24ab2dc0df3dc88f8155d58761a89fe44c111fd9)
Adds a new db table for storing presences, and an API for setting
an individual user's idleness as well as fetching all idle status
for all users in a realm
(imported from commit 5aad3510d4c90c49470c130d6dfa80f0d36b0057)
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)
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)
This was to support get_updates sharding, which we never fully
implemented. We can recommit this change later if we choose to bring
the feature back.
This reverts commit fda2d99d9e9a07951d11fcd9fc61cf229988f471.
(imported from commit aec8203c8d8a94dd6f30089aeee22814d1595fc5)
As a side-effect of customizing the e-mail, this also makes the host
on which the error happened a part of the subject line.
(imported from commit 7d5e9ad108b48fd34528512c5955567119935d4e)
We need this so that we can safely expunge old events without interfering with
the running server. See #414.
(imported from commit 4739e59e36ea69f877c158c13ee752bf6a2dacfe)
Before this is deployed, we need to install rabbitmq and pika on the
target server (see the puppet part of this commit for how).
When this is deployed, we need to start the new user activity bot:
./manage.py process_user_activity
in the screen session on the relevant server, or user_activity logs
won't be processed (which will eventually result in all users getting
notifications about how their mirrors are out of date).
(imported from commit 44d605aca0290bef2c94fb99267e15e26b21673b)
This commit has the effect of eliminating all of the non-UserActivity
database queries from the Tornado process -- at least in the uncached
case.
This is safe to do, if a bit fragile, since our Tornado code only
accesses these objects (as opposed to their IDs) in a few places that
are all fine with old data, and I don't expect us to add any new ones
soon:
* UserActivity logging, which I plan to move out of Tornado entirely
* Checking whether we're authenticated in our decorators (which could
be simplified -- the actual security check is just whether the
Django session object has a particular field)
* Checking the user realm for whether we should sync to the client
notices about their Zephyr mirror being up to date, which is quite
static and I think we can move out of this code path.
But implementation constraints around mapping the user_ids to
user_profile_ids mean that it makes sense to get the actual objects
for now.
This code is not what I want to do long-term. I expect we'll be able
to clean up the dual User/UserProfile nonsense once we integrate the
upcoming Django 1.5 release, with its support for pluggable User
models, and after that I change, I expect it'll be fairly easy to make
the Tornado code only work with the user ID, not the actual objects.
(imported from commit 82e25b62fd0e3af7c86040600c63a4deec7bec06)
Previously it wouldn't work due to using the wrong port numbers.
This commit also has the side effect of fixing the fact that our
frontend tests would send real emails and log events to the real
message log.
(imported from commit f2cf400e6061c089627acba2759d588981ecf5bb)
CasperJS can't handle them; window.webkitNotifications.requestPermission()
throws a type error. We can revisit this when we want to write tests for the
notification code.
(imported from commit 90f4d6ac3ddb387e74051b9af2c230698fa94479)
This was done using instructions provided by the South authors:
<http://south.readthedocs.org/en/0.7.6/convertinganapp.html>
This adds a dependency on python-django-south >=0.7.5. Now when you are
reinitializing the database, you need to run "./manage.py migrate --all"
before running populate_db.
When deploying this commit onto existing servers, you need to run these
commands manually:
./manage.py syncdb
./manage.py migrate zephyr 0001 --fake
./manage.py migrate confirmation 0001 --fake
These do *not* need to be run on new databases, only on existing ones.
(imported from commit f24cff421a6be9ab9cf4c4342565c484ac336e2d)
This view lives at /accounts/accept_terms, and (after getting an acceptance
from the user) sends an email to all@ documenting the acceptance.
(imported from commit 8f64286ab02887fd6544fa274b2967f6499b6dbc)
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)
This is an interim strategy for user education that'll be a stopgap
until we build something in the app itself.
(imported from commit 9022d4ceffca98e127f7045f73c012857fe6fc54)
Per Django docs, these are used to set an alias for use by reverse(). We
mostly don't use these, and they clutter up the file. We do use
reverse('send_confirm') so it stays.
(imported from commit 7789e588e187fae71638bd77a553801c48fa8818)
Previously if you hit /accounts/logout with no ?next=... parameter, you would
see a broken version of index.html missing dynamic content.
(imported from commit d9bca92d1c3c82893524ba69b132d59c48aa34c9)
External people won't be able to register unless we initiate the action
and send them an email, because the confirmation token generation code
is in the still-protected accounts_home view.
(imported from commit 8985257576d3dff5b0cad9d4b0ae213f18528865)
If we have other pages that require login, we might want them to redirect to
the login form. But the root of the site should take you to /accounts/home --
but only after we launch the product.
(imported from commit b5d10e1c908f1ffe1ee68c2689691ca66c896786)