This restores the property that changing one's name in on browser's
"account settings" also changes the user's name in other browser windows'
"account settings" pages.
This makes this UI widget more consistent with its neighbors.
tabbott: This introduces a bug with how the `full_name_field` HTML is
managed; it should be done via the `server_events.js` handler.
- When password fields are cleared, update password strength bar.
- On data dismiss, clear password fields.
- Exclude forgot-password div from focus.
- On enter key, modal should be submitted not dismissed.
- Change password btn text from "Change password" to "*****"
This makes many diffs that touch our JS dependencies in package.json
much, much more readable by suppressing multi-thousand-line changes.
With that kind of change routine, it's clear this isn't a file people
are closely reviewing the text diffs in anyway.
This script and our CI scripts tools/travis/{backend,frontend} have
stayed pretty well in sync in the 6 months since 360c27ded made that
relationship explicit and easy to check!
Just one small exception; so fix that.
This may or may not be temporary, but either way, the other code is
there in source control, and the "why" of disabling gitlint is the
helpful bit for a comment.
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
Circle has been much more robust than Travis in the few weeks we've
had them both enabled, as well as somewhat faster. By disabling
Travis, we're no longer exposed to its spurious failures.
One suite remains on Travis: the "production" suite. This work is
being tracked in #7748.
We haven't actually been using this zulipbot feature for a long time
(haven't applied the `travis updates` label which it looks for.)
Rather than port the config to CircleCI, just cut it for now; we can
always add something like it back if we start using it.
Injecting the generated-file warning into the settings dict felt a
little unnecessarily magical. A warning like this is always going
to be at the top; the way it might differ between files is mainly
if the syntax for a comment varies, and in that case a simple
substitution like we're doing in this template wouldn't be enough
to express the difference anyway. So, embrace the hardcoding.
Now, the template and the images.yml entry have a very simple
relationship: the keys in one are exactly the keys in the other.
That's good for people quickly and confidently understanding it.
A comment like this was removed in
fa44d2ea6 "settings: Remove autoscroll_forever setting."
The comment went on to say something about autoscroll, but this
part still seems relevant. While here, adjust grammar and caps.
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.
Some of our code examples can only be run with administrator
credentials (such as create-user). Thus, the Markdown extension
for generating code examples should have an option to include
the lines that recommend using an admin zuliprc instead of a
non-admin one.
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.
Now that the Markdown extension defined in
zerver/lib/bugdown/api_generate_examples depended on code in the
tools/lib/* directory, it caused the production tests to fail since
the tools/ directory wouldn't exist in a production environment.
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 commit adds a Markdown extension that allows the following
syntax,
{generate_code_example|<md_file_name>|<fixture or method>}
to generate code examples and fixtures found in tools/lib/api_tests.py
and templates/zerver/api/fixtures.json, respectively.
We don't disable code by commenting it out -- that leaves a mess.
We delete it. Remembering what the code was is what source control
is for.
This fixes cd849bc3f "test-run-dev: Disable Nagios check."
from a few weeks ago.
Tim Abbott
YJDave
Greg Price
Mukul Agrawal
Aditya Shridhar Hegde
Brock Whittaker
Privisus
Umair Khan
rht
Rishi Gupta
Robert Hönig
Vishnu Ks
Eeshan Garg