Add channel permission to completely disable all access to queue panel

rainbownapkin commented

2025-09-16 05:15:03 -04:00

(Migrated from gitlab.com)

No description provided.

rainbownapkin commented

2025-09-16 05:15:03 -04:00

(Migrated from gitlab.com)

added #164 as parent issue

rainbownapkin added a new dependency 2025-09-25 05:38:28 -04:00

#164 Tweaks and Fixes

rainbownapkin commented

2025-10-21 08:18:37 -04:00

Owner

per-user per-perm rank checks for queueing actions are more easily implemented in the main channel namespace as that has easier access to relevant user information.

At that same time, looping through, calculating rank, and individually emitting queue for each change feels incredibly clunky and wasteful.

Maybe meet in-between, keep queue-command in the channel namespace, but TX base queue data to clients over a dedicated namespace, that authenticates them on join, avoiding the need to authenticate for each tx, allowing us to just use .broadcast() to send queue data without dumping it to people who shouldn't have it, or fucking up queue command rank checks.

per-user per-perm rank checks for queueing actions are more easily implemented in the main channel namespace as that has easier access to relevant user information. At that same time, looping through, calculating rank, and individually emitting queue for each change feels incredibly clunky and wasteful. Maybe meet in-between, keep queue-command in the channel namespace, but TX base queue data to clients over a dedicated namespace, that authenticates them on join, avoiding the need to authenticate for each tx, allowing us to just use .broadcast() to send queue data without dumping it to people who shouldn't have it, or fucking up queue command rank checks.

rainbownapkin commented

2025-10-21 19:35:59 -04:00

Owner

Currently experimenting with whether or not the solution above is worth the extra authentication upon connection...

rainbownapkin commented

2025-10-21 19:42:10 -04:00

Owner

In a fucked up way it might be easier to give channels a second room (channel-queue).

Maybe it makes more sense than it's own name space since channels will be tied together, and clients have no reason to know the difference between the rooms?

Feels a little dirty splitting channel logic by room string formatting, and not namespaces.

In a fucked up way it might be easier to give channels a second room (channel-queue). Maybe it makes more sense than it's own name space since channels will be tied together, and clients have no reason to know the difference between the rooms? Feels a little dirty splitting channel logic by room string formatting, and not namespaces.

rainbownapkin commented

2025-10-21 19:47:55 -04:00

Owner

We're already using a separate namespace for PM's, and are planning another for games. We should make a base aux-server class that exists as a child-server to the channel manager with it's own namespace.

Both the pmHandler and queue classes could extend it, re-using the same base authentication logic, adding to it where needed.

We're already using a separate namespace for PM's, and are planning another for games. We should make a base aux-server class that exists as a child-server to the channel manager with it's own namespace. Both the pmHandler and queue classes could extend it, re-using the same base authentication logic, adding to it where needed.

rainbownapkin commented

2025-10-22 05:03:03 -04:00

Owner

Split pmHandler to create auxServer class for easy creation of server classes auxiliary to the channel: 597a984e46

Created dedicated queue broadcast namespace, to make authorized queue broadcasts as painless as possible: 5eb307bb9e

Moved server-side queue transmission to it's own protected namespace: 6d16ac2353

Split pmHandler to create auxServer class for easy creation of server classes auxiliary to the channel: 597a984e46 Created dedicated queue broadcast namespace, to make authorized queue broadcasts as painless as possible: 5eb307bb9e Moved server-side queue transmission to it's own protected namespace: 6d16ac2353

rainbownapkin closed this issue

2025-10-22 05:03:03 -04:00

rainbownapkin reopened this issue

2025-10-22 05:03:08 -04:00

rainbownapkin commented

2025-10-22 05:03:24 -04:00

Owner

still need a lil work on the ux

rainbownapkin commented

2025-10-22 05:38:07 -04:00

Owner

Queue icon now only shows when readSchedule is allowed: 57787f81e7

Queue icon now only shows when readSchedule is allowed: 57787f81e7

rainbownapkin closed this issue

2025-10-22 05:38:07 -04:00

Add channel permission to completely disable all access to queue panel #165