* We show a "Click here to reveal." hyperlink in the hidden
message dialog for user to click on and read a hidden message.
* The "reveal" action is temporary, in the sense that a revealed
message will again be hidden once the broswer tab reloads or
if the user renarrows.
* When a message is revealed, we make sure to show the sender
of that message, even if it isn't the first message of it's group.
This is because the first message of that message group (which
would have otherwise shown the sender) can still be hidden.
* Reactions and background color after revealing a message are
the same as if the message hadn'e been hidden at all in the
first place.
* We hide the sender and reactions on messages sent by muted
users, and replace the content with a "This message was hidden"
dialog.
* Ideally, we should collapse a series of consequetive
messages sent by muted users into one such dialog, but
that could break the cursor behaviour and `near/<message_id`
links, so we as of now show one dialog per muted message.
* Because we hide the sender, there is a chance of the first
hidden message in a group looking like it was sent by the
author of the message above it. To tackle this, we intentionally
make the hidden message dialog float-left, so that it is clear
that this is a special type of message.
* For context, we still show the timestamp of the message.
* Starring, editing, deleting etc a message still work just like
before.
A further commit will add the ability to reveal a
hidden message.
Earlier, a user can only mute a topic from its recipient bar but can't
unmute it from there (and in fact we displayed an option to mute even
if the topic was already muted!). This commit fixes that bug and
allows a user also to unmute the topic from its recipient bar.
There are two core issues here;
* We did not have code, an icon, etc. for the "already muted" case in
the recipient bar logic at all.
* We did not rerender messages in !excludes_muted_topics views when
muting state changed.
See: 660475bd0c for background on when
we started only rerendering the streams with excludes_muted_topics
after muting changes. Rerendering of newly muted topics are important
for live rendering if a user is narrowed to that topic itself, which
are essentially all excludes_muted_topics narrows anyway.
Hence, now, we rerender by calling the `rerender` function for muted
topics (which is done just before we update the items for muting via
the function: `update_items_for_topic_muting`).
Tweaked by tabbott to add comments explaining the reasoning and
long-term plans.
Fixes#15223.
This reduces the complexity of our dependency graph.
It also makes sub_store.get parallel to message_store.get.
For both you pass in the relevant id to get the
full validated object.
This commit takes the blocks of code from "build_message_groups" that are the
same as "_rerender_message", and move those into a function called
"set_calculated_message_container_variables". This helps to avoid bugs in
future as in #17663. Like timestr was being updated in one of them, but needed
in both. So, it takes care that message variables are correctly set.
Part of #17663
This commit updates the _rerender_message to update the message_time
string with the current timestamp on the message rerender.
When we locally echo a message, we store a local timestamp that will
generally not be used as it is replaced by the server time in
echo.process_from_server when we confirm receipt of the message.
echo.process_from_server correctly updates the .timestamp field on
the message and triggers a rerender but that rerender reuses
the message_container object without recomputing the
message_container.timestr due to which wrong older timestr was shown
on the message box.
This commit fix this by calling set_timestr in the rerender code path,
alongside calls to update similar data structures like
this._maybe_format_me_message.
Fixes#17655
When idle, we try to backfill messages and in the end reselect
the closest message in the list, which can be a unread message
if present.
When recent topics is open, we can backfill messages; but
shouldn't select the message_id otherwise it will mark the
message as read if the message is unread while triggering
`message_selected.zulip`.
Instead of prohibiting ‘return undefined’ (#8669), we require that a
function must return an explicit value always or never. This prevents
you from forgetting to return a value in some cases. It will also be
important for TypeScript, which distinguishes between undefined and
void.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
ES and TypeScript modules are strict by default and don’t need this
directive. ESLint will remind us to add it to new CommonJS files and
remove it from ES and TypeScript modules.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
m-e-l-u-h-a-n
Abhijeet Prasad Bodas
akshatdalton
Steve Howell
Anders Kaseorg
Signior-X
Ganesh Pawar
Aman Agrawal
Priyank Patel