This adds `--automated` and `--no-automated` flags to all Zulip
management commands, whose default is based on if STDIN is a TTY.
This enables cron jobs and supervisor commands to continue to report
to Sentry, and manually-run commands (when reporting to Sentry does
not provide value, since the user can see them) to not.
Note that this only applies to Zulip commands -- core Django
commands (e.g. `./manage.py`) do not grow support for `--automated`
and will always report exceptions to Sentry.
`manage.py` subcommands in the `upgrade` and `restart-server` paths
are marked as `--automated`, since those may be run semi-unattended,
and they are useful to log to Sentry.
Since the docker macOS setup doesn't work without this, it makes
sense for it to be just part of the setup instead of a thing
they fix after running into failure.
Updates descriptive text that refer to Zulip channels in the
`docs/translating` files to use channel instead of stream, except
for guides for specific languages as those should be updated by
the translation teams themselves.
Part of the stream to channel rename project.
Updates descriptive text that refer to Zulip channels in the
`docs/contributing` files to use channel instead of stream.
Part of the stream to channel rename project.
Updates descriptive text that refer to Zulip channels in the
`docs/development` files to use channel instead of stream.
Part of the stream to channel rename project.
Updates descriptive text that refer to Zulip channels in the
`docs/documentation` files to use channel instead of stream.
Part of the stream to channel rename project.
Updates descriptive text that refer to Zulip channels in the
`docs/outreach` files to use channel instead of stream.
Part of the stream to channel rename project.
Updates descriptive text that refer to Zulip channels in the
`docs/overview` files to use channel instead of stream, except for
the changelog file.
Part of the stream to channel rename project.
Updates descriptive text that refer to Zulip channels in the
`docs/tutorials` files to use channel instead of stream.
Part of the stream to channel rename project.
Updates descriptive text that refer to Zulip channels in the
`docs/testing` files to use channel instead of stream.
Part of the stream to channel rename project.
Updates descriptive text that refer to Zulip channels in the
`docs/subsystems` files to use channel instead of stream.
Part of the stream to channel rename project.
Updates descriptive text that refer to Zulip channels in the
`docs/production` files to use channel instead of stream.
Part of the stream to channel rename project.
This commit relocates all the scripts in the tools directory which
are used for auto-generating screenshots to the new
tools/screenshots directory to avoid cluttering the tools/ root.
Gitter broke their older API as part of being integrated
into Matrix.
Their announcement blog says:
"Anything left using the Gitter APIs will need to be
updated to use the Matrix API"
This commit drops the legacy Gitter import tool and
we plan to build a new one for Matrix in future.
Updates the base hash for the streams setting overlay to be
"channels" instead of "streams".
Because there are Welcome Bot and Notification Bot messages that
would have been sent with the "/#streams" hash, we will need to
support parsing those overlay hashes as an alias for "/#channels"
permanently.
Part of the stream to channels rename project.
This commit adds a 'skip-delay' option to the
'send_zulip_update_announcements' management command.
It will be useful for self-hosted servers after 9.0 upgrade to
avoid the 24 hour delay to receive update messages after group
DM is sent to the admins.
One can run the management command with the --skip-delay flag
to immediately send the update messages.
This removes a bunch of out-of-date documentation which is better
addressed outside of Zulip, and provides more details on running a
PostgreSQL server on a separate host.
`--no-init-db` is used to silence the need for `--hostname` and
`--email` arguments; it is a proxy for "this is not a frontend host."
We would ideally like to use `has_class` to know if the user's
provided puppet classes are include an `app_frontend`, and thus
`--hostname` and `--email` are required -- but doing that requires
several other steps, and we would like this feedback to be immediate.
We make the presence of `--puppet-classes` equivalent to
`--no-init-db`, since nearly every configuration with
`--puppet-classes` does not install both a database and a frontend,
which is what is required to initialize a database.
