See if there is indeed a way to dispatch chat messages via the store.

[nelsonjchen]

I failed miserably to figure this out. Maybe someone else can figure out a stable way to do this?

If this is implemented, it would remove the need to keep the Breakout Rooms and Chat Window open. The host session will still need to stay in the main meeting though.

[khusmann]

To avoid duplicating what you've already tried here, what did you try on this? store.setState?

[khusmann]

Oh, I see, gotta create a reducer: https://stackoverflow.com/questions/47860820/modify-state-in-redux-devtools-extension

If you really want to change the state of your store, you could assign the store (when it is created via createStore) to window._store and then call window._store.dispatch({type: "...", ...}); directly from the Console.

[nelsonjchen]

Zoom Meeting uses Redux Thunk which makes it possible to dispatch functions. If you replace the dispatch function with a logging passthrough, you'll see functions being passed in.

So it's not all just plain Javascript objects. This makes things a little PITA.

[khusmann]

oh gross.

[nelsonjchen]

They also store some logic directly in React and not the store.

We might be able to get a reference to the functions by opening the required UI if it wasn't already open, getting a reference to the React "callbacks", and then closing the required UI if it wasn't open before. It won't be touching the store, but it'll mean the Windows won't have to stay open.

It's a lot of work for not much return. Maybe just some CSS to disable or hide the UI closing elements is all that's needed.

[khusmann]

Maybe just some CSS to disable or hide the UI closing elements is all that's needed.

This approach fits with the bot's namesake... Besides, the deeper we get the more it'll break when zoom rolls out a change to their client.

In my case, I might want to create a big overlay to hide the entire zoom interface with controls/options, so it doesn't matter what's happening underneath. My plan is to have Hacky host the mtg and run in the background.

[nelsonjchen]

Hmm, another reason I was looking into this was to try to get the bot to operate purely on IDs such as GUIDs and not names.

If there's a name conflict, the bot currently aborts actions for the conflicting users.

[khusmann]

Maybe in the meantime we can scan names and rename if there's conflicts?

[nelsonjchen]

User assignment now happens with UUIDs, ids and so on directly via the internal websocket connection to Zoom. Chat messages are unfortunately still odd and need GUI automation though it's not as invasive as the clicks needed for assignment previously.