This function was extracted from build_user_sidebar(). We
also slightly streamlined it to not unnecessarily call
filter() when the filter text was blank. This extraction
also eliminated the need for us to have the two-line
filter_and_sort() function.
Also, we get to 100% coverage in this commit.
We now intialize user-list-filter within activity.initialize(),
which gives us more control to set the module variable
`meta.$user_list_filter` before we build the user sidebar,
while setting up its handlers after we build the sidebar.
This will look through all users and not just ones active in the last
three weeks but only when you are searching with the right sidebar
input box.
Fixes: #5775.
The sidebar selectors may not exist at a particular point on load but
we’d like to realistically cache the results once they are, so we try
to load them live until we know that a valid selector has been found.
This call to update the users scrollbar is inside a huddles update
method which should only affect the group PMs, so we can remove the
update function.
The `exports.build_user_sidebar` method already calls the resize
function, so there’s no need to call it again or wrap it in the
`actually_update_users_for_search` method.
This adds the perfectScrollbar to the right side and theoretically
updates it any time a piece of code interacts with the sidebar and
updates the counts of users displayed in it.
This function no longer sets properties to false, so the supported
way of doing this is to instead use prop(foo, false). Some tests
had to be fixed to accommodate this.
This commit de-couples the PM code from Group code. It also
simplified some code related to finding parent elements by
both introducing local variables and removing unnecessary
selectors.
This is the first part of handling an annoying race that would cause
us to try drawing the right sidebar using (in part) users that we
haven't learned about yet (because we were offline/suspended when they
were created, and we haven't quite realized our event queue is gone yet).
The web app doesn't need any presence data for its first ping to
the server, because it already has up-to-date presence info in
page_params. So now we can tell the server not to send us a big
payload that we were already ignoring.
Most of this code was simply moved from activity.js with some
minor renaming of functions like set_presence_info -> set_info.
Some functions were slightly nontrivial extractions:
is_not_offline:
came from activity.huddle_fraction_present
get_status/get_mobile:
simple getters
set_user_status:
partial extraction from activity.set_user_status
last_active_date:
pulled out of admin.js code
We also fixed activity.filter_and_sort to take user_ids.
This was regressed in 89e17e1aee.
At least one of the symptoms was that we weren't updating the
activity list properly. This could also cause tracebacks in
compose fade logic.
We now correctly pass the list item for a user to the function
compose_fade.update_one_row().
This regression started happening in the recent commit of
eece725073. Before that commit,
compose-fade was broken in a different way.
Testing this fix requires creating a stream and opening the compose
box in one window. Then, in the other window, have a user not
subscribed to the stream log on for the first time. Be careful
to make sure you flip back to the other browser tab quickly, and
you should see the new user grayed out. (You can get a false
positive if you wait too long, because the periodic update was
correctly fading before this fix.)
Introducing the level function makes it a bit more clear that active
users get sorted to the top.
It also shaves a couple milliseconds for large buddy lists, although
that is mostly negligible compared to name sorting and rendering.
It's easier to reason about the activity.js code if we just
make it clear that presence_info is a global singleton. Going
forward, functions that use that data will explicitly refer to
exports.presence_info.
This change makes some tests slightly more awkward to set up, but
with the actual code you now don't have to question whether there
are multiple copies of presence_info to maintain.
The diff for compare_function is a bit confusing to read, but it's
basically just de-dented since we don't need to parameterize the
compare function any more.
The function focus_lost() was setting has_focus to false
in all cases; now it does it more clearly. I also added a
comment explaining why we don't ping on losing focus.
We no longer build the buddy list twice during page load; we
build it just once from page_params information. (We also send
the initial ping and schedule subsequent pings slightly later in
the process.)
We also don't do redraws upon regaining focus, since we don't
show ourselves in the buddy list, and even if we did, we wouldn't
need a full server update.
To have this flexibility, we introduce the want_redraw flag to
focus_ping.
A clear-search option to clear the user-list searchbox has been added.
This feature was present in the main searchbar but absent elsewhere.
Fix a part of #3716.
We now call activity.build_user_sidebar when we initialize
the user sidebar, which avoids some janky jQuery code
that was intended for partial updates.
With 2000 users in dev, the amount of time to build the sidebar
decreases from 1100ms to 700ms in my tests. (Times vary a bit,
but it does seem consistently faster now.)
Activity.update_users() is still used to handle partial
updates of users in the buddy list, but now all the places
that want to re-build the whole widget go through
build_user_sidebar().
The function people.filter_by_search_terms() used
to return a JS object with emails as keys to represent
a set of users. Now we return a Zulip Dict() object
with user_ids as keys.
For the "GROUP PMs" part of the right sidebar, we now have
accurate hrefs when you hover over the groups or right-click
to copy links or open links in new tabs.
The slugs for PM-with narrows now have user ids in them, so they
are more resilient to email changes, and they have less escaping
characters and are generally prettier.
Examples:
narrow/pm-with/3-cordelia
narrow/pm-with/3,5-group
The part of the URL that is actionable is the comma-delimited
list of one or more userids.
When we decode the slugs, we only use the part before the dash; the
stuff after the dash is just for humans. If we don't see a number
before the dash, we fall back to the old decoding (which should only
matter during a transition period where folks may have old links).
For group PMS, we always say "group" after the dash. For single PMs,
we use the person's email userid, since it's usually fairly concise
and not noisy for a URL. We may tinker with this later.
Basically, the heart of this change is these two new methods:
people.emails_to_slug
people.slug_to_emails
And then we unify the encode codepath as follows:
narrow.pm_with_uri ->
hashchange.operators_to_hash ->
hashchange.encode_operand ->
people.emails_to_slug
The decode path didn't really require much modication in this commit,
other than to have hashchange.decode_operand call people.slug_to_emails
for the pm-with case.
When somebody changes their name, we will now update
the buddy list right away. The old code was trying
to do this through a code path that was designed for
true presence updates, but it was also passing in an
empty array, instead of undefined, which caused it to
fail to invoke the intended part of the codepath to
redraw the buddy list.
Now we just call the new activity.redraw() function,
which does the right thing for the buddy list.
The group PM list was live-updating before this change,
and it continues to live-update as part of the new
activity.redraw() function.
We now sort users by the lower case value of their
full names in each of the links in the "GROUP PMs"
section of the right sidebar. We still use "+n others"
for big huddles.
When we filtered buddy lists, a recent change introduced some
bugs related to case-insensitive emails. We now circumvent the
bug by indexing presence_info with user_ids.
We now use comma-delimited lists of user_ids for the following
data structures in unread.js:
- unread_privates[<user_ids_string>]
- get_counts.pm_count[<user_ids_string>]
It used to be the case that you would get new messages for a
huddle, but the huddle wouldn't show up on your buddy list until
the every-50-seconds mass update of the buddy list.
Now we make sure to work with non-stale jQuery objects, and,
more importantly, we resize ourselves if we add new huddles.
(The resize issue arises due to some complicated heuristics
where we don't want group PMs to take up too much of the buddy
list for users who don't have many in their history.)
Previously, we were checking if a particular user was the current user
in dozens of places in the codebase, and correct case-insensitive
checks were not used consistently, leading to bugs like #502.
Previously, the user list would remain filtered after a user hit enter
to start composing a message to a user, leaving them in a state with a
partial user list.
Fixes#360.
The original logic for incremental presence list updating from
668d0d9dfa incorrectly attempted to
insert the user 1 spot later than its proper index in the listing.
Now that we're doing presence updates in a performant fashion, we
don't need to throttle processing these events, and in fact the
throttling of these events created a correctness problem, since we're
now doing incremental updates rather than just rerendering everything
after each event.
The code in 668d0d9dfa for removing an
existing user from the user list to update the status didn't correctly
quote the email address of the user in its jquery selector.
Whenever a user became active, this triggers an immediate presence
update event (to show that user as active). The implementation for
that event (running on the browsers of all other users in the realm)
would fully rerender the presence list, which can be an expensive
operation in a large realm, just to update the status for that one
user. This fixes that case to just remove the user from the list and
then re-insert it at the appropriate index.
[Commit message expanded with more details by Tim Abbott]
Previously, you'd have to be offline to recieve missedmessage
notifications, or maybe idle for an hour. However, I'm pretty sure the
latter code didn't actually work, so we scrap that and just nofity you
via email or push as soon as you're idle.
Closes trac #2350
(imported from commit 899966e0514db575b9640a96865639201824b579)
We show a user as "on mobile" if:
* They are only active on mobile
* They are inactive on all devices and can receive push notifications
(imported from commit 0510b9371727cd19c72f6990df7112921c36ad48)
This is important for hotkey users to be able to use other hotkeys.
Since ESC clears a search, we need ENTER to merely blur the search;
otherwise, hotkey users will need to mouse away from the search box
if they want to keep the search sticky.
(imported from commit 204704435c7821c1ad3b7b750ffe3545adaff9aa)
Whatever text is entered into the search box under users is used
to filter users by their full names. You can use commas to search
for multiple users. Search terms must be at the start of names, so
"st,fr" would match "Steve Howell" and "Leo Franchi" but not
"jesstess." Names are case insensitive.
(imported from commit 822b72883928d3c941d38e9798774d71b0689f30)
Steve Howell
Tim Abbott
Brock Whittaker
Cory Lynch
Steve Howell
fionabunny
Joshua Pan
Harshit Bansal
Raghav Jajodia
vaibhav
Bickio
Rafid Aslam
AZtheAsian
kevv87
Tim Abbott
Ashish
Vladislav Manchev
Tim Abbott
Luke Faraone
Steve Howell
Leo Franchi
Tim Abbott