I'm not actually sure if this is possible; it's been copy/pasted from
the channel/topic code path, but even with that one, it seems like the
topic being `undefined` is impossible (that's not how operators work),
and the channel being undefined might be something that should fail in
`Filter` initialization, not here.
Adds server and web app support for processing the new `with`
search operator.
Fixes part of #21505.
Co-authored-by: roanster007 <rohan.gudimetla07@gmail.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
bulk fetch query of UserPfrofile against which
user_ids are validated, instead of looping
over user_ids and fetchingeach UserPfrofile resulting
in O(n) queries.
While using the pill in `stream_create`, it was noticed that deactivated
users were also part of the user_ids returned by the user_group_pill,
which we do not want to do.
This pill is used in two areas: compose box and stream create/edit.
This commit will only affect stream create/edit since compose box was
just using the typeahead data from user_group_pill and nothing else.
Stream and user pill handle inactive users already, so no change is
needed there.
Fixes#30690.
Before this, we were adding all users to subscriber list without adding
any pill. But, since we want pills to be the source of truth for adding
the subscribers, we will just add the `role:everyone` pill from now on
whenever `Add all users` is clicked.
While we can just directly call `pill_widget.appendValue` in
`stream_create_subscribers`, it's better to expose an API from
`add_subscribers_pill` and use that. This lets us control how appending
an item would work for subscriber pill in a single place.
We list all the members of a group including recursive subgroup members
in the user group popover.
We also add another change in this commit to show `Everyone` if the
group name is `role:everyone` by using
`user_groups.get_display_group_name`.
For system groups, the directive is that we should use the description
as the display name. But in case of `role:everyone`, the description is
`Admins, moderators, members and guests`, while for the
`user_group_pill`, we want to display a simpler and succinct message:
`Everyone`. We've only hardcoded this for user_group_pill since we don't
want to display the name as `Everyone` anywhere else yet.
We've also exposed a method called `get_display_group_name` which will
be used in later commits to get the group display name.
While the support to include all members of a subgroup is needed only in
the `stream_create` context for now, we have added the support for
subgroups to `user_group_pill` for all cases. We have done this because
that is still going to be the correct behaviour if we add similar
support to other pill inputs.
In terms of calculating and populating the recursive member list, it was
decided not to do it when initializing the user_groups data. One reason
for that was it would introduce a lot more complexity when adding or
removing members from any of the subgroups to keep the recursive member
list updated. Keeping in line with the general pattern of calculating
recursive subgroups on the fly too, it was decided to calculate the
recursive list of members on the fly too.
Also changes the `get_group_ids` tests to make sure that subgroup ids
are not part of the result of `get_group_ids`. Since it is used to
calculated taken_groups, we don't want to filter out subgroups as part
of taken_groups and their typeahead should still be visible.
This function goes through all subgroups recursively and returns the
resultant set of the members of those subgroups in addition to the
members of our target_group.
This function is required in order to add the `everyone` pill to create
channel flow.
For the tests written in this commit, it uses the same pattern as the
`get_recursive_subgroups` test.
`is_user_in_group` could have been technically refactored to use
`get_recursive_group_members`, but since the former returns early for
direct members, I've let it be for now.
Transforming valid stream/topic urls to the #**stream>topic**
syntax.
- A valid url contains a stream and optionally a topic
but nothing else, and in that order.
It must belong to the same origin as the Zulip server.
The stream id present in the pasted url should
correspond to an actual stream in the current
server.
- `near` links are not transformed.
- Use-mention distinction is respected by
not transforming a valid url if pasted using
`Ctrl+Shift+V`.
- No transformation occurs inside a code block.
- On pressing `Ctrl+Z` after pasting,
the actual pasted link is restored.
- No transformation occurs if the url is pasted over an
existing url in a markdown link syntax.
- No transformation occurs if the stream or topic name
contained in the pasted url is known to produce broken
stream/topic syntax links (as per #30071).
Fixes#29136
We use a truncated SHA256 of the id and a server-side secret to make
emoji have non-guessable filenames, while also making collisions
unlikely.
We also adjust the Slack import to use the same SHA-based name,
instead of taking the same name as it had in Slack.
We thumbnail and serve emoji with the same format as they were
uploaded. However, we preserved the original extension, which might
mismatch with the provided content-type.
Limit the content-type to a subset which is both (a) an image format
we can thumbnail, and (b) a media format which is widely-enough
supported that we are willing to provide it to all browsers. This
prevents uploading a `.tiff` emoji, for instance.
Based on this limited content-type, we then reverse to find the
reasonable extension to use when storing it. This is particularly
important because the local file storage uses the file extension to
choose what content-type to re-serve the emoji as.
This does nothing for existing emoji, which may have odd or missing
file extensions.
Anders Kaseorg
evykassirer
Vector73
Tim Abbott
Aman Agrawal
bedo
Alya Abbott
Shubham Padia
Kislay Verma
Lauryn Menard
adnan-td
Alex Vandiver
PieterCK