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".
This presents multiple states for the subdomain input option
depending on the existence of a root domain.
Commit modified heavily by Brock Whittaker <brock@zulipchat.com>.
Fixes#6863.
I think an hour after signup is not the right time to try to get someone to
re-engage with a product.
This also makes the day1 email clearly a transactional email both in
experiencing the product and in the eyes of various anti-spam laws, and
allows us to remove the unsubscribe link.
The rules here are fuzzy, and it's quite possible none of Zulip's emails
need an address at all. Every country has its own rules though, which makes
it hard to tell. In general, transactional emails do not need an address,
and marketing emails do.
This is a two-step notifications process that will ask a user
to enable notifications and if they click exit give them three
options:
1. Enable notifications.
2. Ask later.
3. Never ask on this computer again.
The first two are self-explanatory (ask later = next session it
asks again). The third is captured and stored in localStorage and
a check is done on page load to see whether or not notifications
should be displayed.
Commit modified heavily by Brock Whittaker <brock@zulipchat.com>.
Fixes#1189.
We swapped the function of these hotkeys, but forgot to update these:
* left_sidebar: Update hotkey to 'q' in filter stream option title.
* right_sidebar: Update hotkey to 'w' in search people option title.
This allows CSS to discriminate by platform and show particular
content; in this case showing things with the attribute
[if-zulip-desktop] content only on “ZulipElectron”.
This makes the developer experience of the /emails pages significantly
cleaner, since you don't have to look at both the HTML and the text
for each message at the same time.
Fixes#6844.
This was a not-well-thought-through behavior change done in #6489; the
part that was actually a problem was ctrl-enter not producing spaces
anyway.
So we fix this, and also add a comment explaining why.
Fixes#6908.
The original "quality score" was invented purely for populating
our password-strength progress bar, and isn't expressed in terms
that are particularly meaningful. For configuration and the core
accept/reject logic, it's better to use units that are readily
understood. Switch to those.
I considered using "bits of entropy", defined loosely as the log
of this number, but both the zxcvbn paper and the linked CACM
article (which I recommend!) are written in terms of the number
of guesses. And reading (most of) those two papers made me
less happy about referring to "entropy" in our terminology.
I already knew that notion was a little fuzzy if looked at
too closely, and I gained a better appreciation of how it's
contributed to confusion in discussing password policies and
to adoption of perverse policies that favor "Password1!" over
"derived unusual ravioli raft". So, "guesses" it is.
And although the log is handy for some analysis purposes
(certainly for a graph like those in the zxcvbn paper), it adds
a layer of abstraction, and I think makes it harder to think
clearly about attacks, especially in the online setting. So
just use the actual number, and if someone wants to set a
gigantic value, they will have the pleasure of seeing just
how many digits are involved.
(Thanks to @YJDave for a prototype that the code changes in this
commit are based on.)
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.
This changes the "Server" and "Account" attributes in the info log
to render links so that they are guaranteed to have our styling
and behavior across all email clients.
Create a new custom email backend which would automatically
logs the emails that are send in the dev environment as
well as print a friendly message in console to visit /emails
for accessing all the emails that are sent in dev environment.
Since django.core.mail.backends.console.EmailBackend is no longer
userd emails would not be printed to the console anymore.
This removes the underline on hover and changes the text to get to the
index.
This also changes it to an <h2> tag so that it will be more inline
with the styling of the rest of the sections, but without the
down chevron.
Some email services will provide default styling for things like
buttons, and in this case the site created a style that had a
`background` attribute that overrode our `background-color` attribute
because of CSS importance heirarchy. This swiches us to use
`background` as well.
This also forces no `text-shadow` on buttons.
Fixes: #6775.
This adds a max-width constraint to the hero content so that the images
inside the hero don’t keep expanding forever and eventually outside of
the hero’s bounds.
Fixes: #6713.
This deserves a fact-check to make sure I haven't simplified
anything past what's true! Note in particular the TODO comments.
Especially in particular, I took out references to the .zip installer
for macOS and the .deb installer for Linux. I couldn't tell in what
situation we'd really want to steer a user toward them (and wouldn't
recommend instead either the .dmg installer, or the apt or AppImage
instructions, respectively), so taking them out simplifies the
instructions and avoids presenting the user with a choice they have no
context for making. But if there is such a situation, then we can put
them back.
This shows the download instructions only selectively based on
whether the device has download instructions for it. This means
currently it shows the page for Windows, Mac, and Linux.
The issue before was that the left sidebar would become too tall for
the screen because the standard header that has “STREAMS” and buttons
is 20px tall, and this one is 30px tall. This makes it much shorter,
changes the text to be the same style as the “STREAMS” text (medium
grey, uppercase text).
The markup is then fixed to be significantly less verbose than before —
changing a list to just a simple link.
Originally we wanted it to be short, since we were worried about attention
spans. But it seems like people are willing to read quite a bit when
choosing a chat product, and our "10 second" pitch should just be a video,
rather than a small amount of text.
On a standard keyboard, 'q' is to the left of 'w', so it makes sense
for the hotkeys for the left and right sidebars to be `q` and `w`,
respectively, not the other way around.
This allows user to view all group private conversation messages
with a specific user. That is, it views all the the group private
messages from groups which include the given user.
Add search suggestion for group-pm-with. Add operator name
and description in "Search operators" tab.
Add change in tab name to "Group Messages" when using this operator.
Add frontend_tests for group-pm-with search operator.
Fixes: #3882.
Not sure why we have `overflow-y: scroll` in `messages` container in
missed messages email template when it is not a fixed width container
but anyway changing it to `overflow-y: auto` seems to be a safe change
as it will remove the ugly looking inactive scrollbar that was being
displayed there besides the `messages` container without changing the
functionality(if any).
This changes the second plans block label to dark grey responsively
when the width is less than 1390px because the white text does not
appear on that portion of the white background when the block collapses
down a line.
This restructures organization settings and permissions to be
more accurately grouped and for the permissions page to not be too
long.
CHANGES:
PROFILE:
(this was split out)
organization-profile-admin.handlebars:
form #1:
name
description
(SUBMIT)
avatar:
(UPLOAD)
(DELETE)
SETTINGS:
organization-settings-admin.handlebars:
language (mostly untouched)
message editing:
time limit/history/retention
message feed:
mandatory-topics
preview images
preview websites
PERMISSIONS:
organization-permissions-admin.handlebars
(mostly stuff was removed)
Joining:
restrict domains
require invite
User Identity:
name changes
email changes
Streams/Emoji:
creating streams:
waiting period (ADDED)
adding emojis
(SUBMIT) for whole panel
The profile group (name, description, avatar) were split into a new
page that did not previously exist, and the permissions was stripped
of message settings (message editing, message feed), but keeping the
"waiting period" input and putting it in the "Streams & custom emoji"
section.
Fixes: #5844.
This cleans up the styling of the page by adding the white box
around the text content, and by making the header the same
`.get-started` class as other headers in the portico-signup group.
In auth setup, if you're at the error page you may be inclined to
refresh the page once setting up auth after restarting the server,
but the error page is a static page, so add instructions to go
back to the login pages again and try the auth flow from there.
This removes the old flex model for the footer to stay at the bottom
of short pages and instead always just positions the footer below
the portico content and makes the content generally tall enough that
issues don't occur.
This replaces the old footer that has one section with a small list of
items. This expands the footer to have multiple sections.
Actual content tweaked and tagged for i18n by tabbott.
Use this new variable to determine if the user already exists while
doing registration. While doing login through GitHub if we press
*Go back to login*, we pass email using email variable. As a result,
the login page starts showing the "User already exists error" if we
don't change the variable.
This makes the /help/ sidebar more discoverable at windows less
than 1000px in width because it makes it stick out a bit when it
is closed with the hamburger menu at the top.
Fixes: #6038.
This refactors and fixes unicode issues where entities don't display
properly due to being a special character that seems to be rendered
incorrectly in a non-deterministic way every time.
This adds the authors to the Zulip repository on GitHub from
/authors/ along with re-styling the page to fit the same
aesthetic as /for/open-source/ and other product-pages.
In the case of no subdomains, the input is too large because the JS
calculated size does not account for padding. The correct solution is
to do this in JS.
Category 'All' -> text 'Filter by category'; icon chevron right when
the dropdown is closed, icon chevron down when the dropdown is open
All other categories -> text CATEGORIES[state.category]; icon chevron down
Update Email, Beanstalk, Hubot, JIRA, and Trello integrations
links.
The Hubot integrations section (/integrations#hubot-integrations)
was removed in an earlier redesign of /integrations. This commit
replaces the link with the hubot-scripts organization on
Github, which displays the comprehensive list of all integrations
available via Hubot.
Fixes#5875.
A large portion of the diff for landing-page.js is due to refactoring the
contents of integrations_search into top level UI update functions.
State flows as follows: dispatch(action) -> render(state) -> update UI
Routes now use pushState instead of hashes.
On transition between categories scrolling position is fixed,
and on transition between catalog and integration sub-pages the page
scrolls to the top.
This should significantly improve the user experience for new users
signing up with GitHub/Google auth. It comes complete with tests for
the various cases. Further work may be needed for LDAP to not prompt
for a password, however.
Fixes#886.
This allows us to go to Registration form directly. This behaviour is
similar to what we follow in GitHub oAuth. Before this, in registration
flow if an account was not found, user was asked if they wanted to go to
registration flow. This confirmation behavior is followed for login
oauth path.
This is a redesign of the features landing page from the current style
that includes the new sections in a grid format as well as some new
high-quality sections.
While humans can disambiguate 'upper right' and 'top right' to one area,
it might help with any machine reading comprehension task by choosing a
more regular wording.
Apparently, the filters implementation was doing some sort of strange
caching, where you would need to restart the server in order to
refresh for changes to the markdown content.
We fix this by switching to just calling the render_markdown_path
function from Jinja2.
Fixes#5974.
Those buttons were contained in an anchor element. This isn't
valid HTML5 and caused the buttons to be focused on twice when
using tab-based navigation. Replacing the anchor with a form
element fixes this issue.
This either removes aria-hidden=true assignments from buttons with
text, or adds a span to only hide the 'x' symbol rather than the
button for closing buttons.
This adds a link to the Zulip statistics UI, making it easy for users
to discover. We'd been waiting on doing this until the visual design
of that page was satisfactory, which it is now.
Fixes#5774.
Prior to this commit, 7 megabytes of images (through 253 individual requests)
were heavily slowing down the initial load. With this commit, we load only the
logos (60 or so images).
Documentation and images for the individual integration sub-pages is requested
separately using the /integrations/doc/ endpoint, which returns HTML.
This redesigns the /help/ page sets to be a single page app that uses
history.pushState to work the same as the old app.
The big new feature is that now we have the index in a nicely designed
left sidebar.
The MitUser table was removed in df525ad.
confirm_mituser.html could have been accessed through the last few lines of
confirmation/views.py:
templates.insert(0, 'confirmation/confirm_%s.html'
% (obj._meta.model_name,))
The commit message on df525ad suggests there was another way
confirm_mituser.html could have been called, but I don't currently see
evidence for it in the code.
These are some strings I spotted in English when playing around a bit
with the UI set to German, where our translations are near complete.
It'd be great to have a more systematic way of spotting this kind of
omission. Probably a fairly simple linter could catch a lot of cases.
This system hasn't been in active use for several years, and had some
problems with it's design. So it makes sense to just remove it to declutter
the codebase.
Fixes#5655.
About to add another template for digest and missed message emails. Another
natural name would be email_base_transactional, but the followup_day{1,2}
emails aren't really transactional.
On /integrations.
For scalability and people who type fast, update_integrations is
debounced; the function will postpone its execution until after
50 milliseconds after it was last invoked.
The backend errors are currently displayed to the right side of the
input field. This is different from the frontend validation errors
which are displayed at the bottom of the input field (and also looks
really bad). Also frontend validation uses <p> instead of <div> to
display errors so I have changed this also to make both uniform.
Ideally these shouldn't have spaces around them either, but the
font we're using (at least in my browser) has em-dashes that
hardly merit the name -- about twice the width of an interword space.
So I leave them bulked up with spaces.
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.
This isn't very slick, but it should get the main points down,
and it's past time we got something like this up. Definitely
needs in the future another pass at the text, and also some images
(screenshots, etc.) and styling.
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.
For almost all of these, the verbose support offer clause is almost the same
as the non-verbose version. The distinction carries extra carrying cost when
coming up with new copy, testing new email designs, etc.