If a user types "/me runs to the store", we put "runs to the store"
in bold after their name.
(imported from commit fbc11e99244e1c8fa1c03e4753e706957fcd449e)
The main user-facing feature here is that users can open narrows
in new tabs or windows. Internally, it makes the HTML more semantic.
One consequence of making these elements into actual anchor tags
is that clicking on them no longer triggers this logic to
close the compose box when you click outside of it:
// Unfocus our compose area if we click out of it. Don't let exits out
// of modals or selecting text (for copy+paste) trigger cancelling.
if (compose.composing() && !$(e.target).is("a") &&
($(e.target).closest(".modal").length === 0) &&
window.getSelection().toString() === "") {
compose.cancel();
}
Instead of patching the above code, I elected to just call
compose.cancel() explicitly in the click handlers for the links
themselves.
We are gonna try to clean up the compose-box behavior globally soon.
(imported from commit c9a01916f1714fe3dd495d25c78cd5e5532105ef)
I added comments to the section of the template that generates
recipient bars for stream/topic messages.
(imported from commit a7ea9353dc5db20db3410b9566f5e0d670eff31f)
The summary bar now has the following features:
* invite-only locks
* narrowing links to stream/topic/person
* exterior topic links
(imported from commit ddb987b8e04e7dfc2d602c958270b7bc0e37fb5f)
This is experimental, for staging only. There might be a better
way to model this than dueling force_expand/force_collapse flags,
but it works for now. The code in collapse_recipient_group()
could also be DRYed up relative to expand_summary_row().
(imported from commit 107151d1ecd640970fb7700d41278a003bd1abaa)
This is to set up collapsing, but I think they could be useful
in general, so I'm keeping this is a separate commit.
(imported from commit 0da2b8ef246649f678c7cb6664ee78bf36aca076)
This change will allow us to test the muting feature on
staging. Any topic named "muted" will automatically be
muted. You can also mute any other topic on the console:
muting.mute_topic('devel', 'ios');
current_msg_list.rerender();
More UI around this experiment will be coming soon, as well
as support for muting entire streams.
The muting module keeps track of which topics are muted, but a
user can expand muted messages, and once that happens, the
messages are marked with the "force_expand" flag that gets
persisted to the back end.
Muted messages are rendered in similar fashion to the summarized
rows, and as part of unifying some of that code, we have
made it so that expanding a summarized section doesn't remove
individual flags related to summaries; instead, the messages
get the force_expand flag set.
(imported from commit acee4190e63813d46850415c41ff8ebfae4a6953)
This change would allow anyone in the realm to set a topic for a "no topic"
message. As soon as the message topic is set, only the sender can change it again.
(imported from commit 0a91a93b8fd14549965cedc79f45ffd869d82307)
If you search for "hello", then the word "hello" will once again
be highlighted yellow in the messages.
(imported from commit 172a40f1e288f9947ab3bfbff82b4a2f5ba5cecb)
One of the ugly parts of message_list.js is how it re-uses the message objects
from the server to hold handlebars template parameters. These objects are
shared between different message lists and re-renders, but are mutated by the
rendering process. The `dom_id` attribute is normally unset on summary rows,
and should not be used in the template. But when a message comes in with a
`dom_id` from another render, it can end up on the summary row, breaking
`rows.get()`.
(imported from commit ef6af65d5e995dffbd7234547786d6ea861920da)
When you read messages in a narrow and then un-narrow, collapse
adjacent messages read in the narrow into a summary row that can
be clicked to expand those messages.
Scoped to staging with feature flags.
The implementation of this within our current MessageList is rather ugly.
(imported from commit bcb3a39d8c0c334136fe86318f18ead03f0f50bf)