We always use delivery_email to generate gravatar_url, but in
test_admin_api_hide_emails we were passing email to get_gravatar_url
and matched with the avatar_url field of the fetched user object.
The tests were passing because the email_address_is_realm_public
was using old realm object and thus email field was incorrectly
set to delivery_email even when email_address_visibility was set
to EMAIL_ADDRESS_VISIBILITY_ADMINS.
This commit fixes the test to pass delivery_email to get_gravatar_url.
We create RealmUserDefault object for internal realm just
for consistency. The code in migration does so but it
was missed to add the code when creating new internal realm.
Create a file with recommended extensions for contributors using
VScode as their IDE.
Update `.gitignore` so that the json file is added to the project
repository, without changing how the rest of .vscode is handled.
Previously the edit user modal element was appended inside the
settings overlay itself, so the styles for .custom_user_field
elements nested inside #settings_page were sufficient both for
edit user UI and profile section in personal settings.
e6e60107 changed the code to append edit user modal to body
element and thus existing css was no longer applied to custom
profile fields with custom_user_field class in edit user modal.
This commit fixes to have same styles for .custom_user_field
elements in #edit_user_form.
This tool helps catch common typos in code and documentation, which is
particularly useful for our many contributors who are not native
English speakers.
The config is based on the codespell that I ran in
https://github.com/zulip/zulip/pull/18535.
A user wouldn't differentiate between a "normal" modal and a "settings"
modal. If one shows up instantly, one would expect all the others to do
the same. The difference between Bootstrap fade and non-fade is pretty
noticeable (300 ms for fading).
This is a prep commit for the Micromodal migration which will have 120ms
as the animation time which wouldn't feel slow.
We attach the DOM for the modal to the body element
to avoid style interference from other elements and having to choose
a separate parent element for every single dialog_widget.
Not proxying these requests through camo is a security concern.
Furthermore, on the desktop client, any embed image which is hosted on
a server with an expired or otherwise invalid certificate will trigger
a blocking modal window with no clear source and a confusing error
message; see zulip/zulip-desktop#1119.
Rewrite all `message_embed_image` URLs through camo, if it is enabled.
Previously, there existed a bug where clicking an open message edit
box when the compose box was open would not focus the message edit
contents, but would instead:
- focus the message edit content,
- close the compose box,
- and unfocus the message edit content.
That first bug was fixed in 4e1525d7c4
which eliminated the unfocus part of that problem, but closing the
compose box is undesirable here anyway, since often it can be useful
to have compose open while interacting with the sidebar filter widgets
or working on editing a message.
Click_handler.js was created in commit
e5467d3268 by moving code from ui.js.
While making this change, some handlers were rearranged, but the part
of this comment saying "... code above" was never changed. This commit
changes that part of the comment to refer to the correct handler
(which is labeled by a comment as MAIN CLICK HANDLER).
The `make_compose_box_original_size` function is designed in such a
way that it should only be called when it actually needs to resize the
compose box. In 3 of the 4 places that called it, we checked whether
the compose was already the original size; this fixes the 4th to do
the same.
We add discussion id and url in the comments and highlighted title to
the body of disscussion message to make it more meaningful and accessible.
Fixes#19938.
Since it's a button, it doesn't need the "keydown" event. So,
removed it. This fixes the bug where pressing any key while the
avatar's delete_button was in focus would pop up the modal.
It was introduced in e5d0448505.
Most important is adding the icons to help users understand the
recipients of the stream, but we also use clearer language that better
matches that present in the user interface.
This made it impossible to e.g. use Font Awesome icons inside a `<ul>`
list item (they worked correctly inside `<ol>` list items).
This line was apparently added in
17ad591eb4. The original thinking
behind this line is not clear in the original PR, but is likely a
forgotten relic from experiments with a custom unordered list bullet
styling.
We aim to use Zulip topics thoughtfully in displaying messages from
discussions, as well as linking to the discussion in every message so
that it's easy to view them.
Fixes#19938.
Supporting URL percent-encoded bytes is possible using `%%20`, but this
is not necessarily very understandable to end-users, even those that
understand percent encoding.
Allow `%20` in linkifier URL format strings, and transform them into
`%%20` in the pattern just before they are applied in markdown
translation. Care must be taken here, such that already-escaped `%`s
are not escaped an extra time.
We do this before rendering, and not before storage, as
a simplification; the JS-side linkifier at present only understands
`%(foo)s` and thus needs no changes, and to avoid an un-escaping pass
before showing in the admin UI.
User-supplied custom realm filter has had some sort of regex-based
validation of the format URL since their introduction in
d7e1e4a2c0 -- and this has always been
in addition to the URLValidator. The URLValidator is the one which
does the security-relevant work of validating that the schema is
reasonable, and that the overall shape of the URL is well-formed. The
regex has served primarily to arbitrary limit the characters that can
appear in the URL, in the mistaken name of safety.
Adjust the regex, such that its only purpose is to verify that the
usages of `%` characters in the URL are reasonable, and leave the URL
validation to the URLValidator, which can do a far better job. This
includes broadening the support to include `%%` as an escape
character; this is likely such a niche case as to be unnecessary, but
costs little.
Fixes#16013.
This provides a cleaner organization for our display settings, to make
browsing them more intuitive for new users.
We still need to update the /help/ documentation following this migration.
Fixes#19960.
og:image is supposed to be an absolute URL, but some sites incorrectly
provide a relative URL. In this case, it makes more sense to
interpret it relative to the full page URL after redirects, rather
than relative to just the domain part of the page URL before
redirects.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We don't yet have a do_reactivate_stream function, but we reserve a
number since:
1. It'll likely be added in the future.
2. For now, we can restore archived stream with some manual intervention
in the Django shell, and for that we'll want to create an appropriate
RealmAuditLog entry.
Removes the `/day` and `/night` options from the typeahead menu while
still allowing the commands to be used. Typing `/day` and `/night`
will now suggest `/light` and `/dark`, respectively. Also changes the
`Dark mode` and `Light mode` popups that appear after using the
corresponding command.
Fixes#18318.
Created a schema for the ignored_parameters_unsupported that is
returned by the /settings and /realm/user_settings_defaults endpoints
and removed the duplicated text in the api documentation.
Also cleaned up some small errors in the /realm/user_settings_default
definition and sidebar link /api/update-realm-user-settings-defaults.
Fixes#19674
Since 3853285241, PushNotificationsWorker uses the aioapns library
to send Apple push notifications. This introduces an asyncio event
loop into this worker process, which, if unlucky, can respond poorly
when a SIGALRM is introduced to it:
```
[asyncio] Task exception was never retrieved
future: <Task finished coro=<send_apple_push_notification.<locals>.attempt_send() done, defined at /path/to/zerver/lib/push_notifications.py:166> exception=WorkerTimeoutException(30, 1)>
Traceback (most recent call last):
File "/path/to/zerver/lib/push_notifications.py", line 169, in attempt_send
result = await apns_context.apns.send_notification(request)
File "/path/to/zulip-py3-venv/lib/python3.6/site-packages/aioapns/client.py", line 57, in send_notification
response = await self.pool.send_notification(request)
File "/path/to/zulip-py3-venv/lib/python3.6/site-packages/aioapns/connection.py", line 407, in send_notification
response = await connection.send_notification(request)
File "/path/to/zulip-py3-venv/lib/python3.6/site-packages/aioapns/connection.py", line 189, in send_notification
data = json.dumps(request.message, ensure_ascii=False).encode()
File "/usr/lib/python3.6/json/__init__.py", line 238, in dumps
**kw).encode(obj)
File "/usr/lib/python3.6/json/encoder.py", line 199, in encode
chunks = self.iterencode(o, _one_shot=True)
File "/usr/lib/python3.6/json/encoder.py", line 257, in iterencode
return _iterencode(o, 0)
File "/path/to/zerver/worker/queue_processors.py", line 353, in timer_expired
raise WorkerTimeoutException(limit, len(events))
zerver.worker.queue_processors.WorkerTimeoutException: Timed out after 30 seconds processing 1 events
```
...which subsequently leads to the worker failing to make any progress
on the queue.
Remove the timeout on the worker. This may result in failing to make
forward progress if Apple/Google take overly long handling requests,
but is likely preferable to failing to make forward progress if _one_
request takes too long and gets unlucky with when the signal comes
through.
Anders Kaseorg
Sahil Batra
Ganesh Pawar
Lauryn Menard
Suyash Vardhan Mathur
Tim Abbott
rht
YashRE42
Mateusz Mandera
Alex Vandiver
Shlok Patel
Aryaman
nooblag
Alya Abbott
RISHABH SIDANA
Kartik Soneji
isakhagg
Jonny Tran