This was confusingly doing an assertion about the subscription being
active, not the channel. We could rename it to
require_active_subscription. But it was only passed with a non-default
value in b2cb443d24, and that call was
removed in 378062cc83.
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.
Fixes#33567.
We have used the flag `is_modifying_message` since it's more generic
than an archived channel specific flag and helps us understand better
what is the condition where we do not want to allow archived channels.
We have not added tests for message edit since it has an existing test
for this.
This commit implements the backend of migrating the
`allow_edit_history` setting to
`message_edit_history_visibility_policy`.
This allows organizations, to have an intermediate setting to
view only the "Moves" history of the messages.
We still pass `realm_allow_edit_history` in `/register` response
though for older clients with its value being set depending on the
value of `realm_message_edit_history_visibility_policy`. We set
`realm_allow_edit_history` to `False` if the
`realm_message_edit_history_visibility_policy` is "None", and
`True` for "Moves only" or "All" message edit history.
Fixes part of #21398.
Co-authored-by: Shlok Patel <shlokcpatel2001@gmail.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Previously when system bots used to `#-mention` a private
channel's topics in cases like moving messages of a private
channel, then the #-mentions were not rendered by the
markdown. This was because the system bots did not have
authorization to mention these channels.
This is fixed by passing down an `acting_user` parameter
in code paths involving sending these move message
notifications so that permission of acting_user to mention
the topic is verified for rendering the markdown, rather
than that of the system bot.
This commit fixes a bug introduced in commit `37f2c5bc788`,
where a message in DM is not updated to "(deleted)" when
left empty after editing.
Fixes: #33305
This commit updates the 'get_mentions_for_message_updates' function to
use the generic 'event_recipient_ids_for_action_on_messages' function
to determine users having access to the message and perform an
intersection with the mentioned users to filter out the users who
no longer can access the message.
It helps to add hardening such that if the invariant "no usermessage
row corresponding to a message exists if the user loses access to the
message" is violated due to some bug, it has minimal user impact.
This commit updates the 'do_update_embedded_data' function to use
the generic 'event_recipient_ids_for_action_on_messages' function
while deciding the event's recipients.
It helps to add hardening such that if the invariant "no usermessage
row corresponding to a message exists if the user loses access to the
message" is violated due to some bug, it has minimal user impact.
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>
stream_topic variable is needed only when updating content
so we set the field inside is_content_edited block.
Also added a comment clarifying about why we use orig_stream
for stream ID.
We already have realm_id from message object passed to
do_update_message so there is no need to pass "None" to
update_message_cache for direct messages.
Previously, if "None" was passed to update_message_cache,
realm_id was eventually computed from stream if it was
a stream message and from Message object for direct messages.
But we always passed a value which is not "None" for stream
messages, and we can be sure that the message.realm will
always be the realm in which stream is present to which the
message was sent.
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.
Now, message edit operation supports empty topic name.
Adds backward compatibility for:
- `topic` field in the `delete_message` event type
- `orig_subject` and `subject` fields in the `update_message`
event type
Earlier, we were using 'queue_json_publish' in 'check_message_update'
which can lead to a situation where we enqueue event but the
transaction fails at a later stage.
Events should not be sent until we know we're not rolling back.
Update the active status of new stream where the messages are moved
into, if appropriate.
Tested by deleting all messages in a stream. Running the command
to update stream status to mark it inactive. Then moving messages
into the stream to check if the status is updated correctly to active.
Currently, we want to ask users if they would like to delete their
attachments after they have removed the attachments while editing. These
changes are preparatory changes on the backend to return a list of removed
attachments after the user has removed attachments while editing.
Fixes part of #25525.
This commit removes the 'prev_rendered_content_version'
field from:
* the 'edit_history' object within message objects in the
API response of `GET /messages`, `GET /messages/{message_id}`
and `POST /zulip-outgoing-webhook`.
* the 'update_message' event type
as it is an internal server implementation detail not used
by any client.
Note: The field is still stored in the 'edit_history' column
of the 'Message' table as it will be helpful when making
major changes to the markup rendering process.
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.
This commit updates the code so that only the moved notification is
triggered when moving a message between a resolved and unresolved
topic in different streams or when moving a topic itself.
This change takes place even when both stream change and resolve
or unresolve a topic takes place in the same API request, as we
now consider it only a move operation.
This fixes a case where a message is moved between topics that
have the same name, but one resolved and another unresolved and
in different streams. Previously a resolved or unresolved
notification would also be sent. Now, this will not happen,
ensuring only the move operation is notified.
Fixes part of #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.
Earlier, we were using 'send_event' 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.
Updates various areas of the backend code that generate
JsonableErrors with translated strings to use channel
instead of stream.
Part of stream to channel rename project.
A user who was no longer subscribed to a private stream kept their
UserMessage row for a message sent while they were in it; this is
expected. However, they _also_ kept that row even if the message was
moved to a different private stream that they were also not subscribed
to. This violates the invariant that users without subscriptions
never have UserMessage rows.
This `if new_stream is not None` block was improperly indented,
causing it to only run if the propagation mode was not `change_one`.
Since the block controlled creation and deletion of UserMessage rows,
this led to messages being improperly still visible to members of the
old stream if they were being moved from public to private streams.
Clients also failed to receive `delete_message` events, so the
messages remained visible in their feeds until they reloaded the
application.
Rather than pass around a list of message objects in-memory, we
instead keep the same constructed QuerySet which includes the later
propagated messages (if any), and use that same query to pick out
affected Attachment objects, rather than limiting to the set of ids.
This is not necessarily a win -- the list of message-ids *may* be very
long, and thus the query may be more concise, easier to send to
PostgreSQL, and faster for PostgreSQL to parse. However, the list of
ids is almost certainly better-indexed.
After processing the move, the QuerySet must be re-defined as a search
of ids (and possibly a very long list of such), since there is no
other way which is guaranteed to correctly single out the moved
messages. At this point, it is mostly equivalent to the list of
Message objects, and certainly takes no less memory.
This applies access restrictions in SQL, so that individual messages
do not need to be walked one-by-one. It only functions for stream
messages.
Use of this method significantly speeds up checks if we moved "all
visible messages" in a topic, since we no longer need to walk every
remaining message in the old topic to determine that at least one was
visible to the user. Similarly, it significantly speeds up merging
into existing topics, since it no longer must walk every message in
the new topic to determine if the user could see at least one.
Finally, it unlocks the ability to bulk-update only messages the user
has access to, in a single query (see subsequent commit).
