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 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.
Previously, we had this complicated layering where the right sidebar
logic would display "Last active: foo" but the user popovers would
just display "foo", which doens't make any sense, since the two
settings have equal context about the string.
We deduplicate that and also arrange that the "Last active:" prefix is
used when it's not clear what we're talking about; i.e. all the values
except for "Active now".
There is no clear reason to not use a button element here. According
to the spec pharasing content, which includes the <span> element,
are allowed in the button element.
Manually tested both buttons to make sure it works and made sure all
the selectors are updated by grepping all the selector classes/id in
the handlebars templates that are parents of the button or are
present on the button.
(One of the jQuery handler code got reformatted due to it fitting
the line limit due to one character deletion for the selector)
Modified resend_invite modal heading to remove the email
field to avoid it's duplication, since the email feild is
also displayed within the actual modal body.
Tested by the adding a console log to the handlers and typing Tab
and Enter in the group PM and stream compose box. This two event
handlers are attached to form#send_message_form which is the compose
box form.
The tests set keyCode to 42 previously, which does not represent a
valid key, so I assume they were trying to test a random key, and
replace it with "a".
There is no functionality change caused by this change. We turn the
event key to lowercase so hotkeys work even when Caps Lock is on as
it did before.
Tested by using the keybinds with and without Caps Lock in compose
box:
- "Ctrl + B" and "Ctrl + Shift + B",
- "Ctrl + I", and
- "Ctrl + Shift + L".
(Also tested that "Ctrl + Shift + I" and "Ctrl + L" do not work.)
Tested by doing the following in the compose box input for PMs:
- "Enter" works as expcected with and without input
- "Backspace" when there is no input deletes the last pill
- Left arrow in the input focuses last pill
- Comma works as expected for correct and incorrect input
- Left arrow, Right arrow and Backspace work correctly for pills.
We use e.key for our side of code and still pass e.keyCode and
e.which to the custom jQuery event we trigger. The event is handled
by our patched copy of outdated bootstrap and it still requires the
e.keyCode and e.which properties.
One of the places this widget is used is in the settings panel, at
Manage Organization > Organization Settings > Notifications > New
stream notifications. One of the handler is attached to the
dropdown menu items that shows up when you click the "#announce"
button. The other one is attached to the search button. The second
one triggers the custom jQuery event and passes the event data to
bootstrap unless the Up & Down arrow or Esacape is used. The first
event handler handles the Enter click on one of the items and saves
it. Verified that the widget works as expected.
Tested by making sure Enter is treated as click at one of the places
this function is used, recent topics view. Using the keyboard to
focus the mute or read button and click Enter treats it like a
click.
Tested by making sure pressing Enter in the input field of the
changed organization settings (the organization name for example)
clicks the save changes button if present.
This change fixes a bug where pressing Enter does not save the
changes as expected, due to an incorrect selector, when the
save/discard changes button shows up in settings. Tested by changing
the Organization name and pressing Enter at Manage Organization >
Organization profile > Organization name.
The Giphy SDK sends tracking pings when it loads; we don’t want those
to be sent for visitors who aren’t using Giphy.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We were passing new_stream_id as undefined in case of topic
edit as event.new_stream_id is undefined in that case.
We pass the correct stream_id to fix it.
The Event.which and Event.keyCode are deprecated as pointed out by
TypeScript intellisense based on the jQuery types. We use Event.key
instead which behaves similarly to Event.which & Event.keyCode for
our use case.
The only difference in functionality by this change is that the vim
keys won't work when Caps Lock is on. This is because, in this case,
the key property will be "J" instead of 'j'. We can fix this by
adding a mapping for this, however, I think we don't want to handle
this case so I left this change out. Tested by trying out the
everywhere keydown_util is used.
Finally, we also turn off the new-cap rule for tests since I think
it fine to only enforce it on real code and exempting test code is
fine.
This commit disables the button and shows a loading spinner on
the button when signup request is being processed to avoid race
conditions caused by user clicking on the button multiple times.
The fix is done observing that for the case when form is invalid
the whole page is rerendered and thus we do not need to remove
the spinner and enable the button again and for other errors
we redirect to some other page.
And for the validation taking place in client-side, the button
is disabled and spinner is shown, only is form is valid, by
using "$('#registration').valid()".
We live update the "Add subscribers" UI on subscribing/unsubscribing
the stream and the field sub.can_add_subscribers is used to check
whether user is allowed to add subscribers or not.
The sub object used here is not the complete sub object and thus
sub.can_add_subscribers is undefined. We need to use the updated
sub obejcts with all the setting fields that we can get from
'stream_settings_data.get_sub_for_settings' before rendering UI.
This calculation of additional fields was done previously by
'stream_data.update_calculated_fields', but in d50462568b
call to 'updated_calculated_fields' was removed with the aim to
call 'get_sub_for_settings' before updating UI which was missed
in this part of UI update.
Fixes#18616.
Source in pill_typeahead, was intialized in a
very tricky way. In this cleanup, we refactor it
to clearly reflect how source is initialized for
different cases. These changes do not change its
behavior for its current use and solve potential
issues, so that it could be safely used at places
that do not require user pills at all.
In options that we pass to pill_typeahead.set_up we
specify if we want typeahead to support stream or
user_group pills, and use users as source by default.
Using users for source by default, can have unnecessary
suggestions in typeaheads where only user_groups or streams
are needed.
So to solve that, we specify if we want users pill in the input.
This is then utilized in further commits, to clean up hacky code
that deals with intializing source for typeahead.
We make the typeahead a little more nicer but only showing one alias
per language. For example if the user searches for prefix "j", then
the typeahead list should contain "javascript" only, and not "js" and
"javascript".
When muted user's message is revealed, popover should have
an option for hiding the message again. But in case if the
popover is already open while message is being revealed then
option for undo reveal in the popover could be out of sync.
To avoid this, we hide the message actions popover before
revealing muted user's message.
Tooltips in message action buttons for failed message were
not shown properly because they were initialized two times
first because of general tippy-zulip-tooltip class and then
because of message_control_button class. So to avoid showing
an extra empty tooltip for failed message icons we return
false from onShow() method of message_control_button class
initialization of tooltip.
This check was not needded as it is possible to have even zero
edit message buttons in cases when a message is fails. So it
raises unncesary errors on hovering over icons of those failed
messages.
Since this is currently only useful to interpret presence data, we
send this only if presence is requested.
I'm not sure that server_timestamp is the right name for this field,
but ultimately it should match the main presence API format.
When quoting a reply or mentioning a person having full name matching
wildcard mention, in such case, `get_mention_syntax` doesn't return
mention syntax of format: **full_name|user_id**.
As a result, a normal user can't mention such users and users who
can mention them may unwillingly trigger wildcard mention.
This commit fixes such issue.
Prior to this, we restricted to show any user group suggestions
if silent mention syntax is used. But with the addition of
user group silent mentions, there are cases where one may want to
refer to some user groups without actually notifying them.
So, we add typeahead logic for such cases.
Test cases for silent syntax (@_*) and non-silent syntax (@*)
are added.
The regex could have match a bunch of characters including `>`
and hence end up matching across multiple adjacent spans in
a weird way. This commit fixes such an issue.
We add a '?' icon besides the "GIPHY integration" label of
giphy settings dropdown.
The icon links to readthedocs page for setting up giphy API
key when api key is not set, and it points to help center
article of GIFs when the api key is added.
The extracted logic is in linkifier.js.
We have decided to name it linkifier.js instead of realm_linkifier.js
because in future when we will add stream-level linkifiers, we'll
likely want them to be managed by this same file.
We fix the code to show giphy icon live update only if the
updated setting is not disabled and API key has been added.
Though the dropdown is disabled,the setting can still be
changed using API, so this change is necessary.
Previously, we were not checking whether API key is there or
not and icon was shown on live update even if API key was
not there and then it went off on reload.
The command:
codespell --skip='./locale,*.svg,./docs/translating,postgresql.conf.template.erb,.*fixtures,./yarn.lock,./docs/THIRDPARTY,./tools/setup/emoji/emoji_names.py,./tools/setup/emoji/emoji_map.json,./zerver/management/data/unified_reactions.json' --ignore-words=codespell_ignore_words.txt .
The content of codespell_ignore_words:
```
te
ans
pullrequest
ist
cros
wit
nwe
circularly
ned
ba
ressemble
ser
sur
hel
fpr
alls
nd
ot
```
The inconsistent style between these three buttons looked bad.
We have to take some care with the "Starred messages" and "Edit" ones,
to make sure they live-update properly.
Previously, the focus event tends to skip the first
element within the dropdown list when the user presses
the down arrow.
Added a stopPropogation event for keydown handler within
dropdown_list_widget which propoerly binds the focus
event to the dropdown list items.
Previously, the "Move topic" option was only displayed to organization
administrators, despite the new setting making who can move topics
between streams configurable.
Making this migration requires us to remove the text on the previous
"Admin actions" divider, and just make it an hrule, to avoid confusing
normal users, while still providing a hint that moving topics is a
non-personal operation.
We also change the ordering for consistency.
This commit adds the dropdown in 'Stream settings' section of organization
permissions page to control who can move messages between streams and
also hides the stream-edit UI in message-edit form accordingly.
Fixes#14499.
This also handles a few other places missed earlier like
narrow headings, beacuse they use the same function.
We already rerender the PM list for events, so there's no
need to do anything special when someone is muted/unmuted.
`people.get_full_names` is now only used in the settings pages
while creating ListWidgets etc, so we add a new test for
it to ensure coverage.
Directly rendering the default view on pressing `escape` key will lead
to default_view being rendered on the current window hash. So, we set
empty hash to load default view and let hashchange handle it.
This fixes a bug introduced in
59a45d3521.
Long ago, we changed Zulip to inspect server-provided topic history in
our compose and search typeahead modules, but did not trigger a query
to the server to fetch data.
This could result in confusing experiences where someone thought that
a topic doesn't exist that just isn't present in recent history.
Once we merge this, we may want to adjust the messaging in typeahead
to advertise that the first option will create a new topic, since this
change may make it feel more like creating topics is a heavyweight
operation.
Fixes#9857.
We’re getting unexplained exceptions from URL.createObjectURL in
Firefox 88 (#18374); contain them to this function.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Previously, the hook to save drafts when closing the compose box was a
focusout on #compose-textarea. This mostly worked, and was essentially
invisible to users (because the animation to notify you about saved
drafts was in the close_compose_ui widget that is hidden), but you'd
end up seeing the tooltip appear (in the wrong place) if you closed
the compose box immediately after sending a message with Tab+Enter.
The correct fix is for the drafts hook to be just before we start
clearing compose box state, inside hide_box.
This was difficult to catch in a development environment, since one
doesn't use that flow with "Enter sends" enabled.
We were apparently not using the ListWidget API for replacing the
content of a widget without removing the whole thing from the DOM and
replacing it.
Unless ListWidget has unexpected bugs, this should have the exact same
result as the previous logic, with much a nicer user experience.
We use styling same as that of the number shown for overflow
(e.g "+3") which has a gray background.
To keep these avatars up-to-date, we need to rerender the
recent topics view after receiving a `muted_users` event.
Also update the user documentation to mention this detail.
We deliberately avoid mentioning "recent topics" because
this applies to mobile too.
This seems more consistent with what users would expect; Recent topics
may be a better default view in general, but if a user has picked
another default view, we should use that where the default view is
desired.
The default label for empty narrows depends on whether it's a
stream/topic narrow or a PMs narrow.
We leave some default text in compose.hbs for reply label
because it take some time for the js to display the
correct label.
The browser seems to autofill the `Name` field of the add-playground
form. Most likely this behavior is a result of value of the `name`
input field being `name`, causing the browser do to something weird
here. This name is now changed to `playground_name`.
The old logic, inline in the compose area, has produced a very weird
effect where the buttons would move to fit the notification, ever
since design changes to use the full bottom row space.
We address this by just using a Tippy tooltip instead.
Share code between `safe_full_names` and `get_display_full_names`
functions, and rename `safe_full_names` to `get_full_names_for_poll`,
because that was the only place where this was used earlier.
This also has the nice side effect of showing "Muted user" instead
of the muted username in poll results.
Instead of changing the hash to the default_view hash, we render
the default_view directly in case of recent topics and all messages.
This also fixes the bug that user is unable to go back in
browser window history.
We don't want to rely on browser hash to check if RT is visible
because soon we want to display default_view without any hash
and RT may or may not be visible in that hash.
Active stream's hash look like this - `#streams/1/announce`
Since the stream_id is present where typically hash section
is for all other hashes, get_current_hash_section should return
the same result.
Added a commit to bind vim keys with the SettingsPanelMenu,
allowing users to control the settings and organization tabs
using 'h','j','k' and 'l' keys.
vim_left('h') -> Switch between tab by shifting focus to the left.
vim_right('l') -> Switch between tab by shifting focus to the right.
vim_up('k') -> Move up.
vim_down('j') -> Move down.
Also link to it from the API documentation page,
other help pages, and the confirmation dialog for
muting a user.
With substantial edits by tabbott and alya.
To calculate the max-height of buddy_list_wrapper, we use
invite-link-height. This works alright if inviting is enabled
for all. However for users who aren't permitted to invite,
the element does not render, hence the logic uses `0` as
default value for subtraction in `get_new_heights` function
under resize.js. This leads to the keyboard-shortcut icon
rendered below the browser window. Hence use the parent div
`right-sidebar-shortcuts` height for the logic.
* Remove unnecessary json_validator for string parameters.
* Update frontend to pass right parameter.
Bump api feature level and highlight the fix for `emojiset`
parameter of `settings/display` endpoint in zulip.yaml file.
Fixes part of #18035.
* Remove unnecessary json validator for string validator.
* Update frontend to pass right validator.
* Update zulip.yaml to pass right parameter for curl request
in openapi.
* Update python_examples to pass right paramater.
Fixes part of #18035.
Commit ad76df25ac (#18405) uses Map
incorrectly. A JavaScript Map needs to be indexed with .get() and
.set(), not with [].
Also, clean up the API: ‘lookup_table’ is a meaningless variable name,
and there was no information in the array that wasn’t also in the Map.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The previous `top_offset` calculation didn't include the height
of the panels which led the calculations to be performed as if
a portion which was hidden behind the searchbox, was visible to
the user.
The new formula is corect as the frb_top calculation in
panel.resize_app also uses panels_height.
A modal is added to edit the realm linkifier which
supports ui_report error.
Puppeteer tests to verify linkifier update and an
invalid test to verify that linkifier error messages
are reported on the modal are added as well.
Implemented dropdown_list_widget in Move topic popover which enables,
the functionality to search for streams while moving a particular topic.
The aim is to reduce the user effort by having an input
typeahead instead of haivng a dropdown list of streams.
Closes#14860.
Previously, the focus event was triggering on a hidden
dropdown input field, which caused it to not gain focus when
clicked on dropdown button.
This is so because focus events cannot be triggered to
hidden elements or elements that aren't visible in DOM.
Added a fix by explicilty triggering the focus event to
dropdown input field only if the input field is visible in the DOM.
This is good to do in general for these type of event handlers
and this also fixes a bug where pressing on reply button in
the recent topics will open compose with a new line since
browser assumed enter was pressed on compose_textarea since
process_enter_key returned false.
Since we support hooking up code playgrounds for custom languages
outside of the list of languages supported by Pygments, we display
an option to select a "Custom language" in the typeahead.
The `pygments_name` field typeahead shows a list of human-readable
`pretty_name`to pick from. However, the Pygment aliases which are
used for code highlighting within a code block are different from
these. This mismatch might be confusing for folks unfamiliar with
technical details of the "code playgrounds" feature.
To bridge the gap, we now include the Pygment aliases within
parenthesis along with its human-readable name, in the typeaheads.
E.g: Python 2.x (py2, python2).
Added a fix to bind vim_up(k) and vim_down(j) keys
with the draft section, allowing users to scroll
between the drafts using 'k' (scroll up) and
'j'(scroll down) keys.
Fixes#18397
Previously, we used to hide 1:1 PMs with muted users everywhere
in the UI. This commit makes it so that such messages will now be
visible in `pm-with/<muted_user>` narrows, meaning these will not
be excluded from message lists, but will still be hidden under
the "This message was hidden." dialog implemented earlier.
* We hide 1:1 PMs from and to muted users throughout
the UI, because doing so will not lead to loss of
conversational context. The "to" part is also important,
because the last few messages sent to a user before
muting them would probably be asking them to stop
spamming.
* After this change, we will need to do filtering for either
user or topic muting in pretty much all narrows, so we need
to keep the `_all_items` list in MessageListData always
up-to-date.
* A further commit will relax this and make it possible to
view these messages only when in a `pm-with/muted_user`
narrow.
This basically reverts 4bd7ec7c36 and
3a9dfc02e6.
The plan earlier was to have compeletely different codepaths
for user and topic muting, so that we could call seperate
functions in the message list class on receiving the respective
events.
However, this cannot be done, because if we, for example, on
receiving a `muted_users` event, filter `_all_items` based on
just user mutes, and store the result in `_items`, then, that
result may still contain topic-muted messages, which is
undesirable. Hence whenever we filter messages, we must do so
based on both user as well as topic muting.
(The code for the former will be added in further commits.)
So, we will have a single function which will handle updating
the message lists for muting.
We were losing scroll position after re-render because there
were not enough rows present in the table to focus back to
the same position. With this commit it is possible now since we
always render with enough rows to do so.
We save the scroll position of the user by keeping the topic
row at the center of the visible scroll container in focus. The
avoids focus being reset to first topic row when recent topics
renders. Thus, this improves the UX of recent topics.
Add a function which is called before every render to
get the number of items it can render. This can be used by
instance to load custom number of items as per its state.
We allow ListWidget instances to pass functions in opts that can
be called after scrolling to determine when to render.
Also, allow a callback function to be called pre render.
We move compose from being a part of message feed to
being a part of middle column which is a common parent of recent
topics and message feed. This allows us to use a common compose
box for both the views. Fortunately, compose actions were
independent of this change so there weren't any evident
side effects.
Fixes#17543
* Remove unnecessary json_validator for string parameters.
* Remove unnecessary JSON encoding in frontend calls. Structurally,
JavaScript does correct encoding without explicit JSON encoding.
Fixes part of #18035.
The `.refresh-failed-message button` was registering clicks even
while the button was spinning (has already been clicked once).
Thus a network request was sent for every subsequent click which
raises an exception that the local id is not found in the message
store as it had already been reifyed by the first request.
Fixes#18375.
In this 009b7bca24 commit `before_punctuation`
regex was updated to use lookbehind feature of regex.
This caused a regex error in some browsers (reported in
Safari) because lookbehind feature is not yet supported
on all the browsers (https://caniuse.com/js-regexp-lookbehind).
This commit fixes that error by reverting to stable regex which
works on all the browsers.
Thumbor and tc-aws have been dragging their feet on Python 3 support
for years, and even the alphas and unofficial forks we’ve been running
don’t seem to be maintained anymore. Depending on these projects is
no longer viable for us.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Leave the Intel build as the prominent default, since it will run on
both platforms. (I would have liked to detect the appropriate
platform, but Apple seems to have put significant effort into making
that impossible for anti-fingerprinting reasons, which is probably an
overall good.)
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Due to spaghetti CSS that should be fixed but isn’t fixed here, the
<span> wrapper is still needed so the hover effect is applied.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This button will allow users to avoid a distracting red banner across
their screen, while they wait for their sysadmin to do the upgrade
work.
Fixes: #18359
Since we don't process private messages yet, we don't
need to re-render when we receive a new private message
as it doesn't change any data related to recent_topics.
This will allow us to avoid duplication of array filtering
logic of the form-
`Array.filter((user_id) => !muting.is_user_muted(user_id))` and
`Array.filter((person) => !muting.is_user_muted(person.user_id))`
We want to exclude 1:1 PMs from muted users everywhere
except in `pm-with/<muted_user>`.
This method will help us determine whether we are in such
a narrow.
* We show a "Click here to reveal." hyperlink in the hidden
message dialog for user to click on and read a hidden message.
* The "reveal" action is temporary, in the sense that a revealed
message will again be hidden once the broswer tab reloads or
if the user renarrows.
* When a message is revealed, we make sure to show the sender
of that message, even if it isn't the first message of it's group.
This is because the first message of that message group (which
would have otherwise shown the sender) can still be hidden.
* Reactions and background color after revealing a message are
the same as if the message hadn'e been hidden at all in the
first place.
* We hide the sender and reactions on messages sent by muted
users, and replace the content with a "This message was hidden"
dialog.
* Ideally, we should collapse a series of consequetive
messages sent by muted users into one such dialog, but
that could break the cursor behaviour and `near/<message_id`
links, so we as of now show one dialog per muted message.
* Because we hide the sender, there is a chance of the first
hidden message in a group looking like it was sent by the
author of the message above it. To tackle this, we intentionally
make the hidden message dialog float-left, so that it is clear
that this is a special type of message.
* For context, we still show the timestamp of the message.
* Starring, editing, deleting etc a message still work just like
before.
A further commit will add the ability to reveal a
hidden message.
We were not considering the owner role in `sort_role` function
which was leading to improper sorting when sorting the users
list according to role. This commit fixes this bug by considering
role in `sort_role` function.
We also add a check to see if `message_feed_container` is visible,
since it is possible that recent topics could be visible which
was not a possibility when this logic was written.
The typeahead suggests a human-readable `pretty_name` for the
`language` field in the add-playgrounds form.
The suggestions are sorted based on the popularity of these
languages.
E.g: A `py` prefix would match with `Python` first before
matching with others like `Python 2.x` based on priority.
The UI makes use of an onclick on the trash icon to call
DELETE /realm/playground/{playground_id}. The id is
extracted from the data attribute `data-playground-id`
set on that element.
The design of the form is similar to the linkifiers page
and is styled similarly.
The introduction text for "Code playgrounds" is improved
with more details and examples.
Also, we can remove the hardcoded playground and the fix
we had previously done to prevent breaking the hardcoded
playground.
This commit displays the loading animation and hides other
avatar options as delete_user_avatar is called and as we get
response from the server, we show the options back and hide
the loading animation.
These two blocks of code has incorrectly placed or implemented
conditionals for the rare corner case of Zepyhr mirroring
organizations.
Longer-term, we'll want to refactor this further to directly reference
can_render_subscribers, making the logic more general.
The previous commit remove an obsolete form laying within
subscription_table_body.hbs. However, doing so broke the functionality
of triggering the stream-creation modal using the 'Enter' hotkey.
This commit re-introduces the functionality of loading the stream
creation modal only if the user has the permission to create streams.
At the same time, we make sure it's still possible to subscribe to
streams within zephyr mirroring organizations.
The 'reply' button shows the stream>topic or recipient(s) of the
selected message, for better UX. It also expands to fill the
remaining horizontal space in the button bar -- this should help make
it easier for new users to figure out how to reply.
Finally, it uses "Message" instead of "Reply", to better match the
compose box.
Fixes#17940.
Earlier, a user can only mute a topic from its recipient bar but can't
unmute it from there (and in fact we displayed an option to mute even
if the topic was already muted!). This commit fixes that bug and
allows a user also to unmute the topic from its recipient bar.
There are two core issues here;
* We did not have code, an icon, etc. for the "already muted" case in
the recipient bar logic at all.
* We did not rerender messages in !excludes_muted_topics views when
muting state changed.
See: 660475bd0c for background on when
we started only rerendering the streams with excludes_muted_topics
after muting changes. Rerendering of newly muted topics are important
for live rendering if a user is narrowed to that topic itself, which
are essentially all excludes_muted_topics narrows anyway.
Hence, now, we rerender by calling the `rerender` function for muted
topics (which is done just before we update the items for muting via
the function: `update_items_for_topic_muting`).
Tweaked by tabbott to add comments explaining the reasoning and
long-term plans.
Fixes#15223.
We are restricting the feedback widget (confirmation pop-up)
to be visible to the users if they have muted the topic using
the hotkey: `M`, because if the users have muted the topic in
some other way then it is known to them about their activity.
In fact, the confirmation pop-up was intrusive to some users
(see #2367).
While using the hotkey they can unknowingly mute the topic. Hence, in
such a case, it is necessary to acknowledge the users about their
action.
Since we don't have content for GIPHY popover at the time
popover is rendered, we need to render with some fake
content otherwise popover library doesn't allows for us
to show the popover.
This came into notice after 5adc6d7297
broke show popover behaviour for GIPHY but didn't break it for
emoji popover as emoji popover already renders with some content.
Prior to this commit, popover library used `title` as content for
GIPHY popover.
In the source realm selector, when we select a realm from which we want
to import the data, we pass the source realm's string_id. The problem
with this approach is that the string_id can be an empty string. This
commit makes the source_realm pass the realm's id instead of string_id.
Now, the source_realm's value will either be an integer or "" (empty
string) when we don't want to import settings from any realm.
Currently only enabled in development, since the exact details don't
seem right..
Co-Author-By: Signior-X <b19188@students.iitmandi.ac.in>
Co-Author-By: Aman Agrawal <amanagr@zulip.com>
Implements UI for #8005.
Replacing the group PMs icon with "fa fa-group" icon
drops the color class "fraction_present" logic. As there
is no more use of fraction_present class this commit
cleanups its all existence from the codebase.
As of now, editing a widget doesn't update the rendered content.
It's important to ensure that existing votes or options added later on
don't get deleted when rendered.
This seems more complex than it's worth.
For now, we just prevent edits to widgets.
This commit makes the UI clearer that editing widgets isn't allowed.
See also:
https://github.com/zulip/zulip/issues/14229https://github.com/zulip/zulip/issues/14799Fixes#17156
Currently, when there are some old starred messages
in a topic, it is possible that some of them won't be
unstarred on doing "Unstar all messages in topic".
This happens when those messages haven't been fetched
yet from the server, and we have no way to verify if
they actually belong to the topic.
This commit fixes that by changing this mechanism to
first fetch all starred messages in the topic from
the server, and then send their IDs back to the backend
to unstar them.
While doing this, we assume that the user does not
have more than 1000 starred messages in that topic.
Note that, we still depend on the local data to
decide whether or not the "Unstar all messages in
topic" option should be shown in the topic popover.
A method similar to the above cannot be used here, because
making server requests before opening the popover
could visually slow down the popover opening.
Using local data for the topic popover would probably
not be a big problem, because users would want to
unstar all messages in a topic probably after noticing
that there are a lot of them, meaning there was at least
one starred message from that topic which was already
fetched, which is sufficient for us to conclude that
we need to show the option in the topic popover.
Fixes#17790
The dialog now shows `stream > topic` instead of
just the topic.
This creates a new tiny widget for this purpose,
which can be reused in other places too.
The `undefined` case is probably very unlikely, but
if the `stream_id` is bad, after the user confirms,
the request will fail on the backend, which could
confuse the user, since there will be no changes to
the starred messages in view.
So, we don't open the confirmation dialog at all in
such cases.
There is no need to store this field (and make sure
that it's the same in both the message_list and
message_list_data objects) on message_list objects,
because we can anyways access it easily with
`message_list.data.excludes_muted_topics`, and storing
it just on the data object seems more intuitive.
This also simplifies the constructor for the `MessageList`
class.
We hide a conversation from the top-left corner PM list if
it is-
* A 1:1 PM where the other user has been muted, or
* Huddle where all users have been muted.
This commit adds code for live updating the role field of person
object on receiving role change event from server and thus enables
live update of role in users list of settings overlay.
This commit adds code to live update page_params.is_moderator and
person.is_moderator on receiving role change event.
The code for changing role to moderator and from moderator to any
other role was added in previous commit.
This commit modifies the code to show "Moderator" correctly for
realm moderators.
As, we show role using settings_config.user_role_values object and
the same is used for showing options in changing role dropdown, this
commit also adds the moderator option in that dropdown and thus allows
the user to change role to moderator and from moderator to any other
role from frontend.
But the code for live updating page_params.is_moderator and
person.is_moderator will be in further commit.
This commit adds 'admins and moderators' option in frontend for
invite_to_realm_policy.
The logic for moderator for checking whether user is allowed to invite
others or not was added in previous commit as we use common helper
user_has_permission for all policies.
But the test user_can_invite_others_to_relam is updated for including
moderator role in this commit.
Since, we now have role value in the person objects sent from server
we can directly use that to set the value of dropdown used for
changing user role, instead of using multiple if-else conditions
for checking is_admin, is_owner, etc.
Since, we now get role value in person objects sent from server, we
can simply user user_role_map to display role in different places
instead of having multiple if-else conditions to check flags like
is_admin, is_guest, etc.
There were some changes that were lost/added by mistake
during a rebase of #17707 after #18154 was merged.
Fixes the GIF icon being hidden / displayed incorrectly
with respect to the settings.
These changes were originally part of
67527a2517 but
were lost during the rebase.
This commit adds 'user_can_create_streams' helper which is
used to check whether user can create streams or not and
replaces all the instances of 'page_params.can_create_streams'.
This change helps us to remove the complex logic of updating
'page_params.can_create_streams' for 'realm_update' event in
'server_events_dispatch.js', as we will always get the updated
values from the added helper for checking whether the users can
create streams or not.
This commit adds 'user_can_subscribe_other_users' helper in
settings_data.js amd this helper will replaced all the
instances of page_params.can_subscribe_other_users.
We also remove the incorrect code in server_events_dispatch.js
where we were updating page_params.can_invite_to_stream which
is actually not used in other parts of code and instead of it
page_params.can_subscribe_other_users is used to check whether
user is allowed to subscribe others or not. This code was
added in 272ed9068.
Though this could have been done in a different commit, but as
we are adding the code to use the correct updated value in this
commit only, this has been fixed here.
There is also no need of adding that complex logic to update the
correct 'page_params.can_subscribe_other_users' field on
'realm_update' event, as we are using user_can_subscribe_other_users
helper and thus we always use the updated values to check whether
the user is allowed to subscribe others or not.
This commit adds 'user_can_invite_others_to_realm' function
in settings_data.js which replaces all the instances of
'page_params.can_invite_others_to_realm'.
This change makes it possible to remove the complex logic of
updating 'page_params.can_invite_others_to_realm' on
'realm_update' event as we are using above added helper instead
of using page_params object and thus we always use the updated
value to check whether user can invite others or not.
The 'user_has_permission' helper will be used by functions added
for create_stream_policy and invite_to_stream_policy in further
commits and will help in avoiding code duplication.
This commit replaces different objects - create_stream_policy_values,
invite_to_realm_policy_values and invite_to_stream_policy_values,
with a single object common_policy_values.
Though invite_to_realm_policy do not use other fields of objects like
description, order, etc. but we can keep it as it is for now as we
would separate this setting from "Are invitations required...."
dropdown and these fields will be used then.
This is a prep commit for commits that will add helper functions in
settings_data for these policies replacing the usage of page_params
object.
When notifications panel is open at the top, the buddy list and
streams-filter container gets truncated due to max-height exceeding
the necessary value. The commit fixes the issue by subtracting the
panels height when it is visible. The logic to do so is already
present, but we need to ensure that we trigger the full resize code
when we get into this situation.
Fixes: #18221Fixes: #17823
This prevents the regex from requiring multiple spaces between
adjacent alert words by using lookahead and lookbehind (rather than
the before/after checks each needing to eat a whitespace character) so
that consecutive alert words (if any) can be highlighted.
With a frontend test covering adjacent corner cases by tabbott.
Fixes#17320
setTimeout doesn't work all the time especially when trying to
hide and display the popover at once, like when you press
to open giphy popover in message edit form while another giphy
popover is open from the compose box.
MutationObserver works reliably, hence we choose to use it
instead.
In fe66aef0ad, this call to
blueslip.fatal was ported incorrectly to `throw new Error` despite the
latter not supporting the extra_data parameter.
We address this by just doing blueslip logging with the extra data first.
Fixes#18273.
This function requires two arguments; checking for the event being
undefined is code leftover from a previous implementation.
Fixes an issue reported in #18273.
For unknown reasons, 6f7b973d3b
introduced an invalid semi-duplicate call to ui_report.error that
passed the wrong number of parameters.
We should just call `ui_report.error`, which already had logic to
handle the distinction between 40x and 50x errors.
Fixes an issue reported in #18273.
Fixes#18052
When we select a draft with no stream, topic of
drafts gets disappeared. This commit fixes this bug.
In the restore_draft function of drafts.js, we were
explicitly removing the topic of the draft when the stream is
not set.
This was bit reluctant to me, like why we're removing
the topic when the stream is not set. After discussing this on
the Zulip organization chat, I came to know that all code for
drafts is added in commit 1929cc5190.
And as this is a big commit, this microcode would not have
gotten much scrutiny and might get missed.
So removing this feature is not an issue. Also, it may be a bad
design decision to delete topic when we restore drafts. So we should
remove this feature.
When we select a draft with no topic, we typically got navigated to an
empty narrow, because the topic field was empty. Rather than
navigating to a view that will show "Nothing's been sent here yet!",
we should not navigate at all.
Initially, in the restore_draft function of the drafts.js
we were only checking that stream is empty or not,
now we also check for the topic, and if both are set,
we navigate to related context; otherwise, we don't navigate.
Previously, we used to do a kind of "local echo"
whenever the user muted/unmuted a topic. Meaning,
we used to do most of the UI update work before making
the API call to mute the topic, instead of after
receiving the `muted_topics` event. This behavior
has been so since the beginning of time
(b4b6fa14d3) and isn't ideal because:
1. If the request fails on the backend, the UI
could end up in an incorrect state.
2. Adds code complexity.
3. Makes it difficult to catch bugs related to
live-update (like the one fixed by
f725711ff2).
4. Isn't consistent with other parts of the
codebase, which do the UI update while handling
events.
This commit makes it so that all the UI update
work is done only after recieving the `muted_topics`
event.
The only possible issue with this strategy could
be users sending another duplicate request in the small
time span before receiving the event. But that isn't
a big problem, because all requests involved here are
idempotent, and the worst that can happen is a HTTP 400.
This commit adds support for a `None` option in the dropdown menu
of `Notification sound`. When this option is selected, no audible
notification is sent to the user.
`None` will appear as the first option in the dropdown menu, since
this is not categorized as a playable audio.
This new option is added so that folks can disable audio notifications
without losing their other notification configuration (like for PMs, mentions).
Necessary test case is added for this new option.
Fixes#16090.
Item field is added to the pill items, this is done to utilize
it wherever possible, to distinguish between diffrent types
of pill items(stream|user_groups|users).
It is also a preparatory commit to support expanding of stream
and user group pills.
Deduplicate control buttons by re-using the
compose_control_buttons.
A link to `help` overlay was added to `message_edit_form`
as a part of this process.
This fixes a bug that when video provider is set to `Jitsi`
from `none` in organization settings while message_edit_form
is open, the video icon is not displayed since
it was not present in the message_edit_form DOM even if
compose.update_video_chat_button_display tries to display it.
It is fixed since the `.video_link` element is always present
in DOM of `message_edit_form` now.
We convert the following elements to use a class instead of
id for accessing them across the codebase:
* markdown_preview
* undo_markdown_preview
* markdown_preview_spinner
* message_edit_content
* preview_content
Converted them together since changes to one impacted the other in
some modules like click_handlers.
Also, added a function in rows to get `message_row`.
We use `.compose_upload_file` across compose and message_edit_form
for file upload icon. This will help us share common code between
`compose` and `message_edit_form`.
In both compose and `message_edit_form` we use `file_input`
class to identify the file `input` element. This will help
to more easily share common elements between compose and message_edit.
Since we can have multiple instances of `message_edit_form`, it
makes sense to have it as a class.
We track the message_edit_form by setting an id to
`form` element dependent on message_id.
This commit makes it so that muted users never appear
in the right sidebar buddy list, filter text or not.
The hiding is done in the frontend only, and we still
recieve presence data from the server as before, so
no extra work is required on unmuting someone, other
than to rerender the user list.
Long term if we find that there are too many muted users,
we may want to optimize how we send presence data, but
that is unlikely to happen.
The other less extreme option is to gray out muted users,
but that cannot be done because it would conflict
with the graying out we do for non-recipients when the
compose box is open.
This makes the naming more intuitive and gives us a
single place to add more conditions on filtering
user_ids, with the current motivation being filtering
muted users, the logic for which will be added in further
commits.
This is a direct code move which puts all the functions
related to `user_id` lists near the bottom of the file.
This will make the file slightly easier to read.
Long labels like "Yes, Unsubscribe this stream" can
be confusing for translators and it can also create bad
strings that can end with like 4 long words in German.
It is better to have the simple options like "Confirm"
and "Cancel". This commit fixes this issue by changing
the text to "Confirm".
Fixes#17926.
Previously, realm emojis can override default emojis in emoji-picker,
if the user sets an exisitng emoji name to his/her custom emoji.
For clear understanding--
If a user sets an realm emoji with name `smile`, this leads to the
newly realm emoji override the existing default emoji `smile`.
To address such behaviour, Added a warning modal which requires
the user confirmation before overriding the default emoji.
Fixes#16913.
Moved `admin_user_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Fixes#18227
Moved `admin_user_group_list` template to `/templates/settings/` folder
as earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Also modified the node tests to reflect the new changes.
Moved `admin_tab` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder instead.
Moved `admin_profile_field_list` template to `/templates/settings/` folder
as earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Also modified the node tests to reflect the new changes.
Moved `admin_linkifier_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Moved `admin_invites_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder instead.
Moved `admin_human_form` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Moved `admin_export_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Moved `admin_emoji_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Moved `admin_default_stream_list` template to `/templates/settings/`
folder as earlier, it was inaccurately placed within the `/templates`
folder and should have been within the `/templates/settings` folder
instead.
Moved `admin_bot_form` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and `settings` folder is specifically for storing administrative
UI templates.
This involves in two changes for styling.
1. The alert class is moved from alert.css to app_components.css as this
class serves nothing but to default .alert elements to be hidden. This
is only required in the webapp but not portico pages (where .alert
elements are preferred to be shown by default).
2. The import statement for alert.css is moved from app.js to common.js,
so that both the webapp and the portico pages can share the styles. This
will be fine to share the styles as .alert-display, .alert-animations,
.alert-box are more specific then .alert and they use nested class to
define styles for inner elements.
Undoes #17936 properly.
Ganesh Pawar
aryanshridhar
Gaurav Pandey
Riken Shah
sahil839
m-e-l-u-h-a-n
Tim Abbott
Priyank Patel
Vishnu KS
akshatdalton
Anders Kaseorg
Aman Agrawal
Sumanth V Rao
Steve Howell
rht
Abhijeet Prasad Bodas
PIG208
Ryan Rehman
Signior-X
Ken Clary
Siddharth Asthana
pilgrim2308
Nikhil Maske
im-adithya
100RABHpy
Nyior
nikhilmaske-2001