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.
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 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.
It's hinted in the registation process, and as long as one person in the
realm does it, everyone else will know. The tooltip also draws too much
visual attention.
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 makes the avatar portion more responsive and efficient on many
screen settings and also fixes some of the design incongruences present
on the page.
This removes the old base button style which was a blue button and
kills the unnecessary .white class which was essentially just acting as
the new button base.
This then removes all references throughout the settings/subscriptions
pages to those button styles.
This also fixes the strange button styles that changed the :hover and
:active opacity to 0.05 which led to unpredictable results on various
backgrounds.
This cleans up the styling of the organization and the user settings
components to be more responsive and have more consistent styling with
the rest of the overlays.
Previously, the code to hide "Change email" button on page load when
email changes are disabled was present in settings.js using jquery to
hide the button. Now, the show/hide is handled in the account-settings handlebars.
This adds to Zulip support for a user changing their own email
address.
It's backed by a huge amount of work by Steve Howell on making email
changes actually work from a UI perspective.
Fixes#734.
This re-adds the deleted "Delete Avatar" button back to the
settings/your-account tab view in the overlay, which only appears
if you do not currently have a gravitar.
This is technically part of the settings page redesign in the next
commit, but it's probably useful to keep separate, since it touches
totally different code.
There was a duplicate #full_name ID being added many times in tables.
They should be removed because they are not being called anywhere and
should not exist in multiples.
Tim Abbott
Greg Price
Rishi Gupta
Brock Whittaker
Vaida Plankyte
Vishnu Ks
vaibhav
fionabunny
Aditya Bansal
digi0ps
Yago González
Amala Deshmukh
Raghav Jajodia
Umair Khan
Steve Howell
Sampriti Panda
Amy Liu