Apparently, we did essentially all the work to support showing full
topic history to newly subscribed users from a data flow perspective,
but didn't actually enable this feature by having the topic history
endpoint grant access to historical topics. This fixes that gap.
I'm not altogether happy with how the code and tests read for this
feature; the code itself has more duplication than I'd like, and the
tests do too, but it works.
This commit refactors the bugdown to perform a lookup only on active
realm emojis. This was needed because once we migrate realm emojis
to be addressed by `id` rather than name, it will be costly to
perform a lookup on all the realm emojis.
We no longer accept URLs while creating emoji; so this management
command was probably left out while migrating realm emoji
infrastructure to upload backend.
We could fix this to work properly today, but the command was
originally written in a context when Zulip didn't have a UI for
managing realm emoji at all. Now that we do have such a UI, it
doesn't have a compelling use case, and work on migrating the realm
emoji schema demonstrates that this does have a maintenance cost.
So, we simply remove this command.
Previously, stream subscribers were not rendering correctly. Due to
following reasons:
- Subscribers list didn't get initialized
- Subscriber members template add subscriber-list-table DOM element
conditionally, which doesn't handle case if user have access to
subscribers later.
Fix this by cleaning subscriber member template to hide the
elements, instead of conditionally adding DOM elements and
initialize subscribers list even if user can't access subscribers.
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.
If user unsubscribe from private stream, then user can't
access unsubscribed stream members.
After subscription removal, immediately render subscription members
template in case of user can't access stream subscriber.
If user has disabled message content in missed email notifications,
we shouldn't send any informations about missed messages i.e. sender,
stream, message text, etc. to email servers.
We are already hiding this informations in email templates, but we
shoudln't expose any information about message content if user
has disabled this setting.
We now include whether the message was a private or group private
message; this is particularly important with the new setting to
disable including any message content in these emails (since in that
case, one doesn't know anything about the message types).
If new private stream is created by realm admin without realm admin
subscribed to it, then it doesn't automatically add created stream to
realm admin's stream list. We have to reload the browser to get newly
created stream in stream list. Cause private stream creation event is
only sent to the subscribed users to private stream, so even if realm
admin is acting user, they don't get creation event.
We should send private stream creation event to realm admin users along
with subscribed user to stream, as realm admins can access unsubscribed
private streams.
Tweaked by tabbott to fix various typos and clean up the code.
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.
Only allow realm admins to create stream without subscribing
themselves, restrict non realm admin users.
This new restriction is only for the UI; we don't actually block it at
the backend/API level (one could always create and then remove oneself
anyway).
Restrict users(even realm admins) from creating stream with zero
subscribers only in UI.
In backend, if subscribers are zero, we automatically subscribe
current user to stream.
Add div element to inform user whether stream is successfully
created or not. This will help to inform user in case if current
user is not subscribed to created stream.
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.
For public stream, always show stream preview link.
For private stream, only show stream preview link if user is currently
subscribed or previously subscribed to private stream.
We now attach a fetch_status to message lists, so that they
can track their fetch status individually. When you go
back in a narrow and get all the older messages, we turn
off future fetches.
The narrow.js code no longer needs to orchestrate anything
here. The "home" message list won't have as many redundant
fetches after this commit, because we don't need to reset
flags every time we do `narrow.deactivate`.
And then actual narrows get a new message list every time
you narrow, so their fetch status gets reset implicitly
as part of constructing the MessageList object.
Tim Abbott
Ricky
Harshit Bansal
YJDave
Umair Khan
neiljp (Neil Pilgrim)
Archana BS
Abhigyan Khaund
Steve Howell