This fixes two bugs:
* If a user is not subscribed to a default stream, he or she would not
be have the option to invite users to that default stream.
* The initial streams checked in the invite modal were the
non-invite-only streams the user was subscribed to, not their
default streams.
Fixes: #4209.
If a url is present in stream description, it will be
rendered as a clickable link under /streams page.
Tweaked by tabbott to use the separate rendered_description element to
avoid duplicate rendering and to live-update.
Fixes#1435.
This adds a button to #subsciption page called "View Stream"
that narrows the user to that particular stream.
This fix involves typical changes to JS/CSS to add new features,
and we also add a "preview_url" field to the sub object in
stream_data.js.
Fixes#3878
If we get invalid events related to stream subscribers, we now
exit earlier to prevent ugly tracebacks. We may eventually
want to upgrade some of these warnings to errors, once we fix some
of our live-update bugs. In particular, we don't yet live-update
users when streams go from private to public, so if you add/remove
subscribers to a newly-public stream that a user still thinks is
private, they will not be able to handle the event through no
fault of the codepath that happens during the add/remove.
When an admin deactivate a stream, we now remove the
appropriate row from the default streams tables for other
folks viewing default streams in the admin tables.
(There was a method with the same name before, but it wasn't
being used. The new version will accept stream_id instead
of name, and we will use it as part of deactivating streams.)
When we subscribe ourselves using the "Add" button in the
right pane of "Stream settings", we now call
stream_data.subscribe_myself(), which properly updates our
data structures (more than just sub.subscribed) and prevents
some console errors when you un-subscribe yourself using
the check mark.
If a new user is auto-subscribed to a stream called "new
members", we will automatically narrow them to that stream
after the tutorial. Otherwise, we fall back to the code's
previous behavior, which is to direct them to the notifications
stream (often called "announce").
This is somewhat experimental. If we try this concept out on
the public Zulip realm and it works well, we will create a nice
realm setting for the "new members" stream.
This is a major change to the /#subscriptions page, converting it to
by a side-by-side list of streams and their settings in an overlay.
There are no new features added/removed, but it's a huge changeset,
because it replaces the old navigation logic and moves the stream
creation modal to appear in the right side of this overlay.
We now use stream_id as our key to rename streams, which
should prevent a few race conditions long term. (We are
still possibly contending with other events that use
stream_name as a key, so this is not perfect.)
We get events to delete subscribers for streams we are not
necessarily subscribed to, and it is now important to
process those events to produce the correct UI for showing
the number of subscribers to streams.
The startup code in subs.js used to intermingle data
stuff and UI stuff in a loop inside a called function,
which made the code hard to reason about.
Now there is a clear separation of concerns, with these methods
being called in succession:
stream_data.initialize_from_page_params();
stream_list.create_initial_sidebar_rows();
The first method was mostly extracted from subs.js, but I simplified
some things, like not needing to make a copy of the hashes
we were passed in, plus I now garbage collect email_dict. Also,
the code path that initialize_from_page_params() mostly replaces
used to call create_sub(), which fired a trigger, but now it
just does data stuff.
Once the data structure is built up, it's a very simple matter
to build the initial sidebar rows, and that's what the second
method does.
This function will make it easier to unit test upcoming
changes related to stream counts.
This was mostly moving code, but one change is that we
don't call create_subs() in subs.js any more (which would
have been kind of circular dependency), since the only thing
that it did besides calling a more appropriate function
in stream_data.js was to generate a trigger that was
subsequently ignored and possibly a UI trap, as we don't
want to be messing with the stream sidebar when we go into
the stream settings page.
We now simply call exports.create_sub_from_server_data() for
newly encountered unsubscribed streams (which don't belong in
the sidebar anyway.)
This function used to live in subs.js. It's mostly a code move,
but I simplified the logic to determine whether it's subscribed
not to do a lookup into the same data structure that the sub
already came from.
I also added some tests.
This moves these functions from subs.js to stream_data.js:
receives_desktop_notifications
receives_audible_notifications
This makes notifications.js no longer dependent on the
bloated subs.js.
The JS code can now call stream_data.get_sub_by_id() to get
a sub from a stream_id. Subs have stream_id due to a prior commit,
and we keep track of the mapping in stream_data's subs_by_stream_id
variable.
(imported from commit 409e13d6d2e79d909441a66c85ee651529d15cd2)
The tutorial introduces "engineering" messages that might not
be in the user's normal subscription, and they would get a gray
border if we did not override the stream color. Before this change,
we accomplished this by overriding the core data structure in
stream_data.js. Now we are a bit more future-proof; we only
override stream_color.default_color.
(imported from commit 0d0845b72f766912679f5aa7641ae9a60fdbb4ce)
I want to make subscribed_streams() external, but it conflicts with
a legacy name in the same module (stream_data.js), so I have to rename
it in the same commit. The new name conforms better to the current
naming convention, which generally has functions returning objects
use "sub" in the name.
(imported from commit 9f1ed60772c649359a413257e0998857eab3603f)
For a large domain like HS, we were pulling back about 100k of
text with subscriber emails when we opened the Streams page.
This was unnecessary, as the subscribers aren't shown until
you expand the stream, and there's already an AJAX call.
(imported from commit 69b83d769030d87318acefc364ac6ff3a2ec3605)
Warn inside these functions when you get data on streams that you
are not subscribed to:
add_subscriber
remove_subscriber
user_is_subscribed
The back end should be smart enough not to spam us with subscriber
info that we don't care about.
(imported from commit b27644be2abc37c11ddff884ef392ea208bd1bd3)
James Wang
Raghav Jajodia
Kanak Garg
Steve Howell
Tim Abbott
Brock Whittaker
Yago González
AZtheAsian
Tommy Ip
Vishnu Ks
Steve Howell
Jessica McKellar