For get and filter queries of NamedUserGroup, realm_for_sharding
field is used instead of realm field, as directly using
realm_for_sharding field on NamedUserGroup makes the query faster
than using realm present on the base UserGroup table.
Previously, when there were two topics -- A and B, and a user
follows topic A, then when messages of topic B are merged into
topic A then topic A loses its follow status.
This is fixed by updating the algorithm for getting the visibility
policy after merge to be followed in the above case.
Fixes#35226
This commit updates code to use "\x07" as value for
"subject" field of Message objects for DMs and group
DMs, so that we have a unique value for DMs and group
DMs which cannot be used for channel messages.
This helps in avoiding having an empty string value as
topic for DMs, which is also used for "general chat"
channel messages, as large number of DMs in the realm
resulted in PostgreSQL query planner thinking that there
are too many "general chat" messages and thus generated
bad query plans for operations like fetching
"general chat" messages in a stream or moving messages
to and from "general chat" topic.
This change as done for ArchivedMessage and
ScheduledMessage objects as well.
Note that the clients still get "subject" value as
an empty string "".
This commit also adds tests for checking that "\x07"
cannot be used as topic for channel messages.
Fixes#34360.
This commit adds a new personal setting
`resolved_topic_notice_auto_read_policy` which controls how
resolved-topic notices are marked as read for a user.
Fixes#33599.
This commit adds two functions in `zerver/lib/test_classes.py`. The
first function returns the `user_ids` of users for whom the message
is marked as unread. The second function returns the `user_ids` of
users for whom the message is marked read, based on the `message_id`.
This commit separates the "resolve topic" permissions from the
topic editing permissions, through the introduction of setting -
"can_resolve_topics_group" which user group whose members
can resolve topics.
Fixes#21811
This will allow clients to display MOVED/EDITED indicators, and their
tooltips, without interacting with the `edit_history` section of
message objects, which we plan to remove in the future.
Supporting that requires both introducing both last_moved_timestamp,
and changing the definition of last_edit_timestamp to not include
message moves, which involves recalculating it at the API layer.
The last_moved_timestamp is not present if the topic moves for the
message are for resolving or unresolving the topic. It is always
present for channel moves.
Co-authored-by: Lauryn Menard <lauryn@zulip.com>
Fixes#33719
If the user is not subscribed to the new stream but is a subsriber
of the old stream, we were not sending any update events to the user.
This results in unexpected behaviour related to the message.
Previously, 'check_update_message' allowed moving messages to
empty topic even with `mandatory_topic=true`.
This commit fixes the bug. We now raise an error in that case.
Co-authored-by: Prakhar Pratyush <prakhar@zulip.com>
This commit makes changes to the edit message endpoint
to disallow resolving empty string topic.
It also removes the resolve topic button in the web client
from topic popover and message header for empty string topic.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds a `empty_topic_name` client capability to allow client
to specify whether it supports empty string as a topic name.
Adds backward compatibility for:
- `subject` field in the `message` event type
This commit fixes the bug where the "topic unresolved" notification
is wrongly triggered when moving a message between a resolved and
unresolved topic, except for when the topics have the same name.
To resolve this issue, the commit ensures that resolved/unresolved
notifications are not sent if a message has been moved to a new
topic. This is achieved by comparing the names of the old and new
topics without considering the "resolved prefix".
The commit also accounts for the scenario where `new_topic_name`
has been truncated, indicating that it was resolved and the name
had to change to accommodate the "resolved prefix".
This solution does not try to specially handle the possible case that
a stream has two topics with the same name, even if one is resolved
and another unresolved.
Fixes#29007.
Currently we send a notification to the topic if it has been resolved
or unresolved even if there is an immediate event of resolving and
then unresolving or vice-versa. This adds a setting of
RESOLVE_TOPIC_UNDO_GRACE_PERIOD_SECONDS under which if a topic has
been unresolved after being resolved immediately and the last message
was the notification of resolving, then delete the last message and
don't send a new notification and vice-versa.
We use the new message.type field to precisely identify relevant
messages.
Fixes#19181.
Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
Earlier, we were using 'send_event' in 'do_update_message'
which can lead to a situation where we enqueue events but
the transaction fails at a later stage.
Events should not be sent until we know we're not rolling back.
This commit updates code, majorly in tests, to use
setting values from enums instead of directly using
the constants defined in Realm.
We still have those constants defined Realm as they
are used in a couple of places where the same code
is used for different settings. These will be
handled later.
Earlier, we were using 'send_event' & 'queue_json_publish' in
'do_send_messages' which can lead to a situation where we enqueue
events but the transaction fails at a later stage.
Events should not be sent until we know we're not rolling back.
For the common case of not needing to reference the UserMessage row
later, and for being a stream without private history, the UserMessage
row is irrelevant. Convert `has_user_message` to a thunk, and defer
loading it unless necessary.
