Our current workflow for creating a new stream allows the user to
invite as many other users as they like but since there can be
mistakes in doing so, we now open a modal with a warning if the
number of invites are more than 100 just to confirm that user indeed
wanted to do this.
Fixes: #1663.
When you create a stream, there was always an "Announce stream"
option that would be enabled for public streams.
We are about to make it so that we never send PMs to announce
new streams to folks, so the only mechanism will be sending a message
to the realm's notification stream. If a realm has no notifications
stream, the decision is moot, so we hide the option.
The function check_stream_existence() temporarliy got moved
to stream_create.js, and our call from compose.js was still trying
to find it in subs.js. Now we move the function to compose.js,
since we no longer use it stream_create.js.
This function is pretty dubious, and we may want to only check
for duplicate stream names locally.
When the user creates a stream, we no longer do a synchronous
check on the back end to find if the stream name already exists.
Instead, we only check our local data, which will prevent many
typical errors, and then we let the back end capture duplicates for
stream names that the client doesn't know about.
We also tone down errors when the stream name is blank--we
only whine about empty streams right before submitting the form.
Also, since our check for duplicate streams is less expensive,
we now capture the "input" event instead of the "focusout" event,
so that if you fix up the name to avoid a collision, you get more
immediate feedback.
When we do detect stream name errors, we conveniently focus the
text field to let the user correct the problem.
This new modules handles the UI to create streams. It mostly moves
code from subs.js.
It introduces an API around what used to be called meta.stream_created:
reset_created_stream()
set_name()
get_name()
It only partially moves new_stream_clicked().
Tim Abbott
Harshit Bansal
Steve Howell