When decoding an operand, a + can be converted to a space
only if the operand is not an email address.
(imported from commit 08fc36a579bbe6409137c60c0fa9579fe3ab2c43)
It's a bit of a contrived use case, but you could make a topic
called "12345" and then mute it from the sidebar, and it would
crash inside Dict. We now call attr(), not data(), to avoid
string-to-integer conversions.
(imported from commit 89666f40d624df154d41077546e1c13a23ee7e67)
Before this change, you could narrow to an old topic, and it would
not show up in the sidebar unless it had unread messages.
(imported from commit f177a7378dac064e46a6417357cc86ada4475936)
The old code was looping through recent_subjects to find the
original subject name, but we already have logic in get_subject_filter_li()
to be case-insensitive. I tried this with various casings of topics,
narrowing to topics, as well as narrowing to a stream (so no active topic)
and narrowing to an old topic.
(imported from commit 1decde13477cb742fd4bc82798f1afb282182bdf)
Create our own objects for handlebars, so that we can add transient
flags like is_zero without worrying about side effects to other
code.
(imported from commit b351a369cb3f36233e108e270c7abdd4ab8c5860)
When we call rerender() on MessageList, it is usually because
something big has happened, so it's reasonable that the pointer
may now be invalid. As an example, the old pointed-to message
may been removed from the home view. We have always just
moved the pointer under the hood, but now we do it in a way
that doesn't generate spurious blueslip errors.
(imported from commit d399a101f36b744a423ea7da80dda8352440c6c9)
There is a scenario where we call process_read_message()
for a message that we haven't recorded as unread before.
I'm not sure how it happens, but I put back code to
guard against crashing. The regression happened in
5752458c821.
(imported from commit 5ce15d2e236b738b445ed88f1733aa0612be0ff3)
This fixes a blueslip error where we were trying to add the same
message into a MessageList twice. Muting complicates our duplicate
detection, because empty() can return true even when we already
are storing messages that just aren't shown (because of muting).
The name empty() should probably be fixed in light of muting,
but filtering with self.get() is not really a problem here.
(imported from commit 83b0890471c9a0aa21996f3d0d3be4a238f23e65)
We have been persisting muting preferences on the back end for
a while, but we haven't been adding them to page_params for the
client to have at reload/startup time.
(imported from commit d9ca68aa0e4d22bfb0e6ce67fc0bc63981175c8b)
With the muting/hiding features, it has become the case that
this._hash can have entries that don't map to actually visible
rows, so this.get() can return true on an id that shouldn't
actually be selected, causing downstream code to explode. Now
we call this.closest_id() regardless of whether the hash is
populated, to be safe, but then we still call blueslip.error
if the pointer moved.
(imported from commit 348e8ff67ce3a6d61aaeb31f80549386518af2d0)
If you have two browsers open for the same account, muting in one
browser will now be reflected in the other browser. This got
regressed when changing the approach from collapsing to hiding.
The new code should be less brittle, as we encapsulate re-rendering
in muting.rerender().
(imported from commit 4e65e265b64513d38f518770453b7436cb92b4ca)
Update get_counts() so that it ignores counts for muted topics
when calculating stream/home unread counts.
(imported from commit 9b4e4da4346c225c535e97d709d3dee032603cc5)
The indirection was more confusing than helpful, especially
since the function had side effects, despite its getter-like
name.
(imported from commit 85d9cf642b4177f62488136f0e0f7f6c9304942e)
After killing off unread_counts.stream, the only field of
unread_counts was "private", so I just made unread_privates.
(imported from commit 9678f5b03524afb883ec4fa638b059e698888e78)
The prior commit makes it so that we no longer use unread_counts.stream
in get_counts(). This commit removes the code that updates the
data structure.
(imported from commit 5752458c8212bf02cf9c8733ce349fc35b204a9b)
These two data structures are kind of redundant:
unread_counts['stream']
unread_subjects
We are deprecating the former. The latter is more flexible for
features like muting.
Now, in get_counts(), we compute home counts and stream counts
in the same loop that computes subject counts.
(imported from commit c8d0ea12a56d0128811e0aa165de9882546906a5)
We are still showing the same data points, but the logic to drill
down on details for a particular realm is now all server side,
not client side, and we are smarter about omitting fields. In
summary mode, we don't show empty Name or Email columns. In
detailed mode, we show the realm as a headline instead of a column.
In this version you do lose the ability to see all system users in
the same view, but Waseem is ok with this.
(imported from commit edd2e646ab4cf5783ea64232d0cd621debece8d4)
When you load the activity report, it will just show summary
counts for realms, but if you click on a realm, you will see
details about users in the realms. You can also click "Show all"
to see an interleaved view of realms and users.
(imported from commit b106557b1fae64d525071afc124b5a8aed319086)
`Cannot read property 'flags' of undefined` in the
_.each callback in expand_summary_row.
Messages loaded when you scroll up in a narrow are not added to
all_msg_list. Because the user just clicked the message, we know
the message is in current_msg_list, so use that instead.
(imported from commit e76449a2a2748b96f69a2ab05d288b708d9e3ac0)
Instead of collapsing muted messages, just hide them altogether
in view where it makes sense to hide them.
(imported from commit 1c2c987ff302ceb135a025753cf421b4de1aea71)
I moved code into MessageList to further encapsulate details
of filtering. The MessageList instances should be their own
gatekeepers for what messages they care about.
(imported from commit ee6cd7f6eabf97962d724a05d7d0b0a3e6ab19e5)
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)
