Edit history

Two related bugs in POST /guilds/:id/channels, found on a self-hosted instance while building a flow where members create their own channel inside a single category. A ready patch (2 commits + integration test, ~25 lines) is on my fork — the repo does not accept pull requests from forks, so I'm filing it here: Branch: https://github.com/DevEduardoSouza/fluxer/tree/upstream/category-scoped-channel-creation Diff: https://github.com/fluxerapp/fluxer/compare/main...DevEduardoSouza:fluxer:upstream/category-scoped-channel-creation

1. Category overwrites are ignored when creating a channel

GuildChannelService.createChannel (fluxer_api/src/api/guild/services/GuildChannelService.ts) checks MANAGE_CHANNELS via gatewayService.checkPermission without a channelId, and ChannelOperationsService.createChannel does the same for MANAGE_ROLES when the body carries permission_overwrites. Both are therefore guild-level checks, so granting Manage Channels to a role through an overwrite on a category does not let members of that role create channels inside it (403), even though the gateway already knows how to resolve category overwrites (checkPermission accepts channelId) and edit/delete on existing channels are already checked at channel level. Fix: pass the parent category as channelId in both checks. Without parent_id nothing changes. The existing guard that requested overwrites must be a subset of the creator's permissions in the category (getUserPermissions({channelId: parentId})) is untouched, so no privilege escalation (covered by tests: root/other category → 403, ADMINISTRATOR in overwrite → 403, owner unaffected, another member with the same role cannot edit the created channel).

2. Configured max_channels_per_category / max_guild_channels are not applied on creation

ensureCategoryHasCapacity / ensureGuildHasCapacity in fluxer_api/src/api/guild/services/channel/ChannelOperationsService.ts call resolveLimitSafe without an evaluationContext, which defaults to 'user'. Since both keys are guild-scoped (LIMIT_KEY_SCOPES), shouldApplyLimitForContext skips every rule and the defaults (50 / 500) are always enforced, regardless of what is configured in /admin/limit-config/update. The move/edit path (channel_data/ChannelOperationsService.ensureCategoryHasCapacity) already passes evaluationContext: 'guild', so behaviour is inconsistent between the two paths. Repro: raise max_channels_per_category to 500 in the admin limit config → the 51st channel in a category still fails with MAX_CATEGORY_CHANNELS (50). Fix: pass 'guild' to resolveLimitSafe in both capacity checks.

Verification

• New fluxer_api/src/api/channel/tests/CategoryScopedChannelCreation.test.ts (7 cases) + existing ChannelOperationPermissions, ChannelPermissionOverwrites, ChannelOperationValidation → all passing on top of current main (5ee59c46); typecheck clean.
• Manual on docker-compose self-host with an image built from the branch: both scenarios above behave as described before/after.

Happy to adjust anything (naming, splitting into two issues, test placement) if you'd like to pick it up.