If notifications_stream is private and the current user has never been
subscribed, then we would throw an exception when trying to look up
notifications_stream. In this situation, we should just treat it like
the stream doesn't exist for the purposes of this user.
This is purely to make it easier to read narrow.activate()
without having to page past lots of unnecessary detail when
you're trying to understand things like how we set the
selection.
The maybe_select_closest helper, when first introduced, was
tiny and close to its callers.
As it's grown, it's become kind of a big hurdle to reading
narrow.activate(), because it's out of chronological order
and it's hard to tell at a glance which variables it's closing
on.
Now we just move it out to module scope.
It's mostly moving code, with these minor changes:
* we pass in opts for the old closure vars
* we rename then_select_offset -> select_offset
* we early-exit on empty lists
We replace these variables in narrow.activate:
then_select_id (int w/-1 as a sentinel)
select_first_unread (boolean)
The main goal here is to get away from the boolean, since
we are about to introduce a third select strategy.
The new var is select_strategy and it has a union
type with these flavors:
"exact" (was select_first_unread === false)
"first_unread" (was select_first_unread === true)
The new flavor will be something like "last_id".
Eliminating then_select_id is also nice, since the -1
sentinel value could be a pitfall, and it's semantically
cleaner to encapsulate behind a check for
select_strategy.flavor.
We use an IIFE (immediately invoked function expression)
to fetch messages. This will allow us to introduce some
local vars in a subsequent commit without creating an ugly
diff and without cluttering an already crowded namespace.
This cleans up a subsequent diff. Within the context of
`maybe_select_closest`, there's only one `msg_id` we care about,
so the more convoluted name `then_select_id` makes much less
sense than it does in the enclosing scope, and it will make
even less sense after some future changes.
There's also some cosmetic cleanup here.
When we are deciding whether to preserve scroll position, we
mainly care that then_select_offset is set to a value. If
we had no intention of preserving scroll offset, we would have
never bothered to set it. The check for !select_first_unread
is always redundant, as verified by lots of clicking around
with some print debugging. And it's a brittle check,
because it couples the decision of scrolling destination to
the mechanism by which we decide our selection. While those
things are closely related, it's possible in the future that
we'll decide to advance to an unread message and still want
to set then_select_offset, but we might forget to mutate
select_first_unread.
Long story short, the code is simpler and safer now.
We move the var declaration of then_select_offset closer to
where it gets calculated, and we avoid code duplication in
calling current_msg_list.get_row().
Even when then_select_id has the sentinel value of -1, we were
trying to look it up in our message_list.all object. This would
have returned undefined, which is fine, but it's more explicit
to just bypass the check.
This mostly sets up the next commit. The two conditions here
are both inexpensive to check, but we want to bypass an upcoming
expensive operation if can_apply_locally() returns false.
With past logic, on fast upload progress bar don't appears because
uploadFinished is called as soon as upload is finished so
progress bar get disappeared. To make these hiding of progress bar
smooth we set setTimeout for every hiding of progress bar as well
as complete status element.
Here `file.lastModified` is unique for each upload so it is used
to track each upload individually.
Also, we have used `uploadStarted` function because it is
called for each file during an upload.
Fixes: #9068.
Previous logic was little buggy, as many time there can be considerable
difference between uploadFinished and progressUpdated as progressUpdated
can finish much earlier(on a slow connection) and the "uploaded file"
markdown text is inserted with some delay.
It is also a preliminary commit for making each progress bar independent
as currently progressUpdated may close upload_bar even after only
one file out of many files is uploaded.
This takes advantage of the new function narrow_state.stream_id().
We now assume the incoming stream_id is a valid stream_id, so we
no longer need to test some of the error checking. (It's possible that
the incoming stream_id may no longer be for a stream you subscribe
to, but the nice benefit of working more in "id space" is that if
it doesn't match the narrow's stream id, we know false is a safe
return value.)
After adding a newly created stream to the top of the stream list,
call to actually_filter_streams in stream_events.mark_subscribed
rerendered the filter_table and the stream list was refreshed. The
call to actually_filter streams was introduced to rerender the
subscriber list but stream_edit.rerender_subscribers_list takes care
of it already.
Fixes#9033.
Currently when admin add/remove/update custom fields, changes
are not reflected in user settings page, if settings tab
is already open. This might be rare case, but it looks like
an error when admin go to user settings page just after
updating custom fields in org settings.
Fix this by re-rendering custom fields in user settings
on custom_profile_fields event.
In a refactor last fall, we changed `set_message_booleans` to mutate
state (specifically, destroying msg.flags in favor of setting
properties like `msg.unread`). This was fine for most code paths, but
the maybe_add_narrowed_messages code path called
`message_store.add_message_metadata` twice (once after talking to the
server to find out whether the messages go into the current narrow),
and so when we extracted set_message_booleans from that, the second
call didn't properly short-circuit.
We fix this by just removing the second call, and also add a comment
warning about the add_message_metadata call there as being dangerous.
Fixes#8184.
Instead of treating false differently from undefined, our
function is now a regular boolean function, and we limit our
code comments to the one corner case where the true/false
decision is kind of arbitrary and possibly confusing.
The buddy list never includes yourself nor bots, so we
remove the special case handling for those situations.
If we were to put bots or the current user back in the list,
I'm not convinced the old logic was what we'd want in either
case going forward.
For example, we might want to fade bots that aren't subscribed
to public streams, since they might otherwise confuse people,
but then again they would receive messages. And then "yourself"
is a recipient in the technical sense but they're kinda
not and either way it doesn't provide much signal either way.
We don't need to special-case the stream cog handler when we
handle the click event for the surrounding header. The browser
will fire the event for the cog first, which stops propagation.
The new list_cursor class is more generic and saves the state
of your cursor across redraws.
Note that we no longer cycle from bottom to top or vice versa.
The node test code that was removed here was kind of complex
and didn't actually assert useful things after calling methods.
When we populate the buddy list or update it for activity, we now
have buddy_data set a faded flag that is rendered in the template.
This avoids some re-rendering overhead and is on the eventual path
to having our widget be more data-oriented (and all rendering happens
"behind" the widget).
We still do direct DOM updates when the compose state changes or
when we get peer subscription events.
This introduces a generic class called list_cursor to handle the
main details of navigating the buddy list and wires it into
activity.js. It replaces some fairly complicated code that
was coupled to stream_list and used lots of jQuery.
The new code interacts with the buddy_list API instead of jQuery
directly. It also persists the key across redraws, so we don't
lose our place when a focus ping happens or we type more characters.
Note that we no longer cycle to the top when we hit the bottom, or
vice versa. Cycling can be kind of an anti-feature when you want to
just lay on the arrow keys until they hit the end.
The changes to stream_list.js here do not affect the left sidebar;
they only remove code that was used for the right sidebar.
The blur_search() function was removed in this commit:
See da06832837
We now no longer attempt to call it. It's not completely clear
to me what this did before, but we are rewriting a lot of the
keyboard navigation for search anyway.
In this cleanup I make it so that all jQuery selector references
are toward the top of the module, and we do all finds relative
to the container ('#user_presences').
This will make it easier to make a better list abstraction for
the buddy list, for things like progressive rendering.
This was a bit more than moving code. I extracted the
following things:
$widget (and three helper methods)
$input
text()
empty()
expand_column
close_widget
activity.clear_highlight
There was a minor bug before this commit, where we were inconsistent
about trimming spaces. The introduction of text() and empty() should
prevent bugs where users type the space bar into search.
A recent change filtered out offline users from the buddy list
whenever the list size would otherwise exceed 600.
This commit reverts half that change--we can now show 600+ users
again, but only when searching.
This is because we cover the case of `realm_allow_message_editing` by
`realm_msg_edit_limit_setting` after the conversion into dropdown.
This commit also contains a minor variable renaming.
Add realm setting to set time limit for message deleitng.
Set default value of message_content_delete_limit_seconds
to 600 seconds(10 min).
Thanks to Shubham Dhama for rebasing and reworking this. Some final
edits also done by Tim Abbott.
Fixes#7344.
This fixes an issue where with very tall messages (more than about a
screen in height), one would end up scrolled to the bottom of the
message if you clicked on it, which usually felt annoying.
Fixes#8941.
Previously, we did a rerender without first re-computing which
messages were muted; this was incorrect, because whether a message is
muted can change if the topic changes.
Fixes#9241.
This was only called from two places in one function, and we can just
check muting_enabled in the caller.
This refactor is important, because we might need to update muting
after other changes (specifically, message editing to move a topic to
be muted/non-muted).
This is a slight change in the responsive design, moving the 975px
cutoff to 1025px; the main effect is that for windows that just barely
had a right sidebar, we now hide the ride sidebar. This is pretty
beneficial for the user experience specifically in the common size of
1024px, where that sidebar was making things feel a bit too
constrained.
This function replaces part of compose_fade.would_receive_message(),
which has a real janky interface of returning true, false, or
undefined.
We don't need to couple the semantics of compose fading to whether
we help subscribe a mentioned user. They're mostly similar, but they
will probably diverge for things like bots, and the coupling makes
it difficult to do email -> user_id conversions.
One thing that changes here is that we get the stream name from
compose_state, instead of compose_fade.focused_recipient. The
compose_fade code uses focused_recipient for kind of complicated
reasons that don't concern us here.
This coverts the "checkbox" for `realm_allow_message_editing` and
"input" for `realm_message_content_edit_limit_seconds` into a
dropdown with the option for custom time limit option.
If the browser is in the progress of reloading when it finishes
fetching some messages, it's not really a bug, and we shouldn't report
it as such.
This should help make Zulip's browser error reporting less spammy.
If you visit a narrow that has unread messages on it that aren't part
of the home view (e.g. in a muted stream), then we were never calling
`message_util.do_unread_count_updates`, and more importantly,
`unread.process_loaded_messages` on those messages. As a result, they
would be unread, and moving the cursor over them would never mark
those messages as read (which was visible through the little green
marker never disappearing).
I can't tell whether this fixes#8042 and/or #8236; neither of them
exactly fits the description of this issue unless the PM threads in
question were muted or something, but this does feel related.
We consistently either pass a `then_select_id` into narrow.activate,
or were using the select_first_unread option. Now, we just compute
select_first_unread based on the value of then_select_id.
In the very early days of Zulip, we didn't have unread counts; just
the pointer, and the correct behavior when opening a new tab was to
place you near the pointer. That doesn't make any sense now that we
do have unread counts, and this corner case has been a wart for a long
time.
This commit does the main behavior change here. However, there's a
bug we need to fix, where we might end up trying to pre-render a view
of the narrow based on the `all_msg_list` data before `all_msg_list`
is caught up). We need to fix that bug before we can merge this; it
should be possible to determine that using `FetchStatus` on
`all_msg_list`, or with better performance by using the `unread_msgs`
structure to determine whether the message we should be selecting is
present locally.
Fixes#789.
Fixes#9070.
Apparently, we were incorrectly passing through something related to
opts.use_initial_narrow_pointer as the value for `use_first_anchor`.
If you read the logic in narrow.js carefully,
use_initial_narrow_pointer was unconditionally false.
The correct value for this attribute is when we're trying to narrow to
the first unread message in a given context. There are two things to
check:
* then_select_id is -1; i.e. we don't have a specific message ID we're
trying to narrow around.
* select_first_unread is True, i.e. we're trying to narrow to the
first unread message.
A bit more work should allow us to get rid of the second condition,
but I'm not quite confident enough to do that yet.
This prevents us from using const in our JS code, with exceptions
for test code and the portico. Hopefully this is just a temporary
rule until we make our pipelines with work with ES6.
I tried to prevent "let", but that was too noisy.
This adjusts the one false-negative case of using const in a comment.
This change makes a common code path for these two operations:
* clicking on a user
* hitting enter when a user is highlighted
The newer codepath, for the enter key, had some differences that
were just confusing. For example, there's no need to open the
compose box, since that's already handled by the narrowing code.
For possibly dubious reasons, I let each handler still call
popovers.hide_all() on its own, since it makes the code a bit
more consistent with existing code patterns.
If we would have more than 600 people in a buddy list, it's kind of
cumbersome to scroll through it, and it's also expensive to render
it (short of doing progressive rendering, which adds a lot of
complexity).
So, as a short term measure, we filter out offline users whenever the
list would exceed 600 users. Note that if you are doing a search that
narrows to fewer 600 users, the offline users will appear again.
We now have components.toggle simply return an object, without
putting the object into a lookup table. The consumers of the
objects have all been changed to just store the object in their
own module scope.
The diff is a bit hard to read here, but it's mostly de-denting
code and removing these things:
- we don't have opts.name
- we don't have __toggle.lookup
- we don't have keys
- we don't create a sibling object to the prototype object
In this commit:
Two new URLs are added, to make all realms accessible for server
admins. One is for the stats page itself and another for getting
chart data i.e. chart data API requests.
For the above two new URLs corresponding two view functions are
added.
We used uploadStarted for drop callback which is kind of confusing
for new contributors as there is a big difference between uploadStarted
and drop like uploadStarted is called for each file in an upload whereas
the drop is called once when the file(s) are uploaded.
This commit introduces a helper function called
maybe_select_tab() that goes to the correct tab in the
toggler widget.
It avoids the "lookup" mechanism, which I am hoping to
deprecate, and it handles hypothetical startup issues
by warning instead of crashing.
Before this commit, this sequence would lead to errors:
* Open streams page via the gear menu.
* Go to "All" tab.
* Leave streams settings.
* Re-open stream settings via the gear menu.
After doing this, the tab would show "Subscribed" but the list
would be of all messages.
Now we explicitly goto the first tab.
I added a long comment explaining how subs.js contributed
to this bug--in short, we re-build the widget instead of just
re-opening this.
We may also want the toggle component to simply default the
initial tab to the first tab.
We now make sure our toggler exists before invoking its `goto`
method. Usually a toggler exists pretty early during app
startup, but _setup_info_overlay is wrapped in i18n.ensure_i18n,
which asynchronously fetches translation data.
This commit also simplifies how we find the toggler, by just
storing it in the module where it gets created and consumed.
Fixes#9085.
If you started composing a message to a topic, and then the topic was
edited, we would update the compose box and message list state, but we
didn't correctly update the fade state after updating your compose box
(and the message list), resulting in the messages being incorrectly
faded.
The refactor in 12509515ae had a subtle
bug, which is that we switched from accessing the message list "this"
(aka the message list being rerendered) to current_msg_list. This
meant that when the narrowed_msg_list was in view and code needed to
modify home_msg_list, we accessed the wrong `selected_row` to preserve
the scroll position of (namely, the one in current_msg_list, not the
one in home_msg_list).
Fix this, by moving the function to be a property of the
message_list_view object, which makes more sense structurally, anyway.
We may, in the future, want to do a similar migration for more of
message_viewport.js.
Fixes#8854.
If muting, topic editing, or deletion causes a narrow loses its last
message, we should show the empty-narrow notice; similarly, if
un-muting adds the first message, we should hide the notice.
We do this in `rerender()` since that's the common code path for
re-rendering the message list after events that might change this.
This has likely been broken since the very first muting
and topic editing implementations.
This commit exposes some inner variables of notifications.js to make
them easily testable. The first test added simply checks whether the
showing and closing of notifications works properly, and doesn't yet
verify the main code logic of the notification generation.
In 7b8da9b we have introduced some other checkmark icons
which aren't necessary as old icons still make sense there.
So removing them as they don't add any extra value.
Fixes: #8995.
Zulip's search typeahead had a security bug, where when autocompleting
a specially crafted stream name, and then hitting space, code within
the stream name would be executed.
Zulip was doing HTML escaping correctly in the main code path using
Filter.describe to describe a narrow, but the escaping function was
not called in a few parallel code paths. We fix this in a way that
should protect all of these code paths, by making Filter.describe
return properly escaped HTML, rather than depending on its callers to
do so.
Thanks to w2w for reporting this issue.
This fixes a set of XSS issues with Zulip's frontend markdown
processor, which is used in a limited set of contexts, such as local
echo of messages and the drafts feature.
The implementation of several syntax elements, including the <em>
syntax, user and stream mentions, and some others failed to properly
escape the content inside the syntax.
Fix this, and add tests for each corrected code path.
Thanks to w2w for reporting this issue.
This fixes an XSS issue with Zulip's muting UI, where if a stream or
topic name contained malicious HTML containing JavaScript, and the
user did a muting interaction, the malicious JavaScript could run when
rendering the "you just muted a topic" notification.
We did an audit for similarly problematic use of `.html`, and found
none; for the next release we'll be merging a series of changes to our
linter to prevent future instances of this being added.
Thanks to Suhas Sunil Gaikwad for reporting this issue.
There was already a progress bar set up, but it became non-functional
after refactoring. This fixes it.
The default animation was getting cut off when `uploadFinished` is
called, so we add a delay before removing the upload bar to make it
get to the end.
Tweaked by tabbott to have a more natural feeling animation setup
(where we don't animate the width adjustments; just the disappearance
of the bar).
Fixes#8863.
This reverts commit 6e048c5d3f.
See #8963 for the main issue we need to fix before re-enabling this;
basically, some combination of toMarkdown and the way text/html gets
written was introducing a lot of bonus/bogus whitespace, both in the
form of newlines and spaces converted to ` `.
`@everone` and `@all` will have a megaphone icon from FontAwesome in
place of the avatar.
Also, fix the `composebox_typeahead` tests to account for the images.
Fix#6635.
Currently, stream subscriptions aren't getting updated without
hard reload when user is deactivated in realm.
Fix this issue by updating stream subscription widgets on user
deactivation event.
Fixes#5623
This commit adds a new helper func to check if sub settings tab
is active or not and remove function `add_me_to_member_list`
function from `static/js/stream_edit.js`, cause we don't need to
render subscribers for particular case, as we are already doing that.
Currently, even after unsubscribing from private/public stream
email address of stream is still present in html widgets hidden.
Cause we don't clear email address on unsubscription event.
This clears email address from widget when user unsubscribe
from any stream.
Introduced a new checkmark icon in the settings page
from entypo ( www.entypo.com ) to make icons more
consistent between user and organization settings.
This commit changes the way the save and discard buttons on the
organization profile, settings and permissions tabs look and fades
them out after a delay. It also cleans up the code a bit in the
settings_org.js file. It introduces changes to the css in
settings.css as well as the template for save-discard buttons.
It also fixes a bug on the user settings whereby if an option
that requires reload is clicked before clicking an option that does
not require reload, the reload message is erased. This could create
an issue where the user is not aware that a reload is required.
The loader is also changed to using fa-icon as loading spinner on
user settings and the colors are tweaked a little bit.
This commit adds the ability to pass the sticky option to
in the change_display_setting function in order to have the
feedback element remain visible instead of fading out which
is the default behavior. Also passes true for that option in
two instances on the page.
This commit changes the do_settings_change function so that it
defaults to showing the loading spinner for 500ms before fading
out the the feedback element. It also adds a sticky option so you
can override the fading out of the feedback element and have it
remain visible.
This tweak to our compose on-topic-narrow logic may help make it a bit
easier to do quick replies without needing to re-open compose. I'm
not 100% confident this actually makes Zulip better, but it's worth
testing and getting some feedback.
Fixes#6473.
For a non-empty compose box, we previously considered closing the
compose box when switching topic narrows with content in the compose
box; now we leave it open unconditionally.
Part of #6473.
Fixes#8965.
Mark_message(s)_as_read is used in marking a message as having been
read by the browser, rename it to notify_server_message(s)_read to
avoid any confusion.
We've had a longstanding bug where the streams settings code
was getting an i18n'ed value in the middle of a callback from
the toggle component, so it would have been broken for
non-English sites. And then a recent cleanup of the toggle
code introduced a bug where the callback-in-the-callback was
getting stale state, so English sites broke too.
This fix just simplifies everything by using the key that
comes into our callback to determine whether we filter or not.
Fixes#8945
This is a recent regression where we I refactored the toggle
component. For some reason the old code was waiting until
after the callback to set some of its state, and I did the
same thing when I simplified how the state was stored.
Under the old code, this didn't manifest as a bug, although
the old code was problematic for other reasons.
This "fix" doesn't actually change anything user facing, as the
follow up commit fixes the proximal problem more directly. And
the toggle component is still prone to people writing code that
tries to inspect the state of the widget as it's being built.
For info overlays (keyboard/markdown/search help) we now let
the modal portions of the widget have focus, so that you can
page around. And then tab switching still works with the arrow
keys.
This is a pretty thin abstraction to prevent having to put
magic numbers in code, doing the which/keyCode hack, and remembering
to all preventDefault.
Hopefully we'll expand it to handle things like shift/alt keys
for components that want their own keyboard handlers (vs. going
through hotkey.js).
Currently, long textual fields are rendered as short textual fields
in UI, this bug was introduced because of our recent changes in
custom fields type.
It removes code related to custom profile field's placeholder styling
and related to numeric custom fields, as recently we removed support
for numeric custom fields.
This commit adds support for '+' and 'Z' for "zoom in" and '-' and 'z'
for "zoom out" shortcut keys in the lightbox image viewer for Pan and
Zoom.
Fixes: #8689.
Apparently, since 1948cb6a89, we've been
sending requests by an administrator to change a user's name to the
/json/bots endpoint, which would end up changing the "bot owner" of
these objects to some random user.
We fix this by re-splitting the views code.
Fixes#8853.
In certain cases, the browser is not able to look up the message.
Include the recipient data for the message in the delete_message event,
so look up of those attributes by the browser isn't required.
Replace mark_message_as_read with process_read_messages_event as the
latter function is only correct for marking a message as having been
read by this browser.
Tim Abbott
Steve Howell
Aditya Bansal
LuisFSilva
Shubham Dhama
gooca
Angelika Serwa
Shubham Padia
Yashashvi Dave
Akash Nimare
Vishnu Ks
Umair Khan
Sampriti Panda
Utkarsh Patil
Greg Price
Cynthia Lin
Aastha Gupta
Rohitt Vashishtha
Marco Burstein
Balaji2198
Armaan Ahluwalia
Armaan Ahluwalia
Tarun Kumar
Priyank
Abhigyan Khaund
Anurag Sharma