If we find unread messages for a sender, we will
try to render locally narrow for sender searches.
Note that our current implementation brute forces
through all the unread ids. We can improve this,
although it's not really a bottleneck until we
also support buckets for general filtering.
We now try harder to find the first unread message in an
upcoming narrow, which has the user-visible effect that we
select the unread message before waiting for search results.
Before this change, we only applied this logic to searches
that were things like exactly stream/topic or exactly is-private.
Now we will also handle things like stream/topic/sender. For
the stream/topic piece we look up candidate unread ids using
the steam/topic buckets in unread.js, but then we still filter
those messages by stream/topic/sender as we look for the first
unread id.
I renamed get_unread_ids() to _possible_unread_message_ids().
The name is deliberately verbose, since we're about
to make it have kind of unusual semantics that only make sense
for its one caller.
The outside code will continue to call get_first_unread_info().
In the tests I wrap this function in a wrapper with the more
pleasant name of "candidate_ids", since in the test there's
less worry about unwittingly exposing a kind of janky function.
We will use this to find the first id from a list of
message ids that matches a filter. (This will help us
during narrowing to determine whether we have at least
one good message locally, so that we can render something
useful before waiting for the server.)
This new API replaces some more specific functions that were
only recently introduced:
is_stream_only
is_stream_topic_only
is_pm_with_only
is_for_only
We use the deterministically sorted "term_type" values for
matching. (Notably "stream" will come before "topic".)
The "Short/Long Text" option for custom profile fields wasn't properly
capitalized (i.e. "Text" should have been all lowercase), and also
wasn't properly tagged for translation.
For the sake of consistency, the change to proper capitalization has
also been applied to the models and any tests involving this feature.
Due to a bug in Django, it complained about the models having changed
and thus not being consistent with the migrations. That isn't actually
true (since the database stores the numeric values for each key), but
the migrations have been modified to avoid this error. This does not
affect the migrations' behaviour in any way.
This should help prevent problems with folks introducing new code that
doesn't match our whitespace style.
There's a couple things I don't like about this configuration:
* How it handles multi-line JS lists (i.e. the [] syntax)
* That we ended up having to turn off indentation on a half-dozen
files that apparently don't use our standard IIFE indentation style.
* That we have it completely turned off for the node tests; ideally,
we'd just have slightly different rules around the IIFE identation story.
But otherwise, this works pretty well, and should catch a pretty wide
range of indentation regressions.
This works for other text boxes as well, but compose is the main one
that one would want to do a search from.
It's possible we'll find after doing this that "getting back into
compose" becomes a problem, but I guess we can handle that when the
time comes.
This makes a few important cleanup changes:
* Using the more standard data-field-id name for the ID value.
* Using $(e.target).closest() rather than `.parent`, which is more
robust to future changes in markup.
Most of this was straightforward.
Most functions that were grabbed verbatim and whole from
the original class still have one-line wrappers.
Many functions are just-the-data versions of functions that
remain in MessageList: see add, append, prepend, remove as
examples. In a typical pattern the MessageList code becomes
super simple:
prepend: function MessageList_prepend(messages) {
var viewable_messages = this.data.prepend(messages);
this.view.prepend(viewable_messages);
},
Two large functions had some minor surgery:
triage_messages =
top half of add_messages +
API to pass three lists back
change_message_id =
original version +
two simple callbacks to list
For the function update_muting_and_rerender(), we continue
to early-exit if this.muting_enabled is false, and we copied
that same defensive check to the new function
named update_items_for_muting(), even though it's technically
hidden from that codepath by the caller.
Even though starred messages are never unread, it's useful
for us to have helper functions for them.
This change makes it so that clicking on "Starred Messages"
takes you to the last read message immediately, without a
server delay.
This fixes some minor glitches with buttons:
* Movement of the organization-settings-parent block on the
appearance of widgets.
* Large and odd look of save button.
* Use of fadeIn and fadeOut rather than changing opacity as
opacity don't actually remove them.
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.
The original version of this function was simulating kind
of an illogical code path, where -1 was sort of pointing to
a real message, which doesn't make sense.
Now we pass in an explicit then_select_id.
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.
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.
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 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.
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.
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 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.
I have no idea why this started failing just now, but the test was
written without a proper wait in between actions, and fixing that
fixes the failure I'd been seeing.
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.
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 does a few things:
* removes some unnecessary setup
* puts some jQuery setup closer to where it's needed
* renames some variables
* adds an assertion about highlighting
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
There was really no reason for this to be a nested function, since
we weren't closing on any variables. Flatter is better. Also, it
is plausible that folks will want more control over creating
individual jQuery elements (but still want this helper).
I don't think anybody ever really used this feature, which I
developed but don't even use myself. It kind of runs counter
to the minimalist approach of the rest of node tests.
I would eventually like to re-think the template tests altogether.
They're slow, and we could solve that somewhat by replacing
jsdon/jquery with an HTML parser library to verify structural
things.
It's also possible that we can just rely on our template linters
to catch the biggest class of errors (malformed tags) and let
code review do the rest.
And it's also possible that we should make a second attempt to
ramp up tooling on making it easy to verify templates, but it
doesn't have to be part of the node tests. If we did that, we
would also potentially use tooling for Python-side templates.
This node test module is intended as a way for somebody to
quickly immerse themselves in our node testing methodologies,
plus it has the nice side effect of introducing several modules
(albeit very briefly).
A few things here:
* Use _.each to follow our convention.
* Just use new locals to avoid overwriting template and
avoid strange Object.assign hack.
* Just use simple string concatenation.
* Use better var names: full_name, shortcut
* Use chaining syntax.
This rule checks for use of const wherever needed, currently does
nothing since we don't use `let`, instead we use `var`. This rule
can be used to use refactor a file to use const easily by replaceing
var with let using a editor and then by running
`./node_modules/.bin/eslint frontend_tests --fix --cache`. And then revert
those `let`'s back to `var`.
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.
Steve Howell
Tim Abbott
Yago González
Aastha Gupta
Yashashvi Dave
Rohitt Vashishtha
Shubham Dhama
Aditya Bansal
LuisFSilva
Shubham Padia
Umair Khan
Sampriti Panda
Vishnu Ks
Priyank Patel
Utkarsh Patil
Preston Hansen
Tarun Kumar
Joshua Pan
Cynthia Lin