The first menu option supported is to narrow to the topic.
The chevron only shows up if you turn on feature_flags.muting.
(imported from commit 17482f538a6d3e4ff96a36c042bad972d34f4b11)
Use the stream_data API to set up subscribers, so we don't
leak the data structure details into subs.js
(imported from commit e95616f2eb535ecf0e1cef35a143a71ad88de5bc)
This was requested by CUSTOMER28 and would also bring symmetry with
the user sidebar, which already does this.
(imported from commit 4dca3c957d3a710f00bbb34a7cd7dfe6074da8f7)
Though this should not be common, getting a peer subscribed/
unsubscribed notification to a stream we don't yet know about should
not be fatal
(imported from commit ee28b163e0efc9adfad31e1b321e986dfe56271e)
We create a blueslip error for undefined keys in Dict. This led
to a straightforward change in the unit tests for Dict. For the
unread test, to avoid the blueslip error, we had to be more specific
in setting up a user in one place, but this reduced our coverage,
leading to another small test being added.
(imported from commit 33e14795500d9283de2a7c03c4c58aec11cea4b8)
The exceptions were cryptic before, and they were inconsistent with
the fold_case: false behavior.
(imported from commit a40704d1a22bcdc60d91be832ee3c81eb416c6dd)
These engagement data will be useful both for making pretty graphs of
how addicted our users are as well as for allowing us to check whether
a new deployment is actually using the product or not.
This measures "number of minutes during which each user had checked
the app within the previous 15 minutes". It should correctly not
count server-initiated reloads.
It's possible that we should use something less aggressive than
mousemove; I'm a little torn on that because you really can check the
app for new messages without doing anything active.
This is somewhat tested but there are a few outstanding issues:
* Mobile apps don't report these data. It should be as easy as having
them send in update_active_status queries with new_user_input=true.
* The semantics of this should be better documented (e.g. the
management script should print out the spec above)x.
(imported from commit ec8b2dc96b180e1951df00490707ae916887178e)
people_list and people_dict include the feedback bot and anyone you've
cross-realm PM'd with. Useful for autocomplete, but not for admin and
stream settings views.
Fixes the UI part of Trac #1772.
(imported from commit cdefd4e86980447aad5190e7fc8ae3666d66e3c3)
hashchange, which calls admin.setup_page, runs in another onready
event handler before zulip.js main().
(imported from commit 5d4e71f4666baf0a53e3fe9804561ce6cdc06261)
This is feature-flagged to staging only.
There are basically 3 parts to the implementation:
1. In response to typing, fade/unfade the user list.
2. When a compose is aborted, unfade all users.
3. When the presence list is redrawn, fade/unfade the user list again.
(imported from commit cd416de232849a9f69dcacdc8b0fcfc20e3848a2)
This is the last step in getting a consistent client-side picture of who
is on a stream (provided non-MIT realm, and provided the local user is
subscribed to that stream).
(imported from commit 8bca722f169860ad4c1c92fdcb70d62c60f70fed)
This fix required upgrading to 1.1.17, but it's not squashed
with the upgrade, because that would complicate keeping the
copyright-fixing commit separate from the upgrading commit.
The new version of the plugin makes it so we can trigger a
resize event, but it's backward incompatible with our old
compose box code.
A minor cleanup here is that we also don't trigger a resize
right before hiding the compose box.
(imported from commit 6b0cb9ccd2ddef919fd375a80cfca535b5b74c0f)
The previous setting of 1.4em translates to about 19.6px. In the case of
the CUSTOMER4 emoji, 19.6px looks bad in Firefox on Linux while 20px
looks fine.
(imported from commit 01de911076e5f54e4aee96dc9edd3d40f03a4bb3)
It had an invisible part that didn't hide, which covered the send button
in skinny, leading to Trac #1776.
(imported from commit faec9413539238c40c584ab636fc4d75618a5935)
If the date_row is between two messages, it tells you when the message
below was sent, but not when the message above was sent--for that you'd
either have to click on a message or keep scrolling up. This is especially
annoying when there are sometimes gap days on a particular stream (you shouldn't
assume that the message above is simply from the previous day).
This adds the date of the previous message (the time above) to the date_row.
(imported from commit 4c6c956118ae09fedca042e797a6029fdd26e00c)
When creating a new stream, this option lets you announce its
creation to everyone who you didn't explicitly add.
(imported from commit ae4140b4268b73e8b4bb54f5a6eea12fe07cd110)
Leaving the feature flag in in case certain realms don't like it,
so we can easily blacklist them from this feature.
(imported from commit 2a5884008be05216d195a582a327d7641bc419d5)
The summary bar now has the following features:
* invite-only locks
* narrowing links to stream/topic/person
* exterior topic links
(imported from commit ddb987b8e04e7dfc2d602c958270b7bc0e37fb5f)
Previously, narrowing would only work from recipient rows, not
other message table rows (e.g. summary rows). This led to the trap
that you could add a narrows_by_recipient class to an element,
expect that narrowing would work, but the actual handler would
break or silently fail if it weren't part of a recipient row.
Now the click handler looks for the closest table row (tr). It's
encapsulated in rows.get_closest_row(), so if we go to a
non-table-based design, it should be easy to address in one
place.
(imported from commit e116b7573c4bb06599ced84a0adcf8dc23d63593)
This fixes a bug (hit by a branch of mine) wherein you could not
render Handlebars templates from a DOM-ready callback in a file that
came before templates.js alphabetically.
(imported from commit 48091d016776eb6f12d33db199781e776af18fc5)
In particular:
* Pull the count containers out of the containers that cut off overflow text
* Make them lozenge-like
* Add logic for shortening the overflow container when a count container is
present
(imported from commit a2b3d237cbfe4fadfbbc3a931d2de85dfba10d04)
This shows up when you're not running a Zephyr mirroring bot and lets
you use Webathena to have us run it. Obviously needs more docs.
Current problems include:
* supervisorctl reload ends up recreating /var/run/supervisor.sock
with the wrong permissions, so it only works once in a row before
you need to chmod that.
* /etc/supervisor/conf.d needs to be humbug-writeable; this is a clear
local root vulnerability
* This uses SSH and thus is kinda slow.
(imported from commit 7029979615ffd50b10f126ce2cf9a85a5eefd7a2)
This brings several improvements:
* The Dropbox script won't slow loading our app.
* If it fails to load, no traceback; Dropbox link just won't appear.
* For users with Dropbox disabled (most at this point), no loading at all.
(imported from commit e71ae5790fc85a185e622bdafb350109527b4eee)
The setdefault() and num_items() methods are handy, and it was a
little tough to keep track of which objects were Dicts vs. {}.
(imported from commit 6ca81ac411943c59bef6d6bae39c7641feb5574b)
The click handler for collapsing was too broad, and it overrode
the ability to click to narrow from the recipient bar.
(imported from commit feeaa9becf8e400e319e1a77e5b72a33bb22854c)
Specifically:
* Add and style the sidebar toggle button to the header and remove the
gravatar.
* Add the logic for retracting the left side bar.
* Modify the logic for clicking on the referral pane to prevent it from
closing the sidebar.
* Modify the logic for clicking on the stream filters to prevent them
from closing the sidebar.
* Modify the logic for clicking on the stream settings dropdown and the
user info dropdown to prevent them from closing the sidebars.
(imported from commit 73e00eb834a6e87cb8d659fdcf6c2e06fff3731d)
This is experimental, for staging only. There might be a better
way to model this than dueling force_expand/force_collapse flags,
but it works for now. The code in collapse_recipient_group()
could also be DRYed up relative to expand_summary_row().
(imported from commit 107151d1ecd640970fb7700d41278a003bd1abaa)
This is to set up collapsing, but I think they could be useful
in general, so I'm keeping this is a separate commit.
(imported from commit 0da2b8ef246649f678c7cb6664ee78bf36aca076)
(The approach has been simplified to look for summary_row in
the DOM, which makes muted and summary features work off the
same code.)
(imported from commit 4fa3d6ae5ad7bbac5958e60ecffb368d6ef29d2e)
As part of this commit:
* Add and style a top right button that controls the sidebar
* Add the necessary styles for the right sidebar when it's in that mode.
* Add the logic for controlling the sidebar expansion
* Modify the logic for prevent default click events to generally
hide popovers correctly.
(imported from commit ca8063f6c62b436799f952e88541ff0ae8ba85fe)
This change will allow us to test the muting feature on
staging. Any topic named "muted" will automatically be
muted. You can also mute any other topic on the console:
muting.mute_topic('devel', 'ios');
current_msg_list.rerender();
More UI around this experiment will be coming soon, as well
as support for muting entire streams.
The muting module keeps track of which topics are muted, but a
user can expand muted messages, and once that happens, the
messages are marked with the "force_expand" flag that gets
persisted to the back end.
Muted messages are rendered in similar fashion to the summarized
rows, and as part of unifying some of that code, we have
made it so that expanding a summarized section doesn't remove
individual flags related to summaries; instead, the messages
get the force_expand flag set.
(imported from commit acee4190e63813d46850415c41ff8ebfae4a6953)
Home/All/Private/Starred/@-mentions lost their left padding due to a
mistake in 700b444. Restored here.
(imported from commit 9a4d5ab5d376e64ba82802097c30449c6544a5e9)
The old API took a dictionary; the new function works for one
person at a time, which allowed us to clean up the calling code
in ui.set_presence_list.
(imported from commit 0ae9d01491238d32915572c7efebf476d05fed4b)
I regressed this recently, thinking that all our operators are
strings, but I forgot about the "near:" operator used in the
"Narrow messages around this time" feature. The user facing
symptom was that the search bar showed up empty instead
of saying near:50, which might actually be the better
behavior, but it certainly was not intentional. :)
(imported from commit fcb93cecbe9a052bb9bc1af7fcac5aecaba5aafb)
I'm trying to move well-isolated methods out of narrow.js, so that
narrow.js is more strongly focused on UI/ajax interactions and
big, heavy lifting stuff. The logical home for parse/unparse
seemed to be Filter, and they brought along two private methods
with them. The big code moves involved trivial follow ups
like s/exports/Filter/.
(imported from commit ace0fe5aa1c7abce0334d079ba9eb8d9a57bd10f)
Have ui.set_presence_list() only touch the presence list.
Before this change, it was calling update_unread_counts(), which
has a bunch of side effects unrelated to the presence list.
(imported from commit 690f754d78874a03fa36f8ff8765d5a63e431d28)
This was broken in two ways:
1. Commit ad59d6f78042ce89, "Make the left sidebar and right sidebar
more consistent", pushed last Monday, changed the markup for the right
sidebar without changing a selector in stream_list.js that was looking
for the old markup.
2. Even then, whenever new user presence information came in, we would
rerender the user list and blow away the unread counts. This commit
patches around that by updating unread counts after rendering the user
list. I'm not sure what broke this or how it was working before.
(imported from commit 53ed40139e257e44411e918d1ecdce3a49e9ee51)
Trac #1479
All our typeaheads use this, but I made it an option that must be enabled
explicitly since it is not default bootstrap behavior.
(imported from commit 97852dc407d1f6dbe46b5fdd2c56d3ed8c6718d2)
This is like Python's dict.setdefault. I don't love the name, but
the consistency is nice.
We have lots of places where we do things like:
if (! dict.has('foo')) {
dict.set('foo', []);
}
var arr = dict.get('foo');
arr.push(3);
We can now write:
var arr = dict.setdefault('foo', []);
arr.push(3);
(imported from commit b8933809c69ba47ec346ed51d53966793403e56c)
This helps make our statuses more meaningful and should resolve trac #1534.
As part of this, we lower OFFLINE_THRESHOLD_SECS to 1.1̅6 minutes and
mark the user as idle after 5 minutes.
(imported from commit ee6b1ad203554a84b11e16c4c6195be9df5bcf4f)
This was caused by a branch I was working on conflicting with the
stream_data.js split.
(imported from commit 995dcf1412114bd36404b8c7ef66eb6f1e89648a)
keys() and other methods that implicitly return keys return the
casing used for the most recent set()
(imported from commit 47cac13c2b928fd19b07c44fd1504426fb36e3d8)
This means that we no longer need to unmunge keys at the expense of
having to store the original key.
(imported from commit 958c33c806b8b399e9a9290e4f14ef119d923c14)
This changes the mit.edu access rules from:
* Susbcriber list and inviting users to streams are unavailable
to
* Susbcriber lists and inviting users to streams are only available
for invite-only streams
streams must still be made invite-only manually.
This both cuts down on the amount of code that is different between
the mit.edu user experience and the standard one, as well as paving
the way for us to invite-only streams for zcrypt.
(imported from commit 24e0e85428608c05c89eeea349338dd392e5489a)
The function narrow.unparse() is used in a bunch of places in
the search suggestion code, and now it no longer lower cases
operands. This change contributes to fixing trac #1659.
(imported from commit 6b44b8a818482b5c8b4f9a45bc7d3a9d21e04eba)
Streams are converted to their "official" names now.
Topics are not canonicalized at all.
All other operands continue to be lowercased.
Since we don't lowercase stream/topic at the parsing stage,
we have to modify the predicate function to do the lowercasing
of stream/topic to enable case-insensitive comparisons. This
is slightly more expensive. The server-side predicate
functions are already case-insensitive.
(imported from commit 286f118c6c3ff9d23b37c7f958cab4c0eacd5feb)
This can be squashed with the prior commit or subsequent commit,
or it can just stand on its own, but it's part of transitioning
to a functional change in the next commit.
(imported from commit 155a0cdd28f851810fbedfef1a306e3190bf1c34)
If we have a stream named "Denmark" and we're narrowed to it,
then use "Denmark" as the default stream name in the compose box
even if the narrow operators are lowercase.
(imported from commit e9f06b7307c73231aa887dc95849e0307984e6f0)
This function returns the stream's actual name, if we can get it;
otherwise, it's the identity function.
(imported from commit 7a981adba9632d6c6eba54cb6514a9226d1e83e8)
We had a duplicate and incorrect check on if a stream was in your home
view, which caused us to not display Home unread counts in the sidebar
/ notification bar / Dock on page load.
(imported from commit db27cf9091f8b47200b025f03a26c4fe82701882)
Users were getting confused about why the unread count in the sidebar
/ notification bar / Dock was different from what the bankruptcy modal
said, so only show them the true server count until they've made a
decision.
(imported from commit 71d376cd4a85749ccf49936b251e6b8ac21361b7)
This change would allow anyone in the realm to set a topic for a "no topic"
message. As soon as the message topic is set, only the sender can change it again.
(imported from commit 0a91a93b8fd14549965cedc79f45ffd869d82307)
The new implementation makes add_topic() be O(1). We incur
the cost of sort() in topics_seen_for(), but that's only called
in the typeahead widget, and I think the typical number of topics
should be manageable here.
(imported from commit 0e332301b2e44b4465bf7a1d93ae525a8d17a6b6)
Specifically:
* Fix the settings menu positioning and appearance
* Restyle menu and add arrow on top
* Remove labels from new message buttons in narrow windows and adjust the close button on the composition pane
(imported from commit 586753b6526289b32ec0a90b62d8b2ac1c8182cd)
This partially reverts d3c28b17859cacd49b7db9f8784d4b8b9069e1ff.
It is necessary to call update_floating_recipient_bar from _fade_messages and
_want_normal_display because they are called after opening/closing the compose
box. There is no scrolling there, so it is not otherwise updated. It is not
necessary to call from update_rendered_messages as it is not called on
changes of the fade state.
Related: Trac #1682
(imported from commit e2528f8c8827b7e2a135d7fc2b53e9e8162799b0)
Jessica McKellar
Leo Franchi
Allen Rabinovich
Steve Howell
Zev Benjamin
Jeff Arnold
Jeff Arnold
Tim Abbott
Kevin Mehall
Scott Feeney
acrefoot
Waseem Daher
Scott Feeney
Luke Faraone