The original behavior of this setting was to disable LDAP
authentication for any realms not configured to use it. This was an
arbitrary choice, and its only value was to potentially help catch
typos for users who are lazy about testing their configuration.
Since it makes it a very inconvenient to potentially host multiple
organizations with different LDAP configurations, remove that
behavior.
This commit adds a new option 'DMs, mentions, and followed topics'
to 'desktop_icon_count_display' setting.
The total unread count of DMs, mentions, and followed topics appears
in desktop sidebar and browser tab when this option is configured.
Some existing options are relabeled and renumbered. We finally have:
* All unread messages
* DMs, mentions, and followed topics
* DMs and mentions
* None
Fixes#27503.
While the server implementation has accepted this value for a few
months as part of building the feature, following topics was not a
fully supported feature of the Zulip server before
3f2ab44f94, just before feature
level 219.
So that's probably the correct level to document as the first feature
level at which we recommend that clients supporting the followed
topics feature process the value.
These new models are incomplete and totally untested, but merging this
will provide valuable scaffolding for doing smaller PRs working on
individual gaps, and reveals a clear set of TODOs/refactoring/model
changes needed to support where want to end up.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Earlier, the send button's state was determined independently by the
message length and the upload status, and its containing `div`'s state
was separately determined on recipient change by whether the user had
permission to post in that stream, or if direct messages were allowed
in the organisation. The main problem was that as the message length
check was run on each character input, it often overrode the upload
status check.
Now for consistency, the code has been refactored to always disable the
send button by accordingly styling its containing `div`; and using the
observer pattern we update it anytime the message length, upload status,
or the recipient changes, considering **all** of them together.
(The Save button when editing a message still works like before -- only
dependent on upload status.)
Fixes: #21135.
Due to the way turndown pads every block element with 2 new lines, and
makes `br` double space by default, we would get 3 blank lines pasted
when there's just 1 line break between 2 paragraphs.
Now we set `br` to an empty string, and since turndown collapses
sequences of multiple new lines to `\n\n` (1 blank line), so any 2 block
elements will now always have 1 blank line between them, irrespective of
if and how many line breaks there are between them in the copied HTML.
These were written before the draft endpoints were converted to use
@typed_endpoint and pydantic-based DraftData(BaseModel) for param
validation. Update them to avoid the confusion of talking about dicts
and dict_validator functions when those are no longer a thing.
This reverts commit 091e2f177b.
This version of python_to_js_linkifier fails for at least some real
linkifiers. We'll likely re-introduce this after a bit more debugging.
Due to a bug[^1] in Django 4.2, fixed in 4.2.6, queries using
`__isnull` added an unnecessary cast. This cast was _also_ used in
`WHERE` clauses for partial indexes. This means that partial indexes
created before Zulip was using Django 4.2 (i.e. before Zulip Server
7.0 or 2c20028aa4) will not be used when the server is using Django
4.2.0 through 4.2.5 -- and, conversely, that indexes created while
Zulip had those versions of Django (i.e. Zulip Server 7.0 through 7.4
or 7807bff526) will not be used later.
We re-create the indexes, to ensure that users that installed Zulip
after Zulip Server 7.0 / 2c20028aa4 and before Zulip Server 7.5 /
7807bff526 have indexes which can be used by current Django. This
is useless work for some installations, but most analytics tables are
not large enough for this to take significant time.
[^1]: https://code.djangoproject.com/ticket/34840
This makes it possible to send notifications to more than one app ID
from the same server: for example, the main Zulip mobile app and the
new Flutter-based app, which has a separate app ID for use through its
beta period so that it can be installed alongside the existing app.
This commit adds code to send stream deletion events when
unsubscribing non-admin users from private streams and
when unsubscribing guests from public streams since
non-admins cannot access unsubscribed private streams
and guests cannot access unsubscribed public streams.
It was discovered by the Zulip development team that active users who
had previously been subscribed to a stream incorrectly continued being
able to use the Zulip API to access metadata for that stream. As a
result, users who had been removed from a stream, but still had an
account in the organization, could still view metadata for that
stream (including the stream name, description, settings, and an email
address used to send emails into the stream via the incoming email
integration). This potentially allowed users to see changes to a
stream’s metadata after they had lost access to the stream.
This bug was present in all Zulip releases prior to today's Zulip
Server 7.5.
This commit adds new API endpoint to get stream email which is
used by the web-app as well to get the email when a user tries
to open the stream email modal.
The stream email is returned only to the users who have access
to it. Specifically for private streams only subscribed users
have access to its email. And for public streams, all non-guest
users and only subscribed guests have access to its email.
All users can access email of web-public streams.
This commit removes "email_address" field from Subscription objects
and we would instead a new endpoint in next commit to get email
address for stream with proper access check.
This change also fixes the bug where we would include email address
for the unsubscribed private stream as well when user did not have
permission to send message to the stream, and having email allowed
the unsubscribed user to send message to the stream.
Note that the unsubscribed user can still send message to the stream
if the user had noted down the email before being unsubscribed
and the stream token is not changed after unsubscribing the user.
Documents new wildcard mention for topic participants updating
and making tweaks to all relevant pages.
Fixes#27657.
Co-authored-by: Alya Abbott <alya@zulip.com>
This commit moves the main context creation part of the
'billing_home` view to a new shared
'BillingSession.get_billing_page_context' method.
This refactoring will help in minimizing duplicate code
while supporting both realm and remote_server customers.
The word "Filtrar" is ambiguous in this context since it can be
interpreted as "filter out" which is the opposite of what we want
here. "Buscar solo" is a better phrase that we can use unambiguously
and consistently for all instances of "Narrow to".
This should now happen at the same time it did prior to this change,
without requiring the show_all_message_view wrapper to have any
business logic.
This fixes a potential scroll position bug in the event that
narrow.deactivate in fact calls itself recursively after a timeout.
We already do a very parallel construction in narrow.activate, so this
moves us towards being able to unify those code paths, while also just
being more readable by avoiding a small-but-important wrapper function
in hashchange.js.
I believe this fixes a bug where we were not saving scroll position in
browser history when navigating to "All messages" from another view.
Since at least 6ef0753a51, it's been the
case that narrow.activate already hides the inbox/recent views if
open, and the same is true for all messages.
Fixing the duplicate call is important in show_home_view, because
show_all_message_view relies on having an accurate value for whether the
recent/inbox views were already open in order to correctly update the
left sidebar.
Testing experimentally, removing the setTimeout seems to fix a visible
flicker when using Esc to navigate to "All messages" from the Inbox
view. That setTimeout has been moved around without real examination
since 5d79bb6a20 from early 2013; I
don't see any good reason why it would make be necessary only in the
"All messages" code path, and not when narrowing to any other view.
Karl Stolley
aryan
Mateusz Mandera
Prakhar Pratyush
Tim Abbott
Lauryn Menard
Alya Abbott
Vector73
N-Shar-ma
David
Anders Kaseorg
Alex Vandiver
Greg Price
Sahil Batra