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
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.
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.
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 commit is similar to the prior commit, in that we are
more disciplined about setting up handlers. We set them up right
as the widgets get rendered, and the handlers only delegate
up to the container div (id="stream_creation").
We only have one possible email hint, so there's no reason
to create one for each stream row, especially since we don't
clean them out when we close stream settings.
If another user subscribed to or unsubscribed from a stream while the
current user was not subscribed, we previously would attempt to
rerender the subscriber counts for that stream, even though they
weren't rendered at all in the first place; this would trigger
blueslip errors from the expectOne() check in this function.
Fixes#8720.
Even if realm admin can access unsubscribed private stream subscribers,
admin can't add subscriber to stream. Hide the option to add subs to
stream in UI.
This will allow realm admins to access subscribers of unsubscribed
private stream. This is a preparatory commit for letting realm admins
remove those users.
Previously, when creating an invite-only stream, the subscriber counts
were not being rendered properly, in that the "create" event for the
stream had the user not yet subscribed (so can_add_subscribers was
false), and then the rerendering we did when the user susbcribed just
tried to update the number, not actually rerender the thing.
When user click on unsubscribe button, to unsubscribe from private stream
immediately remove unsubscribed stream from all subscribed stream list.
We don't remove public stream immediately on unsubscription, cause
user may want to undo/subscribe back to stream.
Currently, our stream creation do not add stream list to all
stream list. Only subscription-add event add stream list to
stream list. If public stream is created without acting user
subscribed to stream, then newly created stream is not listed
to all stream list.
On stream creation add sub to all stream list table.
This migrates what were effectively data update functions to be called
from the main stream_events handlers, instead of being called from the
view-update code in subs.js.
To re-render stream members on subscription add or remove event,
we are accessing undefined value "active_stream.stream_id" rather
than "active_stream.id", which resulted in falsey value and our
stream members were not updated unconditionally.
This commit prefixes stream names in urls with stream ids,
so that the urls don't break when we rename streams.
strean name: foo bar.com%
before: #narrow/stream/foo.20bar.2Ecom.25
after: #narrow/stream/20-foo-bar.2Ecom.25
For new realms, everything is simple under the new scheme, since
we just parse out the stream id every time to figure out where
to narrow.
For old realms, any old URLs will still work under the new scheme,
assuming the stream hasn't been renamed (and of course old urls
wouldn't have survived stream renaming in the first place). The one
exception is the hopefully rare case of a stream name starting with
something like "99-" and colliding with another stream whose id is 99.
The way that we enocde the stream name portion of the URL is kind
of unimportant now, since we really only look at the stream id, but
we still want a safe encoding of the name that is mostly human
readable, so we now convert spaces to dashes in the stream name. Also,
we try to ensure more code on both sides (frontend and backend) calls
common functions to do the encoding.
Fixes#4713
This will essentially run the code paths to go from whatever you were
at before to /all and back in the case of /new, which will call the
render function three times (!!), so remove this call because it isn’t
really necessary anyways.
Currently the new streams user list will populate twice when you click
the new stream button (or “+”), because it is triggered once directly
by the button click and then once by the hash change to /new, so we
want to ignore the changes by the hash change.
Previously, if you had the streams overlay open (but no active stream
clicked) while another user edited your subscriptions state, we'd
throw an exception handle the get_events call, because the code for
rerendering the subscribers list didn't consider the possibility that
there was no active stream.
When re-subscribing by way of the "Subscribe" button in the right
side settings panel, the row will now be marked as active to
highlight that the row is still selected and being looked at.
Fixes: #6955.
Yashashvi Dave
Steve Howell
Tim Abbott
Greg Price
Cynthia Lin
Brock Whittaker