2024-06-21 21:26:55 +02:00
|
|
|
import type {z} from "zod";
|
ts: Migrate `bot_data.js` to TypeScript.
Add type annotations. Create custom types for Bot and Service.
Add zod data validation for incoming bot data from server.
Based on `zerver/openapi/zulip.yaml` description, `add` operation
(`op`) carries data that follows `Bot` structure. So taking
reference from `bot` structure, I create `ServerAddBotData` zod
schema and infer its type. Similarly, `update` operation carries
data that follows `BasicBot`, so I create `ServerUpdateBotData`.
Note that `Bot` inherits from `BasicBot`.
`zerver/openapi/zulip.yaml` describes that `services` in `BasicBot`
can be one of two objects, one with `{base_url, token, interface}`,
another with `{service_name, config_data}`. Therefore, I create
two corresponding schema and infer their types.
Fix two test cases `bot_data.test.js` and `settings_bots.test.js`
whose synthetic objects should have had followed the schema.
2023-07-21 10:41:35 +02:00
|
|
|
|
2024-06-21 21:26:55 +02:00
|
|
|
import {server_add_bot_schema, server_update_bot_schema, services_schema} from "./bot_types";
|
ts: Migrate `bot_data.js` to TypeScript.
Add type annotations. Create custom types for Bot and Service.
Add zod data validation for incoming bot data from server.
Based on `zerver/openapi/zulip.yaml` description, `add` operation
(`op`) carries data that follows `Bot` structure. So taking
reference from `bot` structure, I create `ServerAddBotData` zod
schema and infer its type. Similarly, `update` operation carries
data that follows `BasicBot`, so I create `ServerUpdateBotData`.
Note that `Bot` inherits from `BasicBot`.
`zerver/openapi/zulip.yaml` describes that `services` in `BasicBot`
can be one of two objects, one with `{base_url, token, interface}`,
another with `{service_name, config_data}`. Therefore, I create
two corresponding schema and infer their types.
Fix two test cases `bot_data.test.js` and `settings_bots.test.js`
whose synthetic objects should have had followed the schema.
2023-07-21 10:41:35 +02:00
|
|
|
import * as people from "./people";
|
2024-06-21 21:26:55 +02:00
|
|
|
import type {StateData} from "./state_data";
|
ts: Migrate `bot_data.js` to TypeScript.
Add type annotations. Create custom types for Bot and Service.
Add zod data validation for incoming bot data from server.
Based on `zerver/openapi/zulip.yaml` description, `add` operation
(`op`) carries data that follows `Bot` structure. So taking
reference from `bot` structure, I create `ServerAddBotData` zod
schema and infer its type. Similarly, `update` operation carries
data that follows `BasicBot`, so I create `ServerUpdateBotData`.
Note that `Bot` inherits from `BasicBot`.
`zerver/openapi/zulip.yaml` describes that `services` in `BasicBot`
can be one of two objects, one with `{base_url, token, interface}`,
another with `{service_name, config_data}`. Therefore, I create
two corresponding schema and infer their types.
Fix two test cases `bot_data.test.js` and `settings_bots.test.js`
whose synthetic objects should have had followed the schema.
2023-07-21 10:41:35 +02:00
|
|
|
|
|
|
|
export type ServerUpdateBotData = z.infer<typeof server_update_bot_schema>;
|
|
|
|
export type ServerAddBotData = z.infer<typeof server_add_bot_schema>;
|
|
|
|
export type Bot = Omit<ServerAddBotData, "services">;
|
|
|
|
|
|
|
|
export type Services = z.infer<typeof services_schema>;
|
|
|
|
|
|
|
|
const bots = new Map<number, Bot>();
|
|
|
|
const services = new Map<number, Services>();
|
|
|
|
|
|
|
|
export function all_user_ids(): number[] {
|
|
|
|
return [...bots.keys()];
|
|
|
|
}
|
|
|
|
|
|
|
|
export function add(bot_data: ServerAddBotData): void {
|
2024-06-21 21:26:55 +02:00
|
|
|
// TODO/typescript: Move validation to the caller when
|
|
|
|
// server_events_dispatch.js is converted to TypeScript.
|
ts: Migrate `bot_data.js` to TypeScript.
Add type annotations. Create custom types for Bot and Service.
Add zod data validation for incoming bot data from server.
Based on `zerver/openapi/zulip.yaml` description, `add` operation
(`op`) carries data that follows `Bot` structure. So taking
reference from `bot` structure, I create `ServerAddBotData` zod
schema and infer its type. Similarly, `update` operation carries
data that follows `BasicBot`, so I create `ServerUpdateBotData`.
Note that `Bot` inherits from `BasicBot`.
`zerver/openapi/zulip.yaml` describes that `services` in `BasicBot`
can be one of two objects, one with `{base_url, token, interface}`,
another with `{service_name, config_data}`. Therefore, I create
two corresponding schema and infer their types.
Fix two test cases `bot_data.test.js` and `settings_bots.test.js`
whose synthetic objects should have had followed the schema.
2023-07-21 10:41:35 +02:00
|
|
|
const {services: bot_services, ...clean_bot} = server_add_bot_schema.parse(bot_data);
|
|
|
|
bots.set(clean_bot.user_id, clean_bot);
|
|
|
|
|
|
|
|
services.set(clean_bot.user_id, bot_services);
|
|
|
|
}
|
|
|
|
|
|
|
|
export function del(bot_id: number): void {
|
|
|
|
bots.delete(bot_id);
|
|
|
|
services.delete(bot_id);
|
|
|
|
}
|
|
|
|
|
|
|
|
export function update(bot_id: number, bot_update: ServerUpdateBotData): void {
|
|
|
|
const bot = bots.get(bot_id)!;
|
2024-06-21 21:26:55 +02:00
|
|
|
// TODO/typescript: Move validation to the caller when
|
|
|
|
// server_events_dispatch.js is converted to TypeScript.
|
ts: Migrate `bot_data.js` to TypeScript.
Add type annotations. Create custom types for Bot and Service.
Add zod data validation for incoming bot data from server.
Based on `zerver/openapi/zulip.yaml` description, `add` operation
(`op`) carries data that follows `Bot` structure. So taking
reference from `bot` structure, I create `ServerAddBotData` zod
schema and infer its type. Similarly, `update` operation carries
data that follows `BasicBot`, so I create `ServerUpdateBotData`.
Note that `Bot` inherits from `BasicBot`.
`zerver/openapi/zulip.yaml` describes that `services` in `BasicBot`
can be one of two objects, one with `{base_url, token, interface}`,
another with `{service_name, config_data}`. Therefore, I create
two corresponding schema and infer their types.
Fix two test cases `bot_data.test.js` and `settings_bots.test.js`
whose synthetic objects should have had followed the schema.
2023-07-21 10:41:35 +02:00
|
|
|
Object.assign(bot, server_update_bot_schema.deepPartial().parse(bot_update));
|
|
|
|
|
|
|
|
// We currently only support one service per bot.
|
|
|
|
const service = services.get(bot_id)![0];
|
2024-05-30 19:07:58 +02:00
|
|
|
if (
|
|
|
|
service !== undefined &&
|
|
|
|
bot_update.services !== undefined &&
|
|
|
|
bot_update.services.length > 0
|
|
|
|
) {
|
ts: Migrate `bot_data.js` to TypeScript.
Add type annotations. Create custom types for Bot and Service.
Add zod data validation for incoming bot data from server.
Based on `zerver/openapi/zulip.yaml` description, `add` operation
(`op`) carries data that follows `Bot` structure. So taking
reference from `bot` structure, I create `ServerAddBotData` zod
schema and infer its type. Similarly, `update` operation carries
data that follows `BasicBot`, so I create `ServerUpdateBotData`.
Note that `Bot` inherits from `BasicBot`.
`zerver/openapi/zulip.yaml` describes that `services` in `BasicBot`
can be one of two objects, one with `{base_url, token, interface}`,
another with `{service_name, config_data}`. Therefore, I create
two corresponding schema and infer their types.
Fix two test cases `bot_data.test.js` and `settings_bots.test.js`
whose synthetic objects should have had followed the schema.
2023-07-21 10:41:35 +02:00
|
|
|
Object.assign(service, services_schema.parse(bot_update.services)[0]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
export function get_all_bots_for_current_user(): Bot[] {
|
|
|
|
const ret = [];
|
|
|
|
for (const bot of bots.values()) {
|
2023-08-22 03:53:15 +02:00
|
|
|
if (bot.owner_id !== null && people.is_my_user_id(bot.owner_id)) {
|
ts: Migrate `bot_data.js` to TypeScript.
Add type annotations. Create custom types for Bot and Service.
Add zod data validation for incoming bot data from server.
Based on `zerver/openapi/zulip.yaml` description, `add` operation
(`op`) carries data that follows `Bot` structure. So taking
reference from `bot` structure, I create `ServerAddBotData` zod
schema and infer its type. Similarly, `update` operation carries
data that follows `BasicBot`, so I create `ServerUpdateBotData`.
Note that `Bot` inherits from `BasicBot`.
`zerver/openapi/zulip.yaml` describes that `services` in `BasicBot`
can be one of two objects, one with `{base_url, token, interface}`,
another with `{service_name, config_data}`. Therefore, I create
two corresponding schema and infer their types.
Fix two test cases `bot_data.test.js` and `settings_bots.test.js`
whose synthetic objects should have had followed the schema.
2023-07-21 10:41:35 +02:00
|
|
|
ret.push(bot);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
export function get_editable(): Bot[] {
|
|
|
|
const ret = [];
|
|
|
|
for (const bot of bots.values()) {
|
2023-08-22 03:53:15 +02:00
|
|
|
if (bot.is_active && bot.owner_id !== null && people.is_my_user_id(bot.owner_id)) {
|
ts: Migrate `bot_data.js` to TypeScript.
Add type annotations. Create custom types for Bot and Service.
Add zod data validation for incoming bot data from server.
Based on `zerver/openapi/zulip.yaml` description, `add` operation
(`op`) carries data that follows `Bot` structure. So taking
reference from `bot` structure, I create `ServerAddBotData` zod
schema and infer its type. Similarly, `update` operation carries
data that follows `BasicBot`, so I create `ServerUpdateBotData`.
Note that `Bot` inherits from `BasicBot`.
`zerver/openapi/zulip.yaml` describes that `services` in `BasicBot`
can be one of two objects, one with `{base_url, token, interface}`,
another with `{service_name, config_data}`. Therefore, I create
two corresponding schema and infer their types.
Fix two test cases `bot_data.test.js` and `settings_bots.test.js`
whose synthetic objects should have had followed the schema.
2023-07-21 10:41:35 +02:00
|
|
|
ret.push(bot);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
export function get_all_bots_owned_by_user(user_id: number): Bot[] {
|
|
|
|
const ret = [];
|
|
|
|
for (const bot of bots.values()) {
|
|
|
|
if (bot.owner_id === user_id && bot.is_active) {
|
|
|
|
ret.push(bot);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
export function get(bot_id: number): Bot | undefined {
|
|
|
|
return bots.get(bot_id);
|
|
|
|
}
|
|
|
|
|
|
|
|
export function get_services(bot_id: number): Services | undefined {
|
|
|
|
return services.get(bot_id);
|
|
|
|
}
|
|
|
|
|
2024-06-21 21:26:55 +02:00
|
|
|
export function initialize(params: StateData["bot"]): void {
|
ts: Migrate `bot_data.js` to TypeScript.
Add type annotations. Create custom types for Bot and Service.
Add zod data validation for incoming bot data from server.
Based on `zerver/openapi/zulip.yaml` description, `add` operation
(`op`) carries data that follows `Bot` structure. So taking
reference from `bot` structure, I create `ServerAddBotData` zod
schema and infer its type. Similarly, `update` operation carries
data that follows `BasicBot`, so I create `ServerUpdateBotData`.
Note that `Bot` inherits from `BasicBot`.
`zerver/openapi/zulip.yaml` describes that `services` in `BasicBot`
can be one of two objects, one with `{base_url, token, interface}`,
another with `{service_name, config_data}`. Therefore, I create
two corresponding schema and infer their types.
Fix two test cases `bot_data.test.js` and `settings_bots.test.js`
whose synthetic objects should have had followed the schema.
2023-07-21 10:41:35 +02:00
|
|
|
bots.clear();
|
|
|
|
for (const bot of params.realm_bots) {
|
|
|
|
add(bot);
|
|
|
|
}
|
|
|
|
}
|