If we get invalid events related to stream subscribers, we now
exit earlier to prevent ugly tracebacks. We may eventually
want to upgrade some of these warnings to errors, once we fix some
of our live-update bugs. In particular, we don't yet live-update
users when streams go from private to public, so if you add/remove
subscribers to a newly-public stream that a user still thinks is
private, they will not be able to handle the event through no
fault of the codepath that happens during the add/remove.
This currently only supports this in emoji reactions, not in actual
emoji in message bodies, but it's a great start for people who want a
text-only view.
Tweaked to update the text by tabbott.
Fixes#3169.
I noticed while reviewing #3807 that we still haven't fixed this;
because timestamps are primarily displayed in the message view, fixing
this is trivial.
Add neccesary UI in #administration and #settings for
changing the bot owner. The bot owner select control
is rendered dynamically in order to avoid performance
issues in case of large number of users.
Fixes: #2719.
When an admin deactivate a stream, we now remove the
appropriate row from the default streams tables for other
folks viewing default streams in the admin tables.
This is a fairly risky, invasive change that speeds up
stream deactivation by no longer sending subscription/remove
events for individual subscribers to all of the clients who
care about a stream. Instead, we let the client handle the
stream deactivation on a coarser level.
The back end changes here are pretty straightforward.
On the front end we handle stream deactivations by removing the
stream (as needed) from the streams sidebar and/or the stream
settings page. We also remove the stream from the internal data
structures.
There may be some edge cases where live updates don't handle
everything, such as if you are about to compose a message to a
stream that has been deactivated. These should be rare, as admins
generally deactivate streams that have been dormant, and they
should be recoverable either by getting proper error handling when
you try to send to the stream or via reload.
For our user administration, we now primarily work with user ids
that get put into data-user-id attributes. We still put emails in the
tags to make our Casper tests easy to maintain.
This requires a minor change to the back end to pass down user ids
for the /users endpoint (in get_members_backend).
If we get a realm_user update for a user that is **not**
changing their full name, we no longer call
admin.update_user_full_name().
This was probably a fairly minor bug.
This commit replaces the placeholder "clipboard" button with a reaction button.
This is done on any message that can't be edited. Also, on messages sent by
the user the actions popover (toggled by the down chevron icon) contains
an option to add a reaction.
When clicked, a popover with a search bar and a list of emojis is displayed.
If the right sidebar is collapsed (the viewport is small), the popover is placed
to the left of the button.
Focus is set to the search bar. Typing in the search bar filters emojis.
Emojis with which the user has reacted to this message are highlighted.
Clicking them sends an API request to remove that reaction.
Clicking on non-highlighted emojis sends an API request to add a reaction.
When the popover loses focus it is closed.
The frontend listens for reaction events. When an add-reaction event is
received, the emoji is displayed at the bottom of the message with a
count initialized to 1. If there was an existing reaction to the message with
the same emoji, the count is incremented.
Old messages fetched from the server contain reactions.
They are displayed (along with title and count) at the bottom
of each message.
When clicking the emoji reaction at the bottom of the message, if the
user has already reacted with that emoji to this message, the reaction
is removed and the count is decremented. Otherwise, a reaction is added
and the count is incremented.
Hovering over the emoji reaction at the bottom of the message displays
a list of users who have reacted with this emoji along with the
emoji name.
Hovering over the emoji reactions at the bottom of the message displays
a button to add a reaction.
Fixes#541.
This commit changes people.remove() to be people.deactivate(),
and it fixes a bug where deactivating users was causing tracebacks
in the PM list if somebody had PM'ed the deactivated user
recently.
This adds support for only allowing normal users with account age
equal or greater than a "waiting period" threshold to create streams;
this is useful for open organizations that want new members to
understand the community before creating streams.
If create_stream_by_admins_only setting is set to True, only admin users
were able to create streams. Now normal users with account age greater
or equal than waiting period threshold can also create streams.
Account age is defined as number of days passed since the user had
created his account.
Fixes: #2308.
Tweaked by tabbott to clean up the actual can_create_streams logic and
the tests.
I make server_events slimmer by not handling a specific
property when subs.update_subscription_properties() should
do all the dispatching (and mostly did).
And then since update_subscription_properties() has
a "sub" already, I can call directly to stream_list code
and remove a function from subs.js. Since I lose the
wrapper function in subs.js, I rename the stream_list
function as part of this commit.
The only code that gets slightly heavier here is that
we have two lines in the 'pin_to_top' case instead of one.
There are no modern browsers that do not have built in JSON parsing
abilities. We do not need $.parseJSON as it now just serves as a call
to JSON.parse.
Extract dispatch_normal_event() from the inner
function dispatch_event() in get_events_success()
in server_events.js. Also, alphabetize the cases in
the switch statement. This starts to address #1541,
but see the discussion on the ticket for how we can
continue to clean up our event dispatching.
Adds a new field default language in the zerver_realm model.
This realm level default language will be used as default language
for newly created users. Realm level default language can be
changed from the administration page.
Fixes#1372.
This is controlled through the admin tab and a new field in the Realms
table. This mirrors the behavior of the old hardcoded setting
feature_flags.disable_message_editing. Partially resolves#903.
Move recenter_pointer_on_display, suppress_scroll_pointer_update,
fast_forward_pointer, furthest_read, and server_furthest_read to
a new pointer module in pointer.js.
It's always been the case that in production, Tornado dumps all the
event queues when shut down so that they can be reloaded by the
replacement Tornado process. This never worked in development because
the codepath for auto-reload didn't go through either a signal or
sys.exit (it re-execs the process instead).
This meant that we didn't have a mechanism for testing the event queue
dump/load functionality in the development environment. We fix this
by adding such dumping/loading. However, this breaks the automatic
reloading of open browser windows on a server restart, so we add that
back in by adjusting the special `restart` events to pass a special
`immediate` flag when used in development.
This also has the benefit of removing the "Bad event queue" errors one
would get on every file save induced restart on the Python console.
Apparently it isn't always the case that removal of jquery and the DOM
prevents cleanup_event_queue from being called via the postunload
hook, so add a check to avoid it being double-called.
Previously, the browser might restart a get_events operation even
while it was in the middle of executing a `DELETE /events` query to
cause its event queue to be de-allocated. This was a rare race
condition when we weren't notifying clients when event queues were
de-allocated, but this will become a common case in the next commit.
Include new field on Realm to control whether e-mail invitations are required
separately from whether the e-mail domain must match.
Allow control of these fields from admin panel.
Update logic in registration page to use these fields.
(imported from commit edc7f0a4c43b57361d9349e258ad4f217b426f88)
When an event queue expires the client is in an unknown state and trying
to restore state during a reload will keep the incorrect state.
(imported from commit e0828626142029aecd86a7c4cec8c77d261eb3eb)
This doesn't affect code when not in testing. It shaves 7 seconds off of casper
test time on my machine.
(imported from commit 7e27fa781bcf16f36d9c8f058427ba57c41068bd)
Have the server send down the stream's id for removal
events, and have the client use that id to look up the
stream in its internal data structures. This sets the
stage for eventually just sending the stream id (and not
the stream name) down to clients, once all our clients
are ready to use the stream id.
(imported from commit 922516c98fb79ffad8ae7da0396646663ca54fd0)
Our overall guideline is the type names for events are singular, and the list of
events of that type are plural. 'subscriptions' was not following this guideline
and (potentially as a result) had a bug where it was impossible for clients to explicitly
subscribe to subscription change events properly.
(imported from commit 7b3162141fd673746e0489199966c29ea32ee876)
Chrome was showing a memory leak after many auto-reloads. Emptying the
the collections and removing the event listeners reduces the severity.
Before this change 40 reloads would would grow to about 140MB, now it
stays around 50MB.
(imported from commit 55fbeff9bdd0363bb95929f2981a2de238ff35d8)
Add try/catch blocks to get_updates_success and send a blueslip error on
errors we catch. This will let get_updates_success return successfully
so that the next call to get_updates will start immediately.
(imported from commit 44d8b85d9d8e930a5552a5fbf4af1d0e5e8c07e8)
Both pointer and last are fields that were removed when we changed the
protocol to use events like a year ago.
This conveniently allows us to stop exporting get_updates_params to
other modules.
(imported from commit 13651ee240ce6e1bafb241b185e5ef653c348cdf)
Previously, we waited until we'd fully loaded the home view to start
calling get_events, which:
(A) didn't make sense non-message related events
(B) resulted in our throwing "get_updates not started" errors when
users sent a message before the home view was fully loaded.
This commit only fixes problem (B); to fix problem (A) we will need to
change the event capture code to only capture some events.
(imported from commit 2aacd6bdfd1e7d7707e3a724f1fde7da4a556538)
Note that this makes the event fire after the home view has messages
loaded all the way to current; previously it only waited for the first
batch of messages to load.
(imported from commit a5c408ea0136c761f4cc77e8be4977b13acc6d77)
Steve Howell
Sourav Badami
Tim Abbott
Harshit Bansal
K.Kanakhin
Elliott Jin
Arpith Siromoney
paxapy
vaibhav
Rafid Aslam
Bojidar Marinov
lonerz
Tommy Ip
Vladislav Manchev
umkay
Umair Khan
Brock Whittaker
Rag Sagar
Rishi Gupta
Kartik Maji
Vishnu Ks
Aristeidis Fkiaras
Tim Abbott
Dylan Dumesnil
David Roe
Tim Abbott
Kate Buckner
Jason Michalski
Zev Benjamin
Jessica McKellar
Steve Howell
Leo Franchi