Earlier, when `realm_mandatory_topics` setting was getting toggled,
the topic input box in composebox was not being live-updated to
align with the correspondning setting's UX.
This commit fixes that bug by making sure that placeholder and
other UI elements are updated accordingly.
This commit replaces direct `.css("visibility", "...")` calls
with `.addClass("visible")` and `.removeClass("visible")` to
manage the `$topic_not_mandatory_placeholder` visibility.
This improves maintainability by keeping styling in CSS.
This reverts commit 9243fa3d52.
This commit appears to have caused the same issue with the compose box
borders at other size/zoom configurations that may be more common.
We'll figure out a better fix and apply that.
Fixes#34010
From version 132, Firefox now defaults to not resize the viewport
content but only the visual viewport. While this works well in
Chrome Android, it creates a buggy experience in Firefox Android
where the compose box is hidden under keyboard.
To fix it, we rollback to resizing content when keyboard is shown
on Firefox Android.
Build warnings are unfortunately very common in third-party packages.
They’re difficult to reliably detect since packages don’t always build
from source, and they can’t be whitelisted on a per-package basis
since they’re all attributed to setuptools or an anonymous code
string.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Adds a help center article that provides an overview and guide
for moving from a self-hosted Zulip organization to using Zulip
Cloud.
Updates the bullet points with the advantages of Zulip Cloud
that is also used in the help center article about choosing
between Zulip Cloud and self-hosting.
Fixes#24042.
Server treats messages sent to "(no topic) or "general chat"
topic as being sent to empty string topic.
Messages sent in web client to "(no topic)" and "general chat"
were locally echoed to those respective topics, resulting in
being narrowed to those topics.
Ideally, the messages should be echoed in the empty string topic.
This commit fixes that bug.
This commit renames "(no topic)" to "" when used as
topic name, while sending or scheduling messages.
This is particularly helpful for older clients where
sending messages with empty topic input box resulted
in messages being sent to "(no topic)" topic.
Now, it will be sent in empty string topic and will
appear in the "general chat" topic.
This helps older clients to somewhat align with the UX
of the clients supporting empty string topic.
This commit adds migration to move messages from "(no topic)"
to the empty string topic.
It'll help in our plan to interpret messages sent to
"(no topic)" as being sent to "".
That interpretation will be particularly helpful for older
clients where sending messages with empty topic input box
currently results in messages being sent to "(no topic)" topic.
In 0680, we moved messages from the "general chat" topic
to the empty string topic. Therefore, we skip moving messages
from "(no topic)" if an empty string topic already exists.
Such cases—where both "(no topic)" and an empty string topic
coexist in a channel—should be rare. The solution is to either
manually rename the "(no topic)" topic or manually move its
messages to the empty string topic.
We introduced `is_channel_message` flag in 90d76b692b.
While populating messages in dev environment, we were not setting
it to False for DMs / group DMs.
This commit fixes that bug.
This commit makes the following changes to improve the display of long
stream titles in the stream creation and user group settings UI:
- Uses `display: -webkit-box` and `line-clamp` properties to show the
title upto two lines, and end with `...` if it exceeds.
- Updates icon `font-size` to align with text size.
- Updates `margin` and `line-height` to make it visually better.
This attempts to use a global copy event listener instead of
triggering the copy handler on Ctrl+C, as this is more robust way to
use browser APIs, including not intefering if end users choose to
remap copying keys on their keyboard.
This has various beneficial side effects, including copying from other
Markdown elements like the preview or drafts UI using the same code as
copying from the message feed.
Fixes: #33949.
We've for a while been finding that copy/paste of LaTeX only worked if
we had a more JS-heavy copy handler that directly copies the HTML/text
using events, rather than just allowing the browser's native copying
logic to do its thing.
We've discovered the bug was that the `<annotation>` tag in MathML is
not rendered in some browsers which results in default copy behavior
of the browser breaking KaTeX copy-pasting and quoting by omitting the
`<annotation>` in the copied HTML as Chrome and possibly other
browsers select only what is visible.
From https://www.w3.org/TR/selection-api/
> Chrome 16 dev behaves as you'd expect given its Selection
implementation. It refuses to select anything that's not visible, so
it's almost always wrong. Opera 11.50 just does nothing in all my
tests, as usual.
This can be observed in the `paste_html` fixtures present in
https://github.com/zulip/zulip/pull/33993#issuecomment-2725417637.
We fix this by simply overriding the `display:none` property from the
<annotation> tag in the user agent stylesheet, which lets the browser
select and ultimately copy it which results in the annotation being
present in the `paste_html` and restore the working of KaTeX
quoting/copy-pasting.
This appears to have no visible impact, since browsers don't actually
have a way to display the annotations.
Renames WHITELISTED_EMAIL_DOMAINS to OVERRIDE_ALLOW_EMAIL_DOMAINS
as the set of email domains that are allowed even if they are in
the set of disposable email domains.
These extended statistics allow the query planner to know that the
prevalence of empty topics is very different in DMs, as opposed to
channel messages. The `ALTER STATISTICS` adjusts the size of the
"most common value" list -- it must be large enough to include the
empty-topic channel messages to be fully effective. Having this list
be over-large does not carry much risk, however.
The `ANALYZE zerver_message` step may be quite slow.
On the event side, orjson does the work of converting
UserGroupMembersData to json. But when fetching intial state data,
UserGroupMembersData was being returned which is not
json-serializable. This was causing a mismatch in the `verify_action`
workflow of test_events related to stream group settings where
apply_events resulted in a state with `direct_members` and
`direct_subgroups` as part of an ordinary dict, while fetching initial
state data was giving us a UserGroupMembersData class.
This commit uses UserGroupMembersDict where appropriate. It will
still be good to keep around the dataclass class since it has the added
benefit of storing the relevant value when needed.
Since we set a new timeout on every connection error, we can
unconditionally clear the timeout when load_messages is called.
This fixes the error when `load_messages` is called irrespective
of `delay_secs` timer.
Since we were using the same click handler callback as the first
time banner was displayed, `attempt` was stuck at `1` when
the click callback is called.
Fixed by removing the old event handler and reattaching the new one.
Sometimes adding the loading indicator svg and making it spin were
happening in different rendering frames, making it look like the
loading spinner was stuck.
Fixed by making sure both happen in the same animation frame.
If users are only allowed to view move history, the header
is 'Message move history.' If users are allowed to view edit
and move history and the message is edited and moved, the header
is 'Message edit and move history.' Otherwise, it shows 'Message
edit history.' If the message is only moved (and not edited), it
shows 'Message move history.'
Fixes#34005.
Earlier, with `realm_mandatory_topics=true` the topic required
error message was shown only when topic="".
The error message was missing for other topic names which are
also considered empty:
* "(no topic)"
* realm_empty_topic_display_name
This commit fixes the bug to show the error message for the
other two topic names too.
Earlier, the `is_topic_name_considered_empty` function
used to return true only if the topic_name is either:
* ""
* "(no topic)"
* `realm_empty_topic_display_name` value
The third condition is not precisely correct. This commit
replaces it with the displayed topic name for `""` topic.
The displayed topic name is not always the same as
`realm_empty_topic_display_name` value.
We set it to True when fetching streams in `fetch_initial_state_data`
and when trying to find newly accessible or inaccesible streams on role
update. We've added tests for role update, but since we don't test
`fetch_initial_state_data` directly, the role update tests changed in
this commit will fail if include_all is not set to True in
`fetch_inital_state_data`.
All those if conditions and different number of events for each
condition was making the current test function unreadable. This commit
hopes to simplify that. All the setup work for the tests is still done
in the respective test functions and not `do_test_change_role`.
Indexes on topic ("subject") are polluted by the existence of DMs,
which all have empty topics, and as such skew the statistics greatly.
This is particularly important given the new use of the empty topic
for the "general chat" function -- left as-is, the database makes bad
query plans because it believes the topic is vastly more common than
it actually is.
We move the old indexes to a new name with `_all`, and
recreate (concurrently) the same indexes but with a condition on
is_channel_message. These new indexes are unused at current, until
the query-building logic adds limits on is_channel_message; see the
following commit.
