Meant to be used in tandem with the manage.py import command.
The following sensitive data is scrubbed:
* user api keys
* user password hashes
* stream email keys
* invite-only streams
* messages from invite-only streams
* messages from users from other domains
(imported from commit 8e58dcdcb80ef1c7127d3ab15accf40c6187633f)
This can happen if the calling process is handling SIGCHLD. See
http://bugs.python.org/issue9127
We ran into this in the zephyr_mirror.
(imported from commit 80fade2274714b7c2c4b9fe38c66a1db8cc63234)
The idea here is that for usages like in the zephyr mirror bot:
backoff = RandomExponentialBackoff()
while backoff.keep_going():
print "Starting zephyr mirroring bot"
try:
subprocess.call(args)
except:
traceback.print_exc()
backoff.fail()
we want it to be the case that the mirror bot running for a while counts as a
success so that the bot doesn't have a finite number of crashes over its entire
lifetime. We only want the mirror bot to stop retrying if it fails too many
times in a row.
(imported from commit 7b10704d3ce9a5ffb3472cbb4dfa168c9c05ae7a)
This will allow us to substantially decrease the server-side work that
we do to support our Mirroring systems (since the personal mirrors can
request only messages that user sent) and also is what we need to
support a single-stream Zulip widget that we embed in webpages.
(imported from commit 055f2e9a523920719815181f8fdb44d3384e4a34)
This way command-line scripts that use our `optparse` populator can
still specify a custom client without munging their `parser` object.
(imported from commit df8d28a46a4d4574523b106030dbfed2d9ac931e)
We previously sent our client type to the server as a GET/POST parameter
of "client=<something>", most commonly "client=API: Python".
We switch here to providing the same information as a User-agent header
sent on each request, which is more standards-compliant.
Also added is some data about the platform the user is using. If your
client string was set to "MyLittleZulip/1.0", the resultant string could
look something like this:
MyLittleZulip/1.0 (Ubuntu; 12.04)
(imported from commit 39fd187a8f9d4b3c9b63fc623e0836e57a4099ca)
This is designed to be run as a "change-commit" trigger. See [Perforce's
documentation][1] on how to set up a trigger for your platform.
[1]: http://www.perforce.com/perforce/r12.1/manuals/cmdref/triggers.html
Closes trac #1034.
(imported from commit d94fa4e50637ade2847a96eab8c5514de3811c24)
Since we're using the module outside of a git repository context we
don't have a git config to reference. Instead, we'll just use the
environment variables we're passed.
(imported from commit 8ae707d5d60eb700052e0ee89e7d36c660e00bb6)
Previously, users of setuptools would get our data embedded in eggs.
Eggs are horrible things, but more importantly our package data should
be free, in a well-known albeit system-dependant path that is
independent of the package.
By specifying [install_data][1] as an alias of install, we assure that
our data (examples, integrations, etc) are placed in $data/share as
$DEITY intended.
Alternative suggestions included force-adding "--old-and-unmanageable",
which would invoke the distutils-style install command, but that had the
unfortunate side effect of turning off eggs and dependency resolution
altogether.
We could also use "--single-version-externally-managed", but I think
that was designed to be used by package managers, not by us.
In any case, both of the above were fragile and might break if the user
specified additional options to setup.py.
In closing, Python module management is horrible. See [this][2],
[this][3], and [this][4] for info about the status quo, and [this][5]
for information about crack to be smoked later down the road. Don't even
get me started about [PEP 427 -- Python wheels][6].
[1]: http://docs.python.org/2/distutils/commandref.html#install-data
[2]: http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/
[3]: http://stackoverflow.com/a/6522905/90777
[4]: http://python-notes.boredomandlaziness.org/en/latest/pep_ideas/core_packaging_api.html
[5]: https://python-packaging-user-guide.readthedocs.org/en/latest/future.html
[6]: http://www.python.org/dev/peps/pep-0427/
(imported from commit 6cf1bd2b8f5a60b2f02f5d11094e4a41cc5e48aa)
Due to limitations in their API, we have to poll and check for
creation and completion events.
(imported from commit be65e507fac16a7f8ad3dc57b2af9c4b98aacf39)
This requires renaming the account in Google Apps at the time we
deploy this; we'll probably want to do this during off hours to avoid
any user-visible downtime.
This also updates some related email addresses.
(imported from commit fce7629b359a4f278bbf7815c8d177a8fa0484fe)
Before these examples weren't obviously blocking calls (they seemed
more like a callback registration, which may make more sense in the future)
(imported from commit 78fdf98d791b19843526437c710901d8dff62e8c)
This mirrors all the "events" in a Basecamp account onto a stream in Zulip
(default "basecamp"); it sets the topic as the calendar or project that the
event belongs to.
Unfortunately, Basecamp will not host hooks, and neither do we, so this script
is currently intended to be run by our customers, much like the Trello mirror.
(imported from commit 484bc12681a43cd01fe0189c072ab4230eb32c22)
Previously it only provided the list of all public streams; now it
allows one to specify any union of some of the following:
* all public streams
* all streams the user subscribed to
(the most relevant being the union of those two, which is what we want
for the "streams" page).
Or:
* all streams in realm (superuser only)
The manual task required is that when this is pushed to prod, we need
to also deploy the new sync-public-streams version to zmirror.
(imported from commit 27848b8bd136e2777f399b7d05b2fdcec35e4e21)
When we deploy this, we'll need to of course actually build and deploy
the new API tarball.
(imported from commit 03c853e8a9424a63f1c74bb83637d5a1e50a159a)
This makes our life a bit nicer if the message is super-long,
because then even when it's "condensed", we still get a link
to the actual article.
(imported from commit 32e70d29cb702ce73f6cd0c04dbc58457cd2e6b5)
Even though we support a command-line option of --user=,
it gets stored in a field called 'email'.
(imported from commit f2956524517a93187ed182caf8e2d85ccbc1a0f4)
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)