Now this function will delete tokens from RemotePushDeviceToken if it
is running on notification bouncer or PushDeviceToken if it is running
on a server which doesn't use notification bouncer.
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 regex we were using didn't cover all the unicode blocks
to which our emojis belong. This commit fixes the regex to
include all the unicode blocks and also updates the
corresponding JS regex in marked.js.
Fixes: #3460.
Unicode codepoints are of minimum length 4, padded with extra
zeroes if the length is less than 4. This commit fixes the
`unicode_emoji_to_codepoint()` to ensure that the codepoint
it generates are of correct length.
When we create a stream, we usually send a welcome message on the
stream itself as well as an announcement on the announcement stream,
but we no longer PM the individual users. Hopefully this will be
more pleasant for users (less spammy), and it also will make creating a
stream a lot faster.
We still send notifications when we add subscribers to an existing
stream.
Thanks to Rishi Gupta, James Rowan, and many others for their work on
this.
This replaces most of the content in prod-customize.md; we'll
deduplicate soon.
We now pre-populate the streams in DEFAULT_NEW_REALM_STREAMS
(social/general/zulip, unless somebody changes settings.py) with
welcome messages. This makes the streams appear to be active
right away, and it also gives the Zulip realm less of a
blank-slate feeling when you create it.
This change only affects the normal web-based create-realm flow.
It doesn't impact the management commands for creating realms
or setting default streams.
If you were narrowed to an unpinned stream, and then pinned it,
we were mostly redrawing the sidebar correctly, but we weren't
setting the active-filter class. Now we accomplish this by
calling maybe_activate_stream_item(), which also reduces some
code duplication. (The new code introduces a bit of extra logic
to do `stream_li.addClass('active-filter')`.
This commit changes the key for recent_topics to be a
stream id. For streams that have been renamed, we will now
get accurate data on recent topics and active streams as
long as stream_data.get_stream_id(stream_name) returns a
valid value.
This commit changes stream_data.in_home_view() to
take a stream_id parameter, which will make it more
robust to stream name changes.
This fixes a bug. Now when an admin renames a stream
you are looking at, it will correctly show itself to
be un-muted. (Even with this fix, though, the stream
appears to be inactive.)
Some callers still do lookups by name, and they will
call name_in_home_view() for now, which we can
hopefully deprecate over time.
Rather than having get_stream_li() look up stream id using
stream name, we force the callers to pass in the stream id.
This adds an extra line to most of the callers for now, but
this will eventually change as we fix some of the callers to
have their callers pass in stream_id.
In places where we now call stream_data.get_stream_id() to
get the stream id, we will be more resilient toward stream
renamings, at least until the next reload, since
stream_data.get_stream_id() can resolve old names that
are stored when we process stream-rename events.
We no longer have get_stream_li() delegate to get_filter_li(),
which simplifies the logic in get_filter_li() and makes
get_stream_li() more direct.
We also move the two functions closer to each other in the file.
