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.
Stripe Checkout means using JS code provided by Stripe to handle
almost all of the UI, which is great for us.
There are more features we should add to this page and changes we
should make, but this gives us an MVP.
[greg: expanded commit message; fixed import ordering and some types.]
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 commit ensures that size of each graph is the same before and
after the data is loaded. It also adds a loading indicator to each
graph until the data is loaded.
Fixes https://github.com/zulip/zulip/issues/6490
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.
I've wanted this when looking at a tab from the day before.
Also provides the date and time in UTC, which is handy for
interpreting some of the data.
Pretty sure this is not the world's cleanest way to do this in the
front-end code. It'll do for now.
Not only does this look better, but in the parallel case of ≤
(coming soon) it prevents a naive parser, like in our linter,
from getting confused by seeing a "<" character.
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.
Substantively, this makes the table more readable by grouping users
into expanding sets by level of activity: active in last day, active
in last week, have an account at all. The class "active in last week",
as opposed to "active in last week but not in last day", makes more
natural comparisons both between realms and for one realm through time,
and it's less sensitive to the details of our definitions.
This also makes the terminology more standard. We already made that
change in the display, in the previous commit; as we go through the
logic here, we adjust the terminology in the code too.
Jerry Zhang
rht
Robert Hönig
Cynthia Lin
Eeshan Garg
Balaji2198
Aditya Bansal
Brock Whittaker
Steve Howell
Vishnu Ks
Rohitt Vashishtha
Rhea Parekh
akashnimare
Rishi Gupta
Aastha Gupta
Marco Burstein
civilnewsnetwork
Shreyansh Dwivedi
YJDave
Utkarsh Patil
Greg Price
Nikhil Kumar Mishra
AlloulDorian