The `match_subject` field is supposed to contain HTML; that's how
the highlighting is done. But the `subject` field is plain text --
it must be encoded if we want corresponding HTML.
Of the three places the `match_subject` field is populated -- two
here in messages_in_narrow_backend, one in get_messages_backend --
two of them already do this correctly, via get_search_fields.
Fix the remaining one, where in a `/messages/matches_narrow` query
we populate `matches_subject` even if the query didn't involve a
full-text search.
This doesn't affect the webapp, which ignores `match_subject` unless
it knows it did a full-text search; nor the mobile app, which
doesn't use `/messages/matches_narrow` at all.
The boilerplate here is supposed to be example of how to apply the Apache
license to files in the project, and is not intended to be applied to the
LICENSE file itself. See https://github.com/benbalter/licensee/issues/103
for some discussion of this.
Moved the text from the LICENSE file to a NOTICE file, with one wording
change: "this file" -> "this project".
Previously we only added the active class to the Date uploaded
column, thinking it was already sorted by upload date by default.
However, it wasn't, so now we explicitly make a call to sort it by upload
date to fix an issue with broken sorting.
Fixes#10518.
I didn't remove zulip_version from context_processors since it seems likely
that we'll want to put that information somewhere on portico at some point.
Apparently, Travis removed the Heroku bundle of packages from their
servers, which made the build start failing when trying to configure
apt to hold their versions (sigh). This commit removes the
problematic packages.
I don't know how long this has been broken, but it seems
some re-design of our message feed moved the Subscribe
button out #zfilt, so we use a different parent selector
now to turn on the click handler.
Hopefully this was a pretty obscure bug. To reproduce
it go to "Manage Streams" and then select a stream you're
not subscribed to (from "All Streams"), and don't actually
subscribe, but then hit "View stream".
The user experience here is still a bit confusing, but
this is just a quick fix.
Surprisingly hard to find a good base example of a user doc. This one should
at least give the basic pointer to sidebar_index.md and where the new file
goes.
In particular, this improves:
* The explanation of how data is mapped into Zulip
* The explanation of what is printed out by `manage.py query_ldap`
* Makes sure users create their first account with EmailAuthBackend.
The term "username" confusingly refers both to the Django concept of
"username" (meaning "the name the user types into the login form") and
a concept the admin presumably already has in their existing
environment; which may or may not be the same thing, and in fact this
is where we document the admin's choice of whether and how they should
correspond. The Django concept in particular isn't obvious, and is
counterintuitive when it means something like an email address.
Explicitly explain the Django "username" concept, under the name of
"Zulip username" to take responsibility for our choice of how it's
exposed in the settings interface. Then use an explicit qualifier,
like "LDAP username", whenever referring to some other notion of
username. And make a pass over this whole side of the instructions,
in particular for consistent handling of these concepts.
Expand on a few things that tend to confuse people (especially the
`%(user)s` thing); move the `LDAPSearchUnion` example out to docs;
adjust the instructions to fit a bit better in their new docs/ home.
This makes it easier to iterate on these, and to expand supplemental
information (like troubleshooting, or unusual configurations) without
further straining the already-dauntingly-long settings.py.
It also makes it easier to consult the instructions while editing the
secrets file, or testing things, etc. -- most admins will find it more
natural to keep a browser open somewhere than a second terminal.
Previously, if someone updated his/her name from accounts page and closed
the modal and then reopen the modal, the page still had the old name as
we use `page_params.full_name` in `accounts-settings.handlebars`. This
commit fixes this bug.
Fixes: #10529.