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)
This new call only allows fetching of existing messages. The idea is
to remove this functionality from get_updates to simplify the backend
code.
(imported from commit 1345db2f1707e208e7c0bd08b7d444932c68b6a2)
The client may now optionally send its current pointer during
get_updates and the server will return the latest pointer if it
differs and was updated more recently by a different session.
(imported from commit e43b377d7dfb52f83cefb0b1003863d5407caf80)
Mobile clients need it.
We are going to need to sit down and think about how much power we
want to give our API users, though. For example, should they even get
to know about your absolute pointer value (maybe they should only be
able to make requests relative to your pointer), or be able to request
very old ranges of messages?
(imported from commit 1680655f0d9a670bc0da0ddb92fbbd5cf851d3dd)
Without this change, one can only create a few users per second(!),
which really puts a damper on quickly importing old messages.
(imported from commit 26daf61b57154daa067db3daf8254c12d23da353)
This makes it easier for mobile clients to use the API by enabling them to
present the user with a familiar username / password prompt, rather than
by asking them for their API key.
(imported from commit 6ed06cfe86f87e7aef54a4be7835fb7bf8d7f209)
The key property is that we never reveal the non-public directory name
4nrjx8cwce2bka8r to a not-logged-in user. This makes it less likely that
random people from the Internet will download all our client code while we're
still in private beta.
(imported from commit 7428e847e0a1a34152cb6dc2b677c1b47290c202)