mirror of
https://github.com/zulip/zulip.git
synced 2025-10-23 04:52:12 +00:00
After b21f533af
, we now update the organization bots
list on receiving realm_user events since non-admins
can also see bots not owned by them in the list.
But the functions to update bot list should be called
only for bot users and not for others, otherwise it
results in an error.
This can be reproduced by first opening the organization
bots list and then just updating the name of the user.
Calling `redraw_bots_list` on receiving "realm_user/add"
event for non bot users will not raise any error but
still we avoid redrawing the whole list when not required.
This commit fixes the code to call functions to update
bot list only when the event is received for a bot.
151 lines
4.5 KiB
JavaScript
151 lines
4.5 KiB
JavaScript
"use strict";
|
|
|
|
const {strict: assert} = require("assert");
|
|
|
|
const {mock_esm, zrequire} = require("./lib/namespace");
|
|
const {run_test} = require("./lib/test");
|
|
|
|
/*
|
|
|
|
Let's step back and review what we've done so far.
|
|
|
|
We've used fairly straightforward testing techniques
|
|
to explore the following modules:
|
|
|
|
filter
|
|
message_store
|
|
narrow_state
|
|
people
|
|
stream_data
|
|
util
|
|
|
|
We haven't gone deep on any of these objects, but if
|
|
you are interested, all of these objects have test
|
|
suites that have 100% line coverage on the modules
|
|
that implement those objects. For example, you can look
|
|
at people.test.js in this directory for more tests on the
|
|
people object.
|
|
|
|
We can quickly review some testing concepts:
|
|
|
|
zrequire - bring in real code
|
|
mock_esm - mock es6 modules
|
|
assert.equal - verify results
|
|
|
|
------
|
|
|
|
Let's talk about our next steps.
|
|
|
|
An app is pretty useless without an actual data source.
|
|
One of the primary ways that a Zulip client gets data
|
|
is through events. (We also get data at page load, and
|
|
we can also ask the server for data, but that's not in
|
|
the scope of this conversation yet.)
|
|
|
|
Chat systems are dynamic. If an admin adds a user, or
|
|
if a user sends a messages, the server immediately sends
|
|
events to all clients so that they can reflect appropriate
|
|
changes in their UI. We're not going to discuss the entire
|
|
"full stack" mechanism here. Instead, we'll focus on
|
|
the client code, starting at the boundary where we
|
|
process events.
|
|
|
|
Let's just get started...
|
|
|
|
*/
|
|
|
|
// We are going to use mock versions of some of our libraries.
|
|
const activity = mock_esm("../src/activity");
|
|
const message_live_update = mock_esm("../src/message_live_update");
|
|
const pm_list = mock_esm("../src/pm_list");
|
|
const settings_users = mock_esm("../src/settings_users");
|
|
|
|
// Use real versions of these modules.
|
|
const people = zrequire("people");
|
|
const server_events_dispatch = zrequire("server_events_dispatch");
|
|
|
|
const bob = {
|
|
email: "bob@example.com",
|
|
user_id: 33,
|
|
full_name: "Bob Roberts",
|
|
is_bot: true,
|
|
};
|
|
|
|
run_test("add users with event", ({override}) => {
|
|
people.init();
|
|
|
|
const event = {
|
|
type: "realm_user",
|
|
op: "add",
|
|
person: bob,
|
|
};
|
|
|
|
assert.ok(!people.is_known_user_id(bob.user_id));
|
|
|
|
// We need to override a stub here before dispatching the event.
|
|
// Keep reading to see how overriding works!
|
|
override(settings_users, "redraw_bots_list", () => {});
|
|
// Let's simulate dispatching our event!
|
|
server_events_dispatch.dispatch_normal_event(event);
|
|
|
|
// And it works!
|
|
assert.ok(people.is_known_user_id(bob.user_id));
|
|
});
|
|
|
|
/*
|
|
|
|
It's actually a little surprising that adding a user does
|
|
not have side effects beyond the people object and the bots list.
|
|
I guess we don't immediately update the buddy list, but that's
|
|
because the buddy list gets updated on the next server
|
|
fetch.
|
|
|
|
Let's try an update next. To make this work, we will want
|
|
to override some more of our stubs.
|
|
|
|
This is where we see a little extra benefit from the
|
|
run_test wrapper. It passes us in an object that we
|
|
can use to override data, and that works within the
|
|
scope of the function.
|
|
|
|
*/
|
|
|
|
run_test("update user with event", ({override}) => {
|
|
people.init();
|
|
people.add_active_user(bob);
|
|
|
|
const new_bob = {
|
|
email: "bob@example.com",
|
|
user_id: bob.user_id,
|
|
full_name: "The Artist Formerly Known as Bob",
|
|
is_bot: true,
|
|
};
|
|
|
|
const event = {
|
|
type: "realm_user",
|
|
op: "update",
|
|
person: new_bob,
|
|
};
|
|
|
|
// We have to stub a few things. We don't want to test
|
|
// the details of these functions, but we do want to
|
|
// verify that they run. Fortunately, the run_test()
|
|
// wrapper will tell us if we override a method that
|
|
// doesn't get called!
|
|
override(activity, "redraw", () => {});
|
|
override(message_live_update, "update_user_full_name", () => {});
|
|
override(pm_list, "update_private_messages", () => {});
|
|
override(settings_users, "update_user_data", () => {});
|
|
override(settings_users, "update_bot_data", () => {});
|
|
|
|
// Dispatch the realm_user/update event, which will update
|
|
// data structures and have other side effects that are
|
|
// stubbed out above.
|
|
server_events_dispatch.dispatch_normal_event(event);
|
|
|
|
const user = people.get_by_user_id(bob.user_id);
|
|
|
|
// Verify that the code actually did its main job:
|
|
assert.equal(user.full_name, "The Artist Formerly Known as Bob");
|
|
});
|