The vertical shifts in message body was due to the <p> tags it gets when
converted to markdown. Removing the top margin from the first <p> child
and bottom margin from the last <p> child resolves this issue as due to
those default margins in <p> tags there was vertical shifts in message
body.
Fixes: #21276.
Added type annotations to function parameters, function return
values and local variables. Added neccessary `if` statements to
enforce the objects having proper type before executing the later
operations.
An error type check in the catch block in `update_favicon`
function is added because the statement in the catch block requires
error to be a type `Error` in order to access `error.stack`.
Since logrotate runs in a daily cron, this practically means "daily,
but only if it's larger than 500M." For large installs with large
traffic, this is effectively daily for 10 days; for small installs, it
is an unknown amount of time.
Switch to daily logfiles, defaulting to 14 days to match nginx; this
can be overridden using a zulip.conf setting. This makes it easier to
ensure that access logs are only kept for a bounded period of time.
Following zulip/python-zulip-api/pull/758/, we're no longer using
python-zephyr, and don't need to build it from source. Additionally,
we no longer need to build a forked Zephyr package, since ZLoadSession
and ZDumpSession were merged in
e6a545e759.
To not change the `supervisor.conf` file, which requires a restart of
supervisor (and thus all services running under it, which is extremely
disruptive) we carefully leave the contents unchanged for most
installs, and append a new piece to the file, only for the zmirror
configuration, using `concat`.
This commit refactors the topic_menu visible check and hide logic,
since we have already migrated the popover from stream_popover.js.
This last bit of code related to topic_menu is also migrated to
popover_menus.js, and the code is refactored to use the new logic,
which is more common for the popover_menus.js system.
To hide the popover, one possible solution could be to use the
hideAll method from TippyJS. However, this could lead to
unintentional behavior for all the popovers. To prevent this, the
hide method is used for the topic_menu only.
This commit removes the use of a separate keyboard handler for
the topic_menu, as we are already using a common keyboard handler
for all Tippy popovers.
This commit migrates the topic_menu popover from stream_popover.js
to popover_menus.js. Since the data required for rendering is large,
it has been moved inside popover_menus_data.js to improve code
readability.
Getting the link of the topic for the clipboardJS inside the onMount
instance was not working with the existing method. To make it easier
to work with, a new attribute, data-clipboard-text, is added to the
'Copy link to topic' anchor tag. This allows the clipboardJS to catch
the URL. The value of data-clipboard-text is sent from popover_menus.js
to the topic_sidebar_actions template.
Fixes: #23891
This is a prep commit for migrating the topic popover to a Tippy
popover.
'elem_to_stream_id' function is used for the topic menu to find the
stream_id of the target topic menu.
This commit passes the body of the PR Review as the message to
the helper function that generates the message to be sent by the
GitHub Integration.
Previously when a PR Review was done the message sent would just
include the link of the review but the message didn't include the
body the review. After this commit, the message also includes the
body of the review.
Fixes#24676
In this commit we remove any explicit references to the polyfills and
replace all the color codes to the hsl() format. We also remove any
other redundant code, after testing for any regressions.
In this commit, we move the progress bar styling out of the legacy
bootstrap.css and move it to a dedicated CSS file. This is a step
forward towards the ongoing effort to remove the use of Bootstrap
from the Zulip codebase.
The new CSS file, progress_bar.css, is added to common.ts, since it
is used in both the webapp and portico pages.
Fixes#23628.
Previously, we had an architecture where CSS inlining for emails was
done at provision time in inline_email_css.py. This was necessary
because the library we were using for this, Premailer, was extremely
slow, and doing the inlining for every outgoing email would have been
prohibitively expensive.
Now that we've migrated to a more modern library that inlines the
small amount of CSS we have into emails nearly instantly, we are able
to remove the complex architecture built to work around Premailer
being slow and just do the CSS inlining as the final step in sending
each individual email.
This has several significant benefits:
* Removes a fiddly provisioning step that made the edit/refresh cycle
for modifying email templates confusing; there's no longer a CSS
inlining step that, if you forget to do it, results in your testing a
stale variant of the email templates.
* Fixes internationalization problems related to translators working
with pre-CSS-inlined emails, and then Django trying to apply the
translators to the post-CSS-inlined version.
* Makes the send_custom_email pipeline simpler and easier to improve.
Signed-off-by: Daniil Fadeev <fadeevd@zulip.com>
We see connection timeouts and other access issues when run exactly on
the hour, either due to load on their servers from similar cron jobs,
or from operational processes of theirs.
Move to on the :17s to avoid these access issues.
Changed the `.enter_sends` css selector for launching tippyjs popover from
`compose.hbs` because it was colliding with `.enter_sends` selector present in
`organization_user_settings_defaults.hbs`.
Before this change when an admin tried to change user realm default setting of
`enter_sends` it was opening a tippyjs popover despite being a checkbox and it
was hitting `/json/settings` endpoint instead of `/json/realm/user_setting_defaults`.
Converted `emoji.js` to TypeScript by adding relevant type definitions,
also modified `target` option in our tsconfig to 'ESNext' so that types
for object methods like `hasOwn` which is being used in `emoji.js` are
included.
This is a prep commit for typescript migration of `emoji.js`. This
commit refactors the code for generating emoji rendering details such
that we avoid writing an ugly code which will involve writing an
incomplete type object when we migrate to TypeScript.
While the previous commit handles the common case of all of the server
being started already, it still produces ERROR output lines from
supervisorctl when most of the server is already running. Take the
case where one worker is stopped:
```
$ supervisorctl stop zulip-workers:zulip_events_deferred_work
zulip-workers:zulip_events_deferred_work: stopped
$ ./scripts/start-server
2023-04-04 15:50:28,505 start-server: Running syntax and database checks
System check identified no issues (15 silenced).
2023-04-04 15:50:31,977 start-server: Starting Tornado process on port 9800
zulip-tornado:zulip-tornado-port-9800: ERROR (already started)
2023-04-04 15:50:32,283 start-server: Starting Tornado process on port 9801
zulip-tornado:zulip-tornado-port-9801: ERROR (already started)
2023-04-04 15:50:32,592 start-server: Starting django server
zulip-django: ERROR (already started)
2023-04-04 15:50:33,340 start-server: Starting workers
zulip-workers:zulip_events_deferred_work: started
zulip_deliver_scheduled_emails: ERROR (already started)
zulip_deliver_scheduled_messages: ERROR (already started)
process-fts-updates: ERROR (already started)
2023-04-04 15:50:34,659 start-server: Done!
Zulip started successfully!
```
More gracefully handle these cases:
```
$ ./scripts/start-server
2023-04-04 15:52:39,815 start-server: Running syntax and database checks
System check identified no issues (15 silenced).
2023-04-04 15:52:43,270 start-server: Starting Tornado process on port 9800
2023-04-04 15:52:43,287 start-server: zulip-tornado:zulip-tornado-port-9800 already started!
2023-04-04 15:52:43,287 start-server: Starting Tornado process on port 9801
2023-04-04 15:52:43,300 start-server: zulip-tornado:zulip-tornado-port-9801 already started!
2023-04-04 15:52:43,300 start-server: Starting django server
2023-04-04 15:52:43,316 start-server: zulip-django already started!
2023-04-04 15:52:43,793 start-server: Starting workers
zulip-workers:zulip_events_deferred_work: started
2023-04-04 15:52:45,111 start-server: Done!
Zulip started successfully!
```
Currently, the output from `start-server` if the server is already
running is potentially confusing, since it says ERROR several times:
```
$ ./scripts/start-server
2023-04-04 15:35:12,737 start-server: Running syntax and database checks
System check identified no issues (15 silenced).
2023-04-04 15:35:16,211 start-server: Starting Tornado process on port 9800
zulip-tornado:zulip-tornado-port-9800: ERROR (already started)
2023-04-04 15:35:16,528 start-server: Starting Tornado process on port 9801
zulip-tornado:zulip-tornado-port-9801: ERROR (already started)
2023-04-04 15:35:16,844 start-server: Starting django server
zulip-django: ERROR (already started)
2023-04-04 15:35:17,605 start-server: Starting workers
zulip_deliver_scheduled_emails: ERROR (already started)
zulip_deliver_scheduled_messages: ERROR (already started)
process-fts-updates: ERROR (already started)
2023-04-04 15:35:18,923 start-server: Done!
```
Catch the simple common case where all of the services are already
running, and output a clearer success message:
```
$ ./scripts/start-server
2023-04-04 15:39:52,367 start-server: Running syntax and database checks
System check identified no issues (15 silenced).
2023-04-04 15:39:55,857 start-server: Zulip is already started; nothing to do!
```
Adds the user ID to the return values for the `/fetch_api_key` and
`/dev_fetch_api_key` endpoints. This saves clients like mobile a
round trip to the server to get the user's unique ID as it is now
returned as part of the log in flow.
Fixes#24980.
This reverts commit 5f4bdfe6bc (#24630).
This was causing Webpack to trigger type checking with the TypeScript
compiler, which is very expensive.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit updates 'test_user_ids_unmuting_topic' to make
an api_post call to '/api/v1/user_topics' instead of
calling the internal function 'do_set_user_topic_visibility_policy'
to verify the logic.
This commit adds a new endpoint, 'POST /user_topics' which
is used to update the personal preferences for a topic.
Currently, it is used to update the visibility policy of
a user-topic row.
This is a prep commit that renames lib functions
so that they can be used while implementing view
for the new endpoint 'POST /user_topics'.
We use a more generic name when removing the visibility_policy of
a topic, i.e., 'access_stream_to_remove_visibility_policy_by_id/name'
instead of 'access_stream_for_unmute_topic_by_id/name' which focused
on removing MUTE from a topic.
Anders Kaseorg
atharmohammad
AcKindle3
xoldyckk
Alex Vandiver
Tim Abbott
palashb01
sbansal1999
Ishita Gupta
Daniil Fadeev
Lalit
Lauryn Menard
Prakhar Pratyush
Mateusz Mandera