Previously, we would return a JSONDecodeError to the user in the event
that the server returned a 500 error (or other non-JSON content).
(imported from commit 1624dfec6ac65d34216f4de91e33116a54e414fa)
Just before this is pushed to prod, we need to rename the Humbug feedback
bot in the database using:
./manage.py change_user_email feedback@humbughq.comfeedback@zulip.com
/etc/init.d/memcached restart
and we also need to update and restart feedback-bot in its deployed
location.
No action is required on pushing this to staging, but in between when
this is pushed to staging and when it is pushed to prod (and that
transition performed), feedback will not work on staging.
(imported from commit 73fc36f680b978f3aebae5df1822918ae4d4e952)
When we push this to staging, we'll need to rename the bot in the
database and also pull on git.zulip.net.
(imported from commit 22b2397b197c8820f0e55daecd8f98d829e195bd)
urlparse.urljoin(base_url, url) will drop any path inside base_url if
either the url has a leading "/" or base_url doesn't have a trailing
"/". So adjust our API bindings to ensure that doesn't happen.
(imported from commit c080ee8c04b89127888609da28afc8b388af1911)
This must be deployed after we update our running nginx configuration
to serve api.humbughq.com.
(imported from commit b5c34ebdd595f55eecd6dca6a18a37f105107bd5)
Since in the future we might want requests to add subscriptions to
include things like colors, in_home_view, etc., we're changing the
data format for the add_subscriptions API call to pass each stream as
a dictionary, giving a convenient place to put any added options.
The manual step required here is updating the API version in AFS
available for use with the zephyr_mirror.py system.
(imported from commit 364960cca582a0658f0d334668822045c001b92c)
This way we can return properties of the streams other than just their
names in future versions of the API without breaking old clients.
The manual step required is to deploy the updated version of
sync-public-streams on zmirror.humbughq.com when we deploy this code
to prod.
(imported from commit 42b86d8daa5729f52c9961dd912c5776a25ab0b4)
I believe this should require no special work on deploy, since some
grepping of logs suggests we are not currently using this API query.
(imported from commit 240086f900c6680cbc90bf6a2f334a9e1f172df6)
The --site= option is really only for internal developer use, so I
don't think we gain anything from being strict about it.
(And it doesn't help that the error message one gets pre-this-patch is
super confusing). Fixes Trac #937.
(imported from commit 8d699982aa6830f9eae2bccd6d0c7a1e0e53dd56)
Give better examples, and rewrite options parsing to be more consistent across examples.
Make it more obvious that you can use "--user" and "--api-key" with our python examples.
This bumps our python bindings to v0.1.9
(imported from commit 297468088f864b7d585e567dc45523ea681f1856)
Previously our receive API bindings were broken in our API tarballs
because we weren't including the receive API bindings which they used.
This requires our deploying the built API tarball to the prod server
when we deploy it so that the link on /api isn't broken.
(imported from commit 14ecaab34556f4e29c72f4f567d8af73c89d6297)
For consistency, and because nobody could think of a reason to have it live
in bots/ with a symlink.
(imported from commit def372653fcdde2805729134fec9d4bc3ce294ec)
