This fixes a regression in 16bd6e6b1d
that caused the user profile modal to display "Last active: Last active: ...".
I'm not convinced these are the best visuals, but the whole modal
needs a visual refresh.
We split recent_topics module into recent_topics_(ui + data + util).
This allows us to reduce cyclical dependencies which were
created due to large list of imports in recent topics. Also, this
refactor on its own makes sense.
`user-profile-modal` is shown using `overlays.open_overlay` which
disables mouse pointer events. The user can't click anywhere while a
modal is present, except to close it.
We use `hide_all_except_sidebars` and `hide_all` to hide popovers.
But since the user can't interact while a modal is present,
closing it manually is redundant.
In d0f8515b50, it was noticed that
Bootstrap's `hide` and `show` calls can cause race conditions.
So, migrate to our `overlay` calls to handle Bootstrap modals.
This should make it more intuitive to add
new elements to the compose box (such as
banners), and it also makes it a bit more
clear for styling purposes that the same
geometry happens whether the compose box
is open or the buttons are visible.
I lifted the #compose_container div into
the server template. It's not totally
clear to me why we need both #compose
and #compose_container, but there are
some scary comments about 1400px that
made me too timid to address that quirk.
In passing I removed a clearly redundant
click handler.
For create stream icon specially, this is useful to allow user having
some extra space around the icon to click.
This fixes the bug that you can have the tooltip of "Add streams" and
by hovering at the bottom of `+` icon but clicking on it shows stream
search.
When message for which tooltip is active has reduced opacity in
an interleaved view due `.message-fade` class being applied to
it, then the tooltip used stack vertically under the recipient_row
which looked awful.
Appending the tooltip to document.body and manually fixing the
bug of tooltip persisting after the reference element is no
longer visible in DOM using MutationObserver does the trick
for us.
Instead of prepending the alert's content to the
navbar alert wrapper HTML it's better to pass the
rendered alert content as a parameter to the wrapper
template.
This is done so that it can be shared by more generally
by different filter widgets used in web-app. An extra parameter
is added to it that helps to get text representation of of items
to be sorted, as items passed to it could be of different format.
Instead of just depending upon clicks of certain buttons to
show the right section, we also show them when user is
creating a new stream or viewing settings of a specific stream.
This fixes a bug where user lands on `#streams/new` via url change
without clicking of any buttons and sees on left section of the
overlay in medium width (756px) devices.
We add a popover on click which allows user to create or browse
streams too.
Reason for doing so:
At present, it is hard to discover how to join streams
and create new streams. In particular:
Users have a hard time finding the gear in the STREAMS
header in the left sidebar and realizing that it's relevant for them.
Even once a user is in the STREAMS menu, the Create
stream button is hard to spot.
Fixes#18694.
The Help Center article talks about these using similar terms, which
may need further work, but it seems clear that undoing "set
unavailable" should be "set available", not "set active".
This moves this block of HTML templates, which are dynamically
rendered with some user data, to be managed by the frontend handlebars
template system.
This migration involves only displaying active alerts in the DOM, and
thus we no longer need navbar_alerts to have display: none by default.
This is important for showing popovers/menus with a light background
in Zulip's light theme.
We extend light-theme to show dark colours in night theme.
Rapidly clicking a button that shows a modal cause a race condition
in Bootstrap. Specifically, Bootstrap adds an "in" class to a modal
on the "shown" event and removes it on the "hide" event. Frequent clicks
cause the "hide" event to trigger before the "shown" event. Therefore, the
"in" class isn't removed. We use the "in" class to check if a modal is
active in overlays.js
For now, we manually remove it once the modal is hidden.
Newer versions of Bootstrap probably handle this better internally.
Look into removing this once it's upgraded.
Fixes#15463
In commit 9ce9c2f9db, we added `maybe_show_keyboard_shortcuts`
function which triggered through hotkeys.js when a user
presses the keyboard shortcut hotkey.
However, within commit 8b29c38e62, we migrated to use
hashchange.go_to_location method in order to open info_overlay, leaving the
`maybe_show_keyboard_shortcuts` function orphaned/dead.
This commit essentially removes the dead
`maybe_show_keyboard_shortcuts` code.
Rename poll_timeout to event_queue_longpoll_timeout_seconds
and change its value from 90000 ms to 90 sec. Expose its
value in register api response when realm data is fetched.
Bump API_FEATURE_LEVEL to 74.
This commit renames `delete_draft_after_send` to
`delete_active_draft` for two main reasons:
1) This function does the job of deleting the draft that we
are currently using in compose box and it is independent
of the message sending functionality.
2) This is prep refactoring for new drafts behavior where
we delete the draft if the compose box is cleared and
closed.
This changes the button text from "Reply" to "Reply to selected
message". Here's the thinking:
* The title "Reply" was a little confusing/inconsistent with the
button's label.
* If you're hovering over the button, it's because you want more
information about what it does -- not just a repeat of the button's
label.
* The "Message foo > bar" content of the button already cleanly
expresses what the button will do if you click it right now.
* The hover text "Reply to selected message (r)" explains to you what
that button's role is in all situation, not just with the current
selection, and thus documents the concept. And it also gives you
clarify if you're thinking "but how do I reply to something in
Zulip?" and try hovering over the buttons at the bottom to find out.
This commit divides the user_invite_restriction setting dropdown to
a checkbox and a dropdown.
The checkbox is used for 'realm_invite_required' setting and dropdown
for 'realm_invite_to_realm_policy'.
This separation of UI elements is fine as these two settings are
separate in database also and also helps in removing excess if-else
conditions and switch cases.
We do not require values of realm_create_stream_policy,
realm_invite_to_stream_policy, realm_private_message_policy
and realm_wildcard_mention_policy in the organization settings
templates, as we handle the dropdown values of these settings
in javascript code (settings_org.js) only and these values
are not used anywhere in templates.
Previously the logic to show save button considered only topic
and content edit. This commit fixes it to show the save button
when only stream edit is possible and content and topic edits
are not.
This commit only introduces a simple fix, in long-term we would
want to change the logic of get_editability to include stream
edits as well but it would also require discussion on when to
show the edit icons at different places, so it is better to do
it in a separate commit later.
Tim Abbott
m-e-l-u-h-a-n
Aman Agrawal
Ganesh Pawar
Steve Howell
Vishnu KS
Riken Shah
aryanshridhar
Anders Kaseorg
Wesley Aptekar-Cassels
Gaurav Pandey
sahil839