Our old optimizations to prevent re-rendering of locally echoed
messages created a lot of code complexity. This commit is an
experiment to simplify the code, which it clearly does. The
danger of re-rendering messages is flicker, but our message
view has changed since the original local echo code was written.
It's kind of confusing to have a filter function that has massive
side effects. Now we just have a simple loop where we triage
some messages into non_echo_messages and do an early-exit in the
loop function. This change also introduces the more explicit
variable name of `non_echo_messages`; before we were shadowing
`messages`.
This fixes the characters like “g” and “l” from overflowing the input
bounds while maintaining the previous height of the input box itself.
Fixes: #6665.
This removes the `box-sizing` attribute on the spectrum input that was
causing the characters to overflow the bounds of the padding, which
would cut off things like the bottom of a “g” or the top of an “f”.
Fixes: #6361.
It's unlikely to be of any real consequence, but this code bugged me
in that it makes a whole set before throwing it away to make nearly
the same set.
Sadly Python's comprehensions lack a way to write these cleanly as one
comprehension; but with no extra code complexity we can make the
temporary a genexp, which does the job.
We need a migration to clear the tutorial_status for existing users,
so that we don't show hotspots to anyone who signed up for Zulip in
the month or so since we deleted the old tutorial.
The `disable_existing_loggers` option to the `logging.config` module
turns on a rather complicated behavior of disabling some, but not all,
loggers that might have been already configured when the call to
`logging.config.dictConfig` or `logging.config.fileConfig` is made:
> This behaviour is to disable any existing loggers unless they or
> their ancestors are explicitly named in the logging configuration.
(https://docs.python.org/3/library/logging.config)
Turns out the only reason this is there is as a compatibility hack to
match the behavior of Python 2.4 and below. See the thread where the
new behavior was introduced: https://bugs.python.org/issue3136
Just as the author of the new behavior explains in that thread from
2008, the legacy behavior forces all logging configuration to be
awkwardly centralized in one place. That makes the code harder to
read, and it perennially causes confusion when a perfectly
normal-looking `logging.getLogger` call at the top level of one module
mysteriously has no effect, while that in another module works fine,
under the influence of the details of what gets imported when.
So, switch to the shiny new behavior of Python 2.5. Here LOGGING is a
Django setting which just becomes an argument to logging.config.dictConfig.
This may cause a few of the logfiles in ZULIP_PATHS to become active
that have been dormant for a long time.
This is a start and fixes the most glaring problems from not updating
this documentation; I'd like Harshit to do a helpful pass on updating
this to cover some of the more subtle details about how our emoji
picker works, emoji aliases, etc.
This fixes a bug where the internal_prep_message code path would
incorrectly ignore the `realm` that was passed into it. As a result,
attempts to send messages using the system bots with this code path
would crash.
As a sidenote, we really need to make our test system consistent with
production in terms of whether the user's realm is the same as the
system realm.
We don't access any attributes of the sender other than the realm, and
as it turns out, we in some cases want to use a different realm than
the sender's.
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.
Deployments whose name is not in the format of a timestamp are
always included in the `recent_deployments` and are not deleted,
hence we don't need to check for them explicitly.
We were checking for whether an item in the deployments directory
represents a directory but were using its relative path which was
causing a false value to be returned for all items irrespective of
their being a directory or not if the script was invoked from some
where other than the deployments directory.
The plan is to have everything expect subdomains, so it makes sense to
move these tests to the subdomains-only test class and style.
Most of the remaining GoogleLoginTest tests are now either duplicates
or basic API-level tests where subdomains are irrelevant.
Previously, this accessed realm.uri via trying to use
zulip_default_context. That doesn't make any sense, because
zulip_default_context expects an HttpRequest object, and those are
nowhere in sight in the code path. We do, however, have the outgoing
webhook bot user involved in the event, and that's the object to
access realm.uri from here.
This change means that almost every Zulip server out there will now be
using subdomains for every realm. There are a few complications noted
in the release notes.
These arguments are only intended to be used for realm creation, and
they make the code more confusing.
We need to make a few changes after doing this, because some tests
were relying on these extra arguments causing the form to not submit
for their error handling.
We don't apply these changes to the LDAP tests, since fixing those
seems complicated.
The pattern test method `test_rule_patterns` tests each rule by
fetching two strings from it: `test_good` and `test_bad`. Each
string is then presented as an input file to `custom_check_file`,
which should return True or False.
All lines in a string need to end with `\n`. Since the linter
expects an additional newline at the end of a file, the test case
adds `\n` to each string on top of that.
Fixes#6320.
Previously, if the operand was an invalid email, the site would
throw a scary-looking browser error. Now, it has the same behavior
as other search exeptions, and simply returns no messages found.