* Removes the confusing notes about supporting only the Slack standard
plan.
* Removes the confusing notes about importing users from a
different organization.
* Clarifies a few sections, improves formatting, etc.
Still some errors (e.g. "Hover over a message to replace the message's
timestamp with its message actions" is no longer correct), and a lot of
other improvements to be made, but just doing a quick fix of a few things I
noticed.
Now that we have support for displaying custom profile fields, this
adds administrator-level support for creating them.
Tweaked by tabbott to fix a few small bugs and clean up the commit message.
Fixes#1760.
An integration with RSS can be much easier to set up with Zapier.
Since the current RSS integration predates Zapier, we should at
least mention that there is an easier way to set it up via
Zapier!
webhook-errors.log file is cluttered with Stream.DoesNotExist
errors, which hides the errors that we actually need to see. So,
since check_message already sends the bot_owner a PM if the webhook
bot tries to send a message to a non-existent stream, we can ignore
such exceptions.
It's possible that this won't work with some versions of the
third-party backend, but tabbott has tested carefully that it does
work correctly with the Apache basic auth backend in our test
environment.
In this commit we start to support redirects to urls supplied as a
'next' param for the following two backends:
* GoogleOAuth2 based backend.
* GitHubAuthBackend.
This commit adds a generic function called check_send_webhook_message
that does the following:
* If a stream is specified in the webhook URL, it sends a stream
message, otherwise sends a PM to the owner of the bot.
* In the case of a stream message, if a custom topic is specified
in the webhook URL, it uses that topic as the subject of the
stream message.
Also, note that we need not test this anywhere except for the
helloworld webhook. Since helloworld is our default example for
webhooks, it is here to stay and it made sense that tests for a
generic function such as check_send_webhook_message be tested
with an actual generic webhook!
Fixes#8607.
We now include whether the message was a private or group private
message; this is particularly important with the new setting to
disable including any message content in these emails (since in that
case, one doesn't know anything about the message types).
@brockwhittaker wrote the original prototype for having
pills in the recipient box when users compose PMs (either
1:1 or huddle). The prototype was test deloyed on our
main realm for several weeks.
This commit includes all the original CSS and HTML from
the prototype.
After some things changed with the codebase after the initial
test deployment, I made the following changes:
* In prior commits I refactored out a module called
`user_pill.js` that implemented some common functions
against a more streamlined version of `input_pill.js`,
and this commit largely integrates with that.
* I made changes in a prior commit to handle Zephyr
semantics (emails don't get validated) and tested
this commit with zephyr.
* I fixed a reload bug by extracting code out to
`compose_pm_pill.js` and re-ordering some
calls to `initialize`.
There are still two flaws related to un-pill-ified text in the
input:
* We could be more aggressive about trying to pill-ify
emails when you blur or tab away.
* We only look at the pills when you send the message,
instead of complaining about the un-pill-ified text.
(Some folks may consider that a feature, but it's
probably surprising to others.)
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.
Now, the fixtures.json file:
* Has all keys sorted alphabetically.
* Has a space after every `:`.
The file was generated using json.dumps with the appropriate
formatting parameters.
Note that this is one of the few fixtures that isn't tested against
a running server. But it still makes sense to move it to fixtures.json so
that it is rendered with indenting and a space after every `:` by
the api_code_example extension.
This works simimlar to the "n" key for next topics.
This commit does a few things:
* It wires up the hotkey to an existing function
that could change narrows.
* It adds documentation.
* It adds logic to make sure the compose box does
not open.
@showell helped a bit with the wording of comments here.
Fixes#4874
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.
Previously, we used to raise an exception if the direct dev login code
path was attempted when:
* we were running under production environment.
* dev. login was not enabled.
Now we redirect to an error page and give an explanatory message to the
user.
Fixes#8249.
This commit adds a test for the sample fixture for when an invalid
stream name is passed to a query that expects a valid stream name
as an argument. This is the case with almost all of our queries
documented under the sidebar heading "Streams".
EDIT: Actually, I was wrong. This payload is highly specific to
get-stream-id, so it shouldn't be a part of common-error-payloads
at all.
In templates/zerver/api/delete-queue.md, we have a sample fixture
for when the queue_id passed to client.deregister_queue is not
valid or the event queue in question has already been deleted.
This commit tests that fixture.
Note that this error payload is specific to client.deregister_queue.
In templates/zerver/api/create-user.md, we have a sample fixture
for when a client attempts to create a user with the same email
as an existing user. This commit adds a test for that fixture.
Note that this error payload is specific to client.create_user
and this error payload isn't generated anywhere else.
In templates/zerver/api/add-subscriptions, we have a sample fixture
for when the user being subscribed is already subscribed to a
stream. This commit tests that fixture against a running server.
This commit adds tests for the fixture for when a user is not
authorized (perhaps because the query requires the use of admin
privileges) for a particular query.
In templates/zerver/api/update-message.md, we have a sample fixture
for when a zulip.Client does not have the permission to update/edit
a particular message. This commit adds a test for that fixture.
Also, tools/test-api now also uses a non-admin client for this test,
which might come in handy in the future.
This commit adds tests for the sample fixture for when a required
request argument is missing. Also, it moves the sample fixture
to common-error-payloads.md, since this is an error payload that
is common to most requests (except the ones that don't take any
arguments).
In templates/zerver/api/private-message.md, we have a sample fixture
for when the email address of the PM's recipient is invalid. This
commit makes sure that fixture is tested against a running server.
In templates/zerver/api/stream-message.md, we have a sample fixture
for when the target stream does not exist. This commit adds a test
for that sample fixture.
We make request to check availibity of subdomain which also checks the
subdomain for illegal characters. Duplicating the backend logic in
frontend in this case is thus no longer necessary.
We have a good "Help Center" section in the footer, where a user
may already expect to look for help/support related requests, so
we can replace the navbar spot there with the "Why Zulip" page link.
This commit modifies the Markdown extension in bugdown/api_code_examples.py
to support rendering code examples in multiple languages by specifying
the language like so:
{generate_code_example(python)|doc.md|example}
This makes us one step closer towards adding support for testable
JavaScript code examples.
In this commit we add support for some tags which are also called
void-elements according to
http://w3c.github.io/html/syntax.html#void-elements to be parsed by
our template parser and get tagged as singleton_html_tags.
Fixes: #8387.
This is the first step in cleaning up the bot edit code.
Since the bot edit form appears dynamically, we remove
it from the static HTML scaffold, of which settings_sidebar
is a part of.
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.
To generate a code exammple,
{generate_code_example|<api_doc_md>|example} sounds better and
more intuitive than,
{generate_code_example|<api_doc_md>|method}
Users having only account in one realm will not be distracted by realm
name in subject lines of every email. Users who have multiple
accounts in realms can turn this setting on and receive a
corresponding realm name in email's subject.
Tweaked by tabbott to rebase and address a few small issues.
Fixes#5489.
Also refactor the "panels"/banner code to be a bit clearer about how
it's supposed to generically work, using [data-process] as a uniquely
identifying marker.
Fixes: #8166.
[greg: rebased and squashed a series of fixup commits.]
Fixes improper katex rendering in markdown help template. The
rendering was originally correct, but was broken when we upgraded to a
new version of KaTeX with a different HTML/CSS interface.
"Sign up" -- pretty important for people to be able to read that!
There's also the "or" that gets rendered as a big "OR" in a divider --
but that styling is too brittle, so that if "or" becomes e.g. "oder",
the lines stay the length they should be for "or" and the lot of them
wrap. Yuck. Better to leave it as "or" until that's fixed.
If there was a realm on the base URL, its logo and name were being
displayed when registering a new realm (i.e. the page where realm details
are entered, after confirming email). This commit prevents the realm
details from being displayed.
Fixes#8186
This commit uses the Markdown extension defined in
zerver/lib/bugdown/api_generate_examples to generate the
example fixture and code example, so that both are tested
in zerver/lib/api_test_helpers.
This commit uses the Markdown extension defined in
zerver/lib/bugdown/api_generate_examples to generate the
example fixture and code example, so that both are tested
in zerver/lib/api_test_helpers.
This commit uses the Markdown extension defined in
zerver/lib/bugdown/api_generate_examples to generate the
example fixture and code example, so that both are tested
in zerver/lib/api_test_helpers.
This commit uses the Markdown extension defined in
zerver/lib/bugdown/api_generate_examples to generate the
example fixture and code example, so that both are tested
in tools/lib/api_tests.
This commit uses the Markdown extension defined in
zerver/lib/bugdown/api_generate_examples to generate the
example fixture and code example, so that both are tested
in tools/lib/api_tests.
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 commit uses the Markdown extension defined in
zerver/lib/bugdown/api_generate_examples to generate the
example fixture and code example, so that both are tested in
tools/lib/api_tests.
This commit uses the Markdown extension defined in
zerver/lib/bugdown/api_generate_examples to generate the example
fixture and code example, so that both are tested in
tools/lib/api_tests.
This commit uses the Markdown extension defined in
zerver/lib/bugdown/api_generate_examples to generate the example
fixture and code example, so that both are tested in
tools/lib/api_tests.
This commit uses the Markdown extension defined in
zerver/lib/bugdown/api_generate_example to generate the example
fixture and code example, so that both are tested in
tools/lib/api_tests.
This is the last commit in the series of commits for completing the
project of cleaning up our html templates to have 4 space and
valid indentation.
Fixes: #1236.
In this commit we also fix a test which would fail as a result of
doing this cleanup since the test wasn't designed to take into
account the space chars which might occur in the beginning of a
html line.
It makes sense to make our Python and JS API examples more visible
than our curl examples, since Python is what most people will tend
to use.
Also, from a design perspective, an API documentation page that
starts off with a shiny Python example with syntax highlighting
looked much better than having a bland curl example be the first
thing readers see.
In this we change the way 'Sending...' is displayed. Instead of
hardcoding it into the template we make change the paradigm so
that we can have a flexible message about what's happening
rather than just always saying 'Sending...'. For eg. this will
help in the upcoming feature of Scheduled Messages by having this
message say 'Scheduling...'.
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 main cleanup here is to move the examples out of the bulleted
list, which was getting rendered in an ugly/confusing way.
I also removed some redundant text, fixed some typos, and changed
the wording a bit.
This commit documents the get-streams endpoint, which can be
by making a GET request to /api/v1/streams.
Note that in the code examples, JavaScript is missing an example
for how to pass in the `include_` query parameters. That is
because zulip-js's client.streams.retrieve function doesn't take
any arguments and zulip-js does not export any function equivalent
to client.call_endpoint in python-zulip-api/zulip.
The JS module we ask our users to install in the installation
instructions is zulip-js, not zulip. These examples would fail
with the latter. This commit updates the examples to use the
name zulip-js.
This commit does the following:
* Move the Arguments table data from stream-message.md and
private-message.md to a JSON file.
* Add a Markdown extension that allows one to include and render
a table from a JSON file like so:
{generate_arguments_table|arguments.json|private-stream.md}
* Use Bootstrap's .table class to format the table instead of
relying on custom CSS.
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 commit adds the following:
* A table specifying the arguments that are required for this API
call.
* Examples of JSON responses.
This will help us in obsoleting api_endpoints.html.
This commit adds the following:
* A table specifying the arguments that are required for this API
call.
* Examples of JSON responses.
This will help us in obsoleting api_endpoints.html.
This commit splits usage.md into two separate docs,
stream-message.md and private-message.md. The arguments and return
values for sending a stream message are somewhat different from
those of sending a private message, so it made sense to split the
two up for clarity.
Currently, users are warned when mentioning @all and @everyone, but not
when posting on the #announce stream. Confirm with users that they want
to send their message on #announce if over 60 people are going to be
notified.
Fixes#6928.
This reverts commit 5a1869901. I reviewed this change and decided not
to merge it yet, but then I did anyway <_< >_>, along with some others
in the same PR.
When a user with no account tries to login using GitHub/Google auth
they are given an option to register. If the user chooses to
register, a mail is sent for verification and the user has to continue
registration as if they signed up using email. This is confusing and
a bit annoying, so instead of sending email I have changed the
procedure to just redirect to /register where they can start
registration over and proceed normally.
An ideal implementation for this would be to just allow users to
continue registration without email or going back to register.
[greg: tweaked to keep existing user-facing text]
This makes the bankruptcy modal compatible with dark mode by adding the
`.modal-bg` class to switch it to dark mode, and by setting a darker
background and border color to the modal header.
This makes the edit history overlay dark mode compatible by changing
the background to the dark blue along with changing the highlight
colors to work with white text and dark backgrounds.
We made this change because users often unnecessarily click "Home"
first in their use of Zulip, because it seems appealing. While "All
messages" isn't quite precise (it doesn't include muted streams), it
does describe relatively simply the interleaved view that this
represents.
This commit leaves everything as "home" in the code, and only changes
user-visible strings and docs. Changing the code will be a big project;
there are hundreds of relevant occurrences in variable names, etc.
Further, we'll probably want to convert those various variable names
in different ways.
Tweaked by tabbott to extend the commit message and update a few comments.
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 first part of this change is to have the "Your bots"
tooltip not lie about creating `.zuliprc`, because it
doesn't put a dot in front of the file.
And then the more significant change here is to make
the "Running a bot" documentation use realistic filepaths,
both in terms of where the download typically puts the file,
and where you want to move it to.
Pointing these at the latest release, rather than the latest version
in master, allows us to make changes to the installer and document
them properly in master, without making the instructions confusingly
wrong for people who just go to the website or the GitHub repo page
and follow instructions to install.
This was basically rewritten by tabbott, because the code is a lot
cleaner after just rewriting the ZulipPasswordResetForm code to no
longer copy the model of the original Django version.
Fixes#4733.
It appears as though the ordering of the overlays in the DOM is
overriding their z-index in Safari on mobile. This moves them up to
the top of the template ahead of the header so that the header will no
longer display above the overlays in positioning.
Fixes: #7248.
We got asked about this from a potential user, and they seemed fairly
excited and confused by it. In particular, it wasn't obvious that
deactivating a user was the feature they were looking for.
This should get test-documentation and test-help-documentation passing
again after we moved everything around in the last commit.
There are a lot more absolute links (generally in code comments) to
update, but they are lower-priority and can be done in a follow-up
pass.
The CSS linter was pretty hard to reason about. It was
pretty flexible about certain things, but then it would
prevent seemingly innocuous code from getting checked in.
This commit overhauls the pretty-printer to be more composable,
where every object in the AST knows how to render itself. It
also cleans up a little bit of the pre_fluff/post_fluff logic
in the parser itself, so comments are more likely to be "attached"
to the AST node that make sense.
The linter is actually a bit more finicky about newlines, but
this is mostly a good thing, as most of the variations before
this commit were pretty arbitrary.
The intended use of $$ is for inline expressions, not for multiline
ones; ```math is an acceptable alternative for the latter. Hence,
the $$-syntax for inline TeX no longer permits newlines within it.
This was also necessary for the next change to be sensible; namely
allowing for spaces around both $$ when crafting inline TeX instead of
forcing everything to be crammed together, e.g. $$x=7$$. In order to
avoid uninentionally creating inline expressions, the opening and
closing $$'s of an inline expression must now both exactly consist of
two dollar signs, no more and no less.
Fixes: #6488.
This adds a slide class that specifies that the JS actions for sliding
up and down sections is the desired behavior, along with a bit of CSS
to help display correctly in the case of not being a sliding section.
This removes the leading whitespace that was approximately the width of
a space character that would get underlined when hovering over any one
of the global filters.
In templates/zerver/api/main.html, since the current context isn't
passed to render_markdown_path when rendering an article,
render_markdown_path doesn't have the context to render values such
as api_url. This commit makes sure that it does by passing a dict
called api_uri_context to render_markdown_path when rendering an
article.
It's kind of awkward that this takes the scheme-relative URL -- either
the full URL, or maybe just the host, would make more sense. But on a
bit of study of the plugin's source, I can't convince myself that it
won't break if given the full URL with the scheme. (See a code
comment thread in #7116.) So leave the substance as is, pending the
plugin itself getting some cleanup, but do fix the sentence's English
grammar since we're looking at it.
This was apparently completely broken for some time, and got a bit
worse with my recent changes (enough to fail a test).
Since the plan for this page likely involves dissecting and
eliminating it, I think it makes sense to just fix it hackishly and
move on.
In addition to decreasing the excessive number of bundles we had, this
will set us up to fix rendering of code blocks when clicking the
sidebar links in the /api-new site.
This commit allows for the /api-new/ page to rendered similarly to our
/help pages. It's based on the old content for /api, but we're not
replacing the old content yet, to give a bit of time to restructure
things reasonably.
Tweaked by eeshangarg and tabbott.
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 creates a template for the /team/ page that is currently just
embedded inside the /about/ page. This includes the titles for core
team members with their pictures.
Lets administrators view a list of open(unconfirmed) invitations and
resend or revoke a chosen invitation.
There are a few changes that we can expect for the future:
* It is currently possible to invite an email that you have already
invited, it might make sense to change this behavior.
* Resend currently sends an invite reminder instead of resending the
original invite, this is because 'custom_body' was not stored when
the first invite was sent.
Tweaked in various minor ways, primarily in the backend, by tabbott,
mostly for style consistency with the rest of the codebase.
Fixes: #1180.
Tweaked by tabbott to have the field before the invitation is
completed be called invite_as_admins, not invited_as_admins, for
readability.
Fixes#6834.
All links by default had an underline on hover, including when
<a> tags were wrapping <div> and <img> tags, which made for a small
underline near them on hover. This better focusses the underline
behavior to just paragraphs and lists.
This effectively implements the feature of default stream groups,
except for a UI, nice styling, etc.
Note that we're careful to not have this do anything in an
organization that doesn't have any default stream groups.
This creates a dropdown in place of the normal register/login links
you get when logged out, with an option to go to the app or log out if
that appears you click on the avatar.
A bit more work is needed to make this look really good, but it's a
great start.
If an organization doesn't have the EmailAuthBackend (which allows
password auth) enabled, then our password reset form doesn't do
anything, so we should hide it in the UI.
Making the same point (that you can configure the notifications in
settings) at both steps felt pushy. I think the first prompt is
actually best kept to a minimum of words, so leave that one with
just the ask.
In the second step, try an active pitch. This could go either way, or
be any number of other messages, but the settings line felt a little
defensive to me, like it was suggesting that our notifications would
be noisy and here's a way you can try to mitigate that. I think with
our default settings (and in an org with mostly-reasonable humans, but
even a large and busy one) they're actually not at all noisy; and if
we learn of situations where that's not true, we'll work to fix that.
So, try this line instead.
A style note: I chose "your team" here to refer to the people the user
communicates with in their organization. We consistently say either
"organization" or sometimes "realm" for the concrete thing in the
product that is the whole universe of streams and users, etc., that a
given account lives in; but that feels too formal here. Conversely,
one reason we don't say "team" for an organization is that it feels
too cozy and small, more appropriate for 8 people who interact every
day than for 80 or 8000 people; but this line is mainly about those
8 people even if the organization has 8000. There are some examples
of this already in the codebase; see `git grep -w team`.
i18n note: These passages of a couple of connected sentences should
generally be marked for translation as one message, not several
separate ones. That helps the translator be sure of the context so
they can translate appropriately. For example, in the second prompt
in this version, there's an implicit "because" relationship between
the two sentences, and in some languages (I'm 90% sure this is true in
Japanese), it would be weird to leave it implicit and the second
sentence should contain the equivalent of "That's because".
Aditya Bansal
Vishnu Ks
Rhea Parekh
Balaji2198
Cynthia Lin
Eeshan Garg
Rishi Gupta
Tim Abbott
Anurag Sharma
Umair Khan
Yago González
sinwar
Anupam-dagar
Shivam Gera
amanagr
Lyla Fischer
YJDave
Steve Howell
Marco Burstein
Utkarsh Patil
Weronika Grzybowska
Viraat Chandra
Abhishek Sharma
Abhigyan Khaund
Vaida Plankyte
Brock Whittaker
Priscilla
Robert Hönig
Roman Godov
VishalCR7
rht
Tarun Kumar
Greg Price
Aditya Shridhar Hegde
Jerry Zhang
Rohitt Vashishtha
akashnimare
Aastha Gupta
civilnewsnetwork
Shreyansh Dwivedi
Nikhil Kumar Mishra
AlloulDorian
Tommy Ip
Sumana Harihareswara
Mohd Ali Rizwi
Andy Perez
sagar-kalra
Jack Zhang
Harshit Bansal
Henrik Pettersson
Alexis La Porte