Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mute room feature #5731

Merged
merged 40 commits into from
Oct 25, 2022
Merged

Mute room feature #5731

merged 40 commits into from
Oct 25, 2022

Conversation

keianhzo
Copy link
Contributor

@keianhzo keianhzo commented Sep 26, 2022

This features add support for room owners to disable/enable voice and chat for the rest of the users in a room from the room settings panel. In case voice/chat is disable this will only affect to users that are not room owners.
¡
Screen Shot 2022-10-25 at 17 17 48

Related Hubs-Foundation/reticulum#629

Copy link
Contributor

@netpro2k netpro2k left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly lgtm. I focused mostly on just auditing hooks/effects and didn't dig very deep on the actual components or css. Made a few notes, biggest one I would change before shipping is moving the toggling of the actual mic state out of an effect since its pretty weird to have the UI dictating that.

@@ -69,8 +71,16 @@ export function useMicrophone(scene) {
[mediaDevicesManager]
);

useEffect(() => {
if (canVoiceChat) {
mediaDevicesManager.startMicShare({});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't seem right to tie the actual behavior of mic toggling to a react hook. That would mean if no UI happens to be showing the uses useMicrophone this would not be toggled. Should just be handled outside of react land. Probably in MediaDevicesManager in the same spot we are toggling it off on permission changes?

Copy link
Contributor Author

@keianhzo keianhzo Oct 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is mostly because the useMicrophone hook is used in MicSetupModal and the audio popover as that's where we want to conditionally start the mic based on if the voice permission is enabled. I don't have a strong opinion about this but I've moved it back to ui-root as a hook so we can still update the UI without relaying on the useMicrophone hook.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having MicSetupModal have an effect that initially enables the mic makes sense, since that's part of what that screen does. But having it here means this ends up being what is re-enabling the mic in response to permission changes which seems wrong. MediaDeviceManager is what handles turning disabling it when permissions change, so I would think in the same spot it should also handle re-enabling it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two different things. One is mic sharing and another one is mic enabling. Mic sharing just triggers the sharing process and ask for permission if needed. Enabling pauses/resumes the producer so we are effectively sending voice data.

In ui-root we are listening to voice permission updates to start sharing the mic during the different entry steps.
In the MediaDevicesManager we are listening to voice permission updates to pause the mic producer and we rely on the user to manually resume it as it might be tricky if the voice permission is re-enabled by a moderator and that forces the user's mic to open.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right, that makes sense. We should still probably move this effect out of useMicrophone though, since if anything happens to be using it when a permission change happens its going to trigger, since it has canVoiceChat as a dependency, and useCan listens for permission change events.


NotifiablePermissions.forEach(perm => {
if (APP.hub.member_permissions[perm] !== settings.member_permissions[perm]) {
hubChannel.sendMessage({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this isn't just part of hubChannel.updateHub(settings) like the other settings?

Copy link
Contributor Author

@keianhzo keianhzo Oct 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are not sending messages for room permissions updates so we need to manually send these permissions as messages so we also have all the added message info that ret adds to correctly visualize them in the chat. Let me know if I'm missing something.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We send messages for other permission updates like "allow object spawning" and "allow drawing" no? Shouldn't this be the same?

Copy link
Contributor Author

@keianhzo keianhzo Oct 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now we don't send messages for room permissions although if we are doing it for chat/voice probably we should also do for the rest? Maybe that could be part of a follow-up PR as this is how it's in production right now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah seems worth changing on the server side so this can be removed as a special case.

src/components/avatar-audio-source.js Show resolved Hide resolved
src/message-dispatch.js Outdated Show resolved Hide resolved
return <div className={classNames(presenceClasses)}>{this.props.entries.map(this.domForEntry)}</div>;
}
useEffect(() => {
setLogEntries(entries.map(domForEntry));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whats the goal with this effect and logEntries state vs just using entries directly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if I get this one. Entries is the raw message data, logEntries are the DOM elements processed via map.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. But why have an effect and state instead of mapping in render like we were doing before. In either case we still have to render whenever a new entry comes in, so this just seems like an added layer of indirection.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yep, right, yes this is redundant. Removing.

}
export function PresenceLog({ entries, preset, hubId, history, presences, onViewProfile, include, exclude, ...rest }) {
const intl = useIntl();
const isMod = useCan("kick_users");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We seem to be mixing moderator and owner in a few places. Here we are checking of kick_user permission as "mod" but in other spots related to this we are checking if they have the owner role. Is that intended?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in our case we want the room owners to be the ones with voice/chat permissions so I've introduced a useRole hook to check for owner permissions and add some consistency.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be using useRole then?

Copy link
Contributor Author

@keianhzo keianhzo Oct 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did that in 9602625 maybe you are referring to some other one? I think I've moved all of them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah must have been looking at old code.

src/react-components/room/ChatSidebarContainer.js Outdated Show resolved Hide resolved
src/react-components/room/ChatSidebarContainer.js Outdated Show resolved Hide resolved
src/react-components/room/ChatSidebarContainer.js Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
whats new Include this PR on the "What's New" page
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants