After adding a newly created stream to the top of the stream list,
call to actually_filter_streams in stream_events.mark_subscribed
rerendered the filter_table and the stream list was refreshed. The
call to actually_filter streams was introduced to rerender the
subscriber list but stream_edit.rerender_subscribers_list takes care
of it already.
Fixes#9033.
This is a general code cleanlyness improvement.
While we're at it, we combine together two test classes that didn't
have a particularly good reason for existing.
Currently when admin add/remove/update custom fields, changes
are not reflected in user settings page, if settings tab
is already open. This might be rare case, but it looks like
an error when admin go to user settings page just after
updating custom fields in org settings.
Fix this by re-rendering custom fields in user settings
on custom_profile_fields event.
Combines, both portico js and css into one bundle. This for now solve
the issue of an empty js bundle being generated by webpack for the
portico-styles stylesheet.
This commit adds a new field history_public_to_subscribers to the
Stream model, which serves a similar function to the old
settings.PRIVATE_STREAM_HISTORY_FOR_SUBSCRIBERS; we still use that
setting as the default value for new streams to avoid breaking
backwards-compatibility for those users before we are ready with an
actual UI for users to choose directly.
This also comes with a migration to set the value of the new field for
existing streams with an algorithm matching that used at runtime.
With significant changes by Tim Abbott.
This is an initial part of our efforts on #9232.
In a refactor last fall, we changed `set_message_booleans` to mutate
state (specifically, destroying msg.flags in favor of setting
properties like `msg.unread`). This was fine for most code paths, but
the maybe_add_narrowed_messages code path called
`message_store.add_message_metadata` twice (once after talking to the
server to find out whether the messages go into the current narrow),
and so when we extracted set_message_booleans from that, the second
call didn't properly short-circuit.
We fix this by just removing the second call, and also add a comment
warning about the add_message_metadata call there as being dangerous.
Fixes#8184.
The handlebars error message is just for the manual development
environment; this prevents the state of compiling handlebars templates
from run-dev.py from potentially causing the unit tests to fail.
Instead of treating false differently from undefined, our
function is now a regular boolean function, and we limit our
code comments to the one corner case where the true/false
decision is kind of arbitrary and possibly confusing.
The buddy list never includes yourself nor bots, so we
remove the special case handling for those situations.
If we were to put bots or the current user back in the list,
I'm not convinced the old logic was what we'd want in either
case going forward.
For example, we might want to fade bots that aren't subscribed
to public streams, since they might otherwise confuse people,
but then again they would receive messages. And then "yourself"
is a recipient in the technical sense but they're kinda
not and either way it doesn't provide much signal either way.
Rhea Parekh
Vishnu Ks
Angelika Serwa
Tim Abbott
Shubham Padia
Yashashvi Dave
Priyank Patel
Rohitt Vashishtha
Eeshan Garg
Shubham Dhama
guaca
Steve Howell