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.