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 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)
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 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)
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)