Streams should not be marked as private, and subscribers
of the deactivated stream should not be removed.
Update the confirmation message when archiving a stream.
When clicking on a message from an archived
stream, the `adjusted_terms` may be null since
archived streams are not sent back to the client.
This results in an error for the user.
Function `delete_sub` was exclusively called by `stream_data.delete_sub`.
With the change in the approach where we no longer remove subscriptions
from `stream_info` and `subs_by_stream_id`, the `delete_sub` function is no
longer needed.
Previously, when archiving a stream `delete` function was used to
remove stream from `stream_info`. However, with the current
approach, we don't remove stream instead we use the `set_false`
function to mark streams as false, making the `delete`
function unnecessary.
Stream is simply marked as `archived: true` instead of removing
the stream from `sub_store` and `stream_info`.
A check in `subscribe_myself` is added before subscribing to a
stream.
`is_archived` field is added to the stream and types.
Include a new `archived_channeels` client capability, to allow clients
to access data on archived channels, without breaking
backwards-compatibility for existing clients that don't know how to
handle these.
Also, included `exclude_archived` parameter to `/get-streams`,
which defaults to `true` as basic clients may not be interested
in archived streams.
As several archived streams may have the same new name,
it is essential to verify whether any stream, regardless
of its current status (active or archived), already has that name
before executing any renaming operation.
Earlier, in left stream sidebar, new topic button was shown for all
stream rows irrespective of compose permission of the user for
individual streams.
This commit changes the behaviour by hiding the new topic button if
user doesn't have appropriate compose permission for individual
streams.
Fixes: zulip#31800.
Previously, the hashing logic for static avatar files hashed the default
and medium files separately, which didn’t match how user-uploaded
avatars work—where you just add the "-medium.png" suffix to get the
medium version. Since we don’t have clear documentation for avatars yet,
this caused some issues for the mobile apps.
This commit makes sure the default and its medium variation share the
same hash.
On the frontend, the selection is still a dropdown of system groups but
on the API level, we have started accepting anonymous groups similar to
other settings
We've kept require system groups true for now until we switch to group
picker on the frontend.
On the frontend, the selection is still a dropdown of system groups but
on the API level, we have started accepting anonymous groups similar to
other settings.
We've kept require system groups true for now until we switch to group
picker on the frontend.
Updates the main query and logic for building the remote activity
table to use remote server mobile user/push data for server rows
and remote realm mobile user/push data for realm rows.
With the introduction of `assignee_updated` parameter in the library,
- Github, Gitea, Gogs can display the assignee in assignment events.
- Github can display the user unassigned in unassignment events.
Fixes https://chat.zulip.org/#narrow/channel/127-integrations/near/1965136
If we paste a stream-topic URL that can be formatted as per #29302,
we now generate a normal markdown link if the stream topic syntax
could result in a broken link.
Fixes#31904
We didn't have thumbnailing for images coming from data import and this
commit adds the functionality.
There are a few fundamental issues that the implementation needs to
solve.
1. The images come from an untrusted source and therefore we don't want
to just pass them through to thumbnailing without checking. For that
reason, we cannot just import ImageAttachment rows from the export
data, even for zulip=>zulip imports.
The right way to process images is to pass them to maybe_thumbail(),
which runs libvips_check_image() on them to verify we're okay with
thumbnailing, creates ImageAttachment rows for them and sends them
to the thumbnailing queue worker. This approach lets us handle both
zulip=>zulip and 3rd party=>zulip imports in the same way,
2. There is a somewhat circular dependency between the Message,
Attachment and ImageAttachment import process:
- ImageAttachments would ideally be created after importing
Attachments, but they need to already exist at the time of Message
import. Otherwise, the markdown processor doesn't know it has to add
HTML for image previews to messages that reference images. This would
mean that messages imported from 3rd party tools don't get image
previews.
- Attachments only get created after Message import however, due to the
many-to-many relationship between Message and Attachment.
This is solved by fixing up some data of Attachments pre-emptively, such
as the path_ids. This gives us the necessary information for creating
ImageAttachments before importing Messages.
While we generate ImageAttachment rows synchronously, the actual
thumbnailing job is sent to the queue worker. Theoretically, the worker
could be very backlogged and not process the thumbnails anytime soon.
This is fine - if the app is loaded and tries to display a message with
such a not-yet-generated thumbnail, the code in `serve_file` will
generate the thumbnails synchronously on the fly and the user will see
the image preview displayed normally. See:
1b47134d0d/zerver/views/upload.py (L333-L342)
Alya Abbott
Aman Agrawal
sanchi-t
Karl Stolley
Pratik Chanda
Tim Abbott
PieterCK
Sahil Batra
Shubham Padia
Mateusz Mandera
Lauryn Menard
Niloth P
Kislay Udbhav Verma