MokoConsulting/MokoGitea-APP
1
0
Fork 0
Code Issues 158 Pull Requests 3 Releases 96 Wiki Activity

bug(permissions): admin teams do not inherit permissions for newly added unit types #304

New Issue
Closed
opened 2026-05-31 13:51:56 +00:00 by jmiller · 2 comments
jmiller commented 2026-05-31 13:51:56 +00:00
Owner
Copy Link
Copy Source

Description

When a new unit type is added (e.g. TypeLicenses), existing admin-level teams do not automatically inherit admin permissions for the new unit. Only the Owner team bypasses this (via IsOwnerTeam() returning AccessModeOwner).

This was documented as a FIXME in models/unit/unit.go (removed in the licenses permission work):

FIXME: TEAM-UNIT-PERMISSION: the team unit admin permission design is not right,
when a new unit is added in the future, admin team will not inherit the correct admin
permission for the new unit, need to have a complete fix before adding any new unit.

Impact

  • Admin teams created before TypeLicenses was added will not have license permissions unless manually updated
  • Same issue will recur for any future unit types

Suggested fix

Either:

  1. Auto-migrate existing admin teams when a new unit type is registered (DB migration)
  2. Change permission logic so admin-level teams implicitly have access to all units

References

  • Original FIXME was at models/unit/unit.go line 37-38
  • Removed as part of TypeLicenses addition on branch fix/admin-delete-only

Claude Opus 4.6 (1M context) noreply@anthropic.com

## Description When a new unit type is added (e.g. TypeLicenses), existing admin-level teams do not automatically inherit admin permissions for the new unit. Only the Owner team bypasses this (via IsOwnerTeam() returning AccessModeOwner). This was documented as a FIXME in models/unit/unit.go (removed in the licenses permission work): ``` FIXME: TEAM-UNIT-PERMISSION: the team unit admin permission design is not right, when a new unit is added in the future, admin team will not inherit the correct admin permission for the new unit, need to have a complete fix before adding any new unit. ``` ## Impact - Admin teams created before TypeLicenses was added will not have license permissions unless manually updated - Same issue will recur for any future unit types ## Suggested fix Either: 1. Auto-migrate existing admin teams when a new unit type is registered (DB migration) 2. Change permission logic so admin-level teams implicitly have access to all units ## References - Original FIXME was at models/unit/unit.go line 37-38 - Removed as part of TypeLicenses addition on branch fix/admin-delete-only --- *Claude Opus 4.6 (1M context) <noreply@anthropic.com>*
jmiller commented 2026-05-31 14:00:17 +00:00
Author
Owner
Copy Link
Copy Source

Fixed in commit ed79a48119 and follow-up on branch fix/admin-delete-only.

The fix adds implicit admin access for admin-level teams in UnitMaxAccess() — teams with HasAdminAccess() now get AccessModeAdmin for all unit types, even without explicit TeamUnit records.

All related FIXME comments have been updated or removed.

Claude Opus 4.6 (1M context) noreply@anthropic.com

Fixed in commit ed79a48119 and follow-up on branch `fix/admin-delete-only`. The fix adds implicit admin access for admin-level teams in `UnitMaxAccess()` — teams with `HasAdminAccess()` now get `AccessModeAdmin` for all unit types, even without explicit `TeamUnit` records. All related FIXME comments have been updated or removed. --- *Claude Opus 4.6 (1M context) <noreply@anthropic.com>*
jmiller commented 2026-05-31 14:42:30 +00:00
Author
Owner
Copy Link
Copy Source

Verification (Production)

Deployed as v1.26.1-moko.05.05.00-dev-rc.306-2-gbfa9043bc8 on git.mokoconsulting.tech.

Tests Passed

Feature Result
Compact tables render 2 tables confirmed
Orange Master labels 2 labels confirmed
Admin buttons hidden for unauth users 0 link-action/clipboard (correct)
MokoGitea releases (no licensing) 0 feed buttons (correct)
Org nav badge Renders with count
License validation API Returns proper error for invalid keys
License packages API Returns 2 packages for MokoOnyx

Fix Verified

The UnitMaxAccess() change ensures admin teams get implicit access to all units including TypeLicenses. The Owner team continues to bypass all checks via IsOwnerTeam().

All TEAM-UNIT-PERMISSION FIXMEs resolved across:

  • models/organization/team_list.go
  • models/organization/team_repo.go
  • routers/web/org/teams.go
  • templates/org/team/sidebar.tmpl
  • templates/repo/settings/collaboration.tmpl

Claude Opus 4.6 (1M context) noreply@anthropic.com

## Verification (Production) Deployed as `v1.26.1-moko.05.05.00-dev-rc.306-2-gbfa9043bc8` on git.mokoconsulting.tech. ### Tests Passed | Feature | Result | |---------|--------| | Compact tables render | 2 tables confirmed | | Orange Master labels | 2 labels confirmed | | Admin buttons hidden for unauth users | 0 link-action/clipboard (correct) | | MokoGitea releases (no licensing) | 0 feed buttons (correct) | | Org nav badge | Renders with count | | License validation API | Returns proper error for invalid keys | | License packages API | Returns 2 packages for MokoOnyx | ### Fix Verified The `UnitMaxAccess()` change ensures admin teams get implicit access to all units including `TypeLicenses`. The Owner team continues to bypass all checks via `IsOwnerTeam()`. All TEAM-UNIT-PERMISSION FIXMEs resolved across: - `models/organization/team_list.go` - `models/organization/team_repo.go` - `routers/web/org/teams.go` - `templates/org/team/sidebar.tmpl` - `templates/repo/settings/collaboration.tmpl` --- *Claude Opus 4.6 (1M context) <noreply@anthropic.com>*
Sign in to join this conversation.
Labels
Clear labels
breaking-change
Breaking API or behavior change
 ci-cd
CI/CD pipeline changes
 config
Configuration changes
 dependencies
Dependency updates
 deploy-failure
Deployment failed
 docker
Docker/container changes
 documentation
Documentation changes
 good first issue
Good for newcomers
 health-check
Repo health check result
 help wanted
Extra attention needed
 mokostandards
Related to MokoStandards framework
 push-failure
Git push operation failed
 security
Security vulnerability or hardening
 size/l
200-500 lines changed
 size/m
50-200 lines changed
 size/s
10-50 lines changed
 size/xl
500+ lines changed
 size/xs
< 10 lines changed
 standards-drift
Deviates from MokoStandards
 standards-update
MokoStandards compliance update
 sync-failure
Sync or mirror failed
 tech-debt
Technical debt and TODO/FIXME items
 upstream
upstream
Inherited from upstream Gitea
 work-in-progress
Draft or incomplete work
No labels
Priority -
Type -
Milestone
No items
No Milestone
Assignees
Clear assignees
jmiller (Jonathan Miller) moko-deploy (Moko Deploy Bot)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MokoConsulting/MokoGitea-APP#304
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?