The information here was recently added to manage-who-can-join-and-invite.
Arguably this is one we should save, since it is a distinctive feature not
offered by all of our competitors, and it gets some additional visibility by
being in the left sidebar. The model of having multiple things in the
sidebar pointing to the same article is getting messy though, and as our
feature count increases the cost of having stuff in the left sidebar is
increasing as well.
Both the integrations use our new Matrix integration (with only one
additional paragraph for the IRC docs), so docs for both should point
to the same underlying Markdown macro for configuring a Matrix bridge.
This is a follow-up to #9491.
Based on an original version written by Rishi, but this has been
basically rewritten by tabbott.
We also clean up one confusing part of our Slack docs.
Add `translate_emoticons` to `prop_types` and `expected_keys`.
Furthermore, create a emoji-translating Markdown inline pattern.
Also use a JavaScript version of `translate_emoticons` and then use
this function during Markdown previews and as a preprocessor. This
is only needed for previews, because usually emoticon translation
happens on the backend after sending.
Add tests for emoticon translation, a settings UI, and a /help/ page
as well.
Tweaked by tabbott to fix various test failurse as well as how this
handles whitespace, requiring emoticons to not have adjacent
characters.
Fixes#1768.
This commit:
* Removes the unnecessary screenshot.
* Reorders the instructions and combines them in to 4 steps.
* Improves the contents of the webhook-url-with-bot-email-indented.md
macro and makes it more consistent with create-bot-construct-url.md.
* Sets the recommended stream name to "commits", since that's what
the webhook function for Beanstalk expects in
zerver/webhooks/beanstalk/view.py. This allows us to use the
create-stream.md macro.
We now have a separate page for common error payloads, for example,
the payload for when the client's API key is invalid. All error
payloads that are presented on this page will be tested similarly
to our other non-error sample fixtures.
Now that we have a Markdown extension-based test framework for
generating and testing code examples on our /api pages, we don't
need this macro anymore!
This is a server setting so I created the section "Server settings" in the help sidebar for this to go under, and rewrote the copy and retook the images that were originally done by @Privisus due to some issues.
The JSON response for when an invalid API key is used to initiate
an API call seems to be identical in every case, so this macro
can be reused all the time.
The JSON response for when an API call to send a message is
successful is the same for both private and stream messages, so
these macros may be used again.
This is part of our efforts to change our integrations/webhooks
docs to follow the same sort of numbered-list format as our /help
docs. In order to indicate that paragraphs separated by newlines
are part of the same numbered-list point, every paragraph must be
indented 4 spaces.
The "subdomain" label is redundant, to the extent it's even
accurate -- this is really just the URL we want to display,
which may or may not involve a subdomain. Similarly "external".
The former `external_api_path_subdomain` was never a path -- it's a
host, followed by a path, which together form a scheme-relative URL.
I'm not quite convinced that value is actually the right thing in
2 of the 3 places we use it, but fixing that can start by giving an
accurate name to the thing we have.
This section has the docs a new admin might look at during initial set up.
Does not add or remove articles, just moves stuff around on the
sidebar. Does remove the "Miscellaneous" section.
Collects all relevant docs into "Sending Messages" and "Reading Messages".
Doesn't add or remove any docs, just moves them around on the sidebar.
Duplicates "Message a stream by email" (it now appears in two sections)
Removes the "Editing Messages" section/header.
This section should be the stuff we want users to see when they are first
setting up their account.
This commit only moves links on the sidebar around, no additions or
deletions.
Instead of recommending our users to download and install our
bindings "to the <integration_name> server", we now recommend
installing our bindings "to the server where the
<integration_name> bot lives". Technically, the latter is more
accurate.
Now, we further clarify in the create-stream.md macro that even
if users follow our default stream name recommendation for a
given integration, said stream must still be explicitly created.
Previously, we used Integration.name as the recommended stream
in our macros. Now, we have a dedicated attribute set in the
Integration class (that WebhookIntegration and GithubIntegration
inherit from) for the recommended stream name in cases where
the stream name is different than the name of the integration
itself.
This macro is an alternative to git-webhook-url-with-branches.md,
which contains the full URL with a `branches` query parameter at
the end. This macro is for when we just want to specify that this
can be done but the URL to append to can be variable or is unique
to a particular integration (and thus, doesn't warrant its own
macro and a full URL example).
This better sets expectatations for the fact that in Zulip, the
Organization settings UI is available read-only to non-administrator
users.
Tweaked by tabbott to update some additional references.