The new `#groups` overlay had no way for user groups to be deleted.
This commit adds UI support for removing user groups along with
adding support for live update of `#groups` overlay on remove
event for user groups.
We add live update support for user group events as part of
https://github.com/zulip/zulip/issues/19526.
This however has a few TODOs:
1. Deciding on how we want to sort the group list on left of
#groups overlay.
2. How we highlight the newly created groups after it is added
to the list.
These will be covered as we add support for more groups events.
Since we do not currently have live update on newly
created ui for user group management, alert shown
after successful creation of user group apeared across
full width of right panel of #groups overlay. Which
made it look a bit awkward, so we add margins to that
alert info.
This removes the focus outline on `simplebar-content-wrapper` in
the left sidebar and other places in the app when focused since
it doesn't look visually nice.
This commit fixes the code which incorrectly set the cursor
property to "pointer" for input and textarea elements where
only select elements should have it. The code causing this bug
was added in d708bc338.
In Zulip, message topics are case-insensitive but case-preserving.
The `get_context_for_message` function erroneously did a
case-sensitive search, and thus only messages whose topic matched
exactly were pulled in as context.
Make the missed-message pipeline aware that message topics are not
case-sensitive. This means that, when collapsing adjacent messages,
we merge messages with topic headers which are "different"; create a
separate explicit "grouping" to know which to collapse.
Similar to the previous commit, Django was responsible for setting the
Content-Disposition based on the filename, whereas the Content-Type
was set by nginx based on the filename. This difference is not
exploitable, as even if they somehow disagreed with Django's expected
Content-Type, nginx will only ever respond with Content-Types found in
`uploads.types` -- none of which are unsafe for user-supplied content.
However, for consistency, have Django provide both Content-Type and
Content-Disposition headers.
The Content-Type of user-provided uploads was provided by the browser
at initial upload time, and stored in S3; however, 04cf68b45e
switched to determining the Content-Disposition merely from the
filename. This makes uploads vulnerable to a stored XSS, wherein a
file uploaded with a content-type of `text/html` and an extension of
`.png` would be served to browsers as `Content-Disposition: inline`,
which is unsafe.
The `Content-Security-Policy` headers in the previous commit mitigate
this, but only for browsers which support them.
Revert parts of 04cf68b45e, specifically by allowing S3 to provide
the Content-Disposition header, and using the
`ResponseContentDisposition` argument when necessary to override it to
`attachment`. Because we expect S3 responses to vary based on this
argument, we include it in the cache key; since the query parameter
has dashes in it, we can't use use the helper `$arg_` variables, and
must parse it from the query parameters manually.
Adding the disposition may decrease the cache hit rate somewhat, but
downloads are infrequent enough that it is unlikely to have a
noticeable effect. We take care to not adjust the cache key for
requests which do not specify the disposition.
This was missed in 04cf68b45ebb5c03247a0d6453e35ffc175d55da; as this
content is fundamentally untrusted, it must be served with
`Content-Security-Policy` headers in order to be safe. These headers
were not provided previously for S3 content because it was served from
the S3 domain.
This mitigates content served from Zulip which could be a stored XSS,
but only in browsers which support Content-Security-Policy headers;
see subsequent commit for the complete solution.
In nginx, `location` blocks operate on the _decoded_ URI[^1]:
> The matching is performed against a normalized URI, after decoding
> the text encoded in the “%XX” form
This means that if a user-uploaded file contains characters that are
not URI-safe, the browser encodes them in UTF-8 and then URI-encodes
them -- and nginx decodes them and reassembles the original character
before running the `location ~ ^/...` match. This means that the `$2`
_is not URI-encoded_ and _may contain non-ASCII characters.
When `proxy_pass` is passed a value containing one or more variables,
it does no encoding on that expanded value, assuming that the bytes
are exactly as they should be passed to the upstream. This means that
directly calling `proxy_pass https://$1/$2` would result in sending
high-bit characters to the S3 upstream, which would rightly balk.
However, a longstanding bug in nginx's `set` directive[^2] means that
the following line:
```nginx
set $download_url https://$1/$2;
```
...results in nginx accidentally URI-encoding $1 and $2 when they are
inserted, resulting in a `$download_url` which is suitable to pass to
`proxy_pass`. This bug is only present with numeric capture
variables, not named captures; this is particularly relevant because
numeric captures are easily overridden by additional regexes
elsewhere, as subsequent commits will add.
Fixing this is complicated; nginx does not supply any way to escape
values[^3], besides a third-party module[^4] which is an undue
complication to begin using. The only variable which nginx exposes
which is _not_ un-escaped already is `$request_uri`, which contains
the very original URL sent by the browser -- and thus can't respect
any work done in Django to generate the `X-Accel-Redirect` (e.g., for
`/user_uploads/temporary/` URLs). We also cannot pass these URLs to
nginx via query-parameters, since `$arg_foo` values are not
URI-decoded by nginx, there is no function to do so[^3], and the
values must be URI-encoded because they themselves are URLs with query
parameters.
Extra-URI-encode the path that we pass to the `X-Accel-Redirect`
location, for S3 redirects. We rely on the `location` block
un-escaping that layer, leaving `$s3_hostname` and `$s3_path` as they
were intended in Django.
This works around the nginx bug, with no behaviour change.
[^1]: http://nginx.org/en/docs/http/ngx_http_core_module.html#location
[^2]: https://trac.nginx.org/nginx/ticket/348
[^3]: https://trac.nginx.org/nginx/ticket/52
[^4]: https://github.com/openresty/set-misc-nginx-module#set_escape_uri
This commit fixes the issue where the "Click to view or download" comes
to the right of the image title. We add a parent division in this commit
that leads to the break tag being applied successfully, shifting the
secondary tooltip content ("Click to view or download") to next line.
Some non-English characters overflow when the line height is reduced
for the tooltip text. This commit increases the line height of the
tooltips to accommodate these non-English characters and fixes the
hotkey hint margins for the same.
This commit enables the stylistic set "ss01" in Source Sans 3
font family which contains stylistic variant of the upper-case
character "I", which contains two bars, one each on the top and
bottom of the letter. This provides a uniform look across all
the characters when used in the hotkey hints of the tooltips.
The second line of a multi-line tooltip generally desctribes the
additional information which helps the major text, i.e. the first
line of the multi-line tooltip, hence it would be a good idea to
add italics styling, to differentiate it from the main title. We
describe a simple ".italic" class for the same.
We also add a shorter line height to this description using the
".tooltip-inner-content" class.
We scan a tooltip for any required windows-to-mac hotkey conversions
from the list of attributes supplied to the hotkey_hints helper.
If we find any, we add/modify the hotkyes in the hotkey hints list to
match the mac-style key combinations and then return back the modified
list of hotkey hints to be displayed in the tooltip.
We also rename the "adjust_mac_shortcuts" function, used for the
keyboard shortcuts menu and help center documnets, to
"adjust_mac_kbd_tags" to avoid any ambiguity with the
adjust_mac_tooltip_keys funtion which is used for tooltip hotkeys.
We add the support for hotkey hints for the tippyjs tooltips through
the hotkey_hints handlebar helper.
The hotkey_hints helper takes space seperated string arguments and
returns a span containing all the hotkeys with the required classes
for styling.
We also add a simple node test for the hotkey_hints handlebar helper.
Part of #21753
We use hsla(0, 0%, 20%, 1) for the light theme background color and
hsla(0, 0%, 0%, 1) for the dark theme. The text inside the tooltips
should be white in color, 14px in size and have a line height of 15px.
With one line of text, we want the height of the tooltips to be 25px,
i.e, line height (15px) + padding (5px + 5px = 10px).
Part of #21753
We will hopefully be able to just this in #16208 to document what
users need to configure in order to do this manually, but the content
here will be useful for anyone who hasn't set that up regardless.
Fixes the documentation generated from the Markdown macros
{settings_tab|your-bots} and {settings_tab|bot-list-admin} to
match the text labels in the Zulip UI and improves the text of
relative links to explicitly say if we are referring to the Bots
tab of the Personal or Organization settings menu.
Follow-up to #23256.
This code needs to be more flexible to improve the documentation
of items in the Personal and Organization settings menu when
using the `{settings_tab|[setting-name]}` Markdownm macro that
provides relative links or step-by-step instructions.
This commit moves the Markdown formatting code to a new function that
receives tuples from `link_mapping` as input. This is a preliminary
step to offer more flexibility than the current approach.
Instead of using localstorage to set the filters every time we
render recent topics, we only do it during initial page load and
then use the locally present `filters` variable to set the
filters.
This avoids multiple Zulip tabs of having a live impact on the
filters used in recent conversations.
Rename 'muting.py' to 'user_mutes.py' because it, now
, contains only user-mute related functions.
Includes minor refactoring needed after renaming the file.
This commit moves topic related stuff i.e. topic muting functions
to a separate file 'views/user_topics.py'.
'views/muting.py' contains functions related to user-mutes only.
This is necessary to offer the "Unsubscribe" button in full user
profiles when the current user has the necessary permissions for a
given stream.
We remove settings_data.user_can_unsubscribe_other_users, since we've
changed its only caller and it is no longer a useful abstraction.
This commit adds dropdown-list-widget element in create stream UI
to set can_remove_subscribers_group setting when creating stream.
For now only role-based system groups are shown as options.
This commit adds dropdown-list-widget element in "General" section of
stream settings for can-remove-subscribers-group setting. For now we
only show role-based system groups as the options.
This commit adds get_realm_user_groups_for_dropdown_list_widget function
which returns the list of objects containing the display name and id
of system user groups and adds tests for this function.
This commit updates the frontend to show or hide the "Unsubscribe"
button in subscribers list in stream settings as per the
can_remove_subscribers_group setting for the stream.
Previously, subscription rows with a remove-subscription-button were
much taller than those without. This will be problematic when the new
permissions setting makes it possible for the current user to have
permission to unsubscribe the target user from some streams but not
others.
Fix this by both making the button a bit less tall and setting a
minimum height for the rows. Probably a nicer CSS solution is
possible, but this is enough to unblock merging a much larger project.
m-e-l-u-h-a-n
Aman Agrawal
Sahil Batra
Alex Vandiver
sayamsamal
evykassirer
Mateusz Mandera
Alya Abbott
David Rosa
Ujjawal Modi
Prakhar Pratyush
Kartik Srivastava
Tim Abbott