We really should not be storing bot API keys in the DOM and should
require some sort of additional authentication before showing them,
but this seems reasonable for a first pass.
(imported from commit c7d75aa52e21894bf53917457e771c18de38bbcc)
For sites that are supported, we now grab thumbnails for images + video
embed code for videos and use them in lieu of our existing embed code.
We also embed rich non-script content.
Special casing is done so that we don't embed images twice.
Some testcases were modified to avoid triggering Embed.ly
The manual step is to install python-embedly.
(imported from commit d725bab91675c61953116c5ca741055fce49724e)
The .height() and .width() functions are actually pretty expensive for
the number of times we call them. The viewport height and width
don't change often, though, so we can just cache them and recalculate
them on window resize.
(imported from commit 129fb8c058144125e2974f6b7967cd9f1a5c9ead)
This allows users on signup-eligible domains to sign up for Humbug using
Google Apps.
As part of this, we wrap the openid done view in our own code in order to
handle the "Unknown user" error. Therein, we create a PreregistrationUser
and then shunt the user through the rest of the confirmation process, pre-
filling in their name.
(imported from commit 066d9a1021384a6da2662352e62a701451bd6f44)
* renamed the 'icon-star' style to 'icon-vector-star' to keep backwards compatibility for icon-* classes
* changed relevant styles in zephyr.css; added FontAwesome assets
* changed relevant CSS classes in base.html, left-sidebar.html, ui.js, message.handlebars
* added new fonts.css to start consolidating all font-based assets
* added fonts.css to PIPELINE_CSS in settings.py under 'portico' and 'app'
* modified the stars test suite to reflect new star icon class name.
(imported from commit 3116fcfd4b5fb4edecd457da554fea616bb7081b)
Otherwise these logs will end up all getting split up when we switch
to the new deployment model.
(imported from commit 0514c296470be7113cab6c2f48e8dd33f1b9353d)
This allows users to drag and drop content onto the compose box, storing
their data in Amazon S3.
New dependencies:
- python-boto
(imported from commit 339874e483db5c36312c9ceae56db29da6ca0d99)
This creates a new management command, subscribe_new_users, which should be
run as a daemon process. When new users are created, an event is passed to
RabbitMQ including the following data:
* Email
* Full name
* IP address of the person who confirmed registration
* Time of registration confirmation
MailChimp strongly encourages the collection of the last two to enable
responses to abuse requests, and providing more data lowers the chance that
we could get banned from their service if complaints do occur.
To use this commit, you need to install the "postmonkey" module from
PyPI.
(imported from commit 20c628c3fa8bb985aaead85a80ad3b38bf94b9dc)
Django's South migrations support for setting up a new database
doesn't properly handle AUTH_USER_MODEL changing over time. Fix this
by having the initial migration be run with AUTH_USER_MODEL set to the
default value.
(imported from commit c373db9edc61f26527c486c741f8e870614600e3)
...rather than embedding them into index.html.
This is only acceptable for dev, but the next commit adds an alternative
mechanism for prod.
There isn't actually a manual deployment step here. However, this commit won't
work on staging / prod without the next one (since we don't serve
zephyr/static/templates in prod).
(imported from commit dce7ddfe89e07afc3a96699bb972fd124335aa05)
Beanstalk integration uses webhooks that use http basic auth to authenticate
the sending user.
(imported from commit bd65f5b2d052a3c1eb04da64d055a3640a384892)
When this is deployed to staging, we need to run
./manage.py logout_all_users --realm=humbughq.com
When this is deployed to prod, we need to run
./manage.py logout_all_users
(imported from commit d6c6ea4b1c347f3d9122742db23c7b67767a7349)
The new nginx configuration file needs to be copied to
/etc/nginx/humbug-include and nginx needs to be restarted when this
commit is deployed.
(imported from commit 6c43f3c2c7a6acee6a852c672c96a38bda01dd0d)
The policy this implements is:
* 1 week for most persistent data (Clients, etc.)
* 1 day for messages
(imported from commit d57bb2c6b9626ffa2155c6d0ef9b60827d1f2381)
Apparently, something in Django 1.5's changes to their default logging
setup resulted in the logger 500 errors (logged in
django.core.handlers.base.handle_uncaught_exception) from reaching the
root logger -- they stopped at propagating at the 'django' logger. We
deal with this by making our logging system handle those events in the
'django' logger ourselves (and making the related changes needed to
ensure that we still log to server.log and the console everything
logged by our own humbug.requests logger and anything that falls
through to the root logger).
This requires updating the mechanism we use in test_settings.py to
silence our request logging, since now the 'humbug.requests' logger is
being re-initialized by the Django logging setup, which runs after
test_settings.py.
While we're at it, set propagate=False in the commented-out
'django.db' logging configuration (previously, queries would be logged
twice).
(imported from commit 32af29084e52be1ba6f92a7952c3a3946925b46b)
This only does something if DEBUG=False, but it's now required that
you set this on Django 1.5 or the server will silently serve up 500s
for every request (not the best failure mode).
(imported from commit fa226c644770c468d73143c8a49d5d29d282df27)
Jessica McKellar
Leo Franchi
Zev Benjamin
Luke Faraone
Steve Howell
Allen Rabinovich
Tim Abbott
Keegan McAllister