feat: Enterprise Wiki Expansion & Governance Strategy #79

New Issue

2026-05-13T00:36:01Z

jmiller commented

2026-05-13 00:36:01 +00:00

Summary

Enhance the MokoGitea wiki system with page-level permissions and granular access control, enabling different visibility levels for individual wiki pages.

Requirements

Page-Level Permissions

Each wiki page can be set to one of: public, members-only, or private (specific teams/users)
Permission stored as frontmatter or metadata in the wiki page
Default permission inherited from repo visibility
UI in wiki editor to set page visibility
Unauthorized users see a "no access" page instead of content

Granular Permissions

Team-based wiki access: specific teams can edit specific pages/sections
Read vs write permissions per page
Wiki admin role: can manage all pages and permissions
Audit log for wiki permission changes

Integration with .mokogitea Org Repo

The .mokogitea org-level repo houses org wiki and profiles
Folder structure: private/, members/, public/ with README/profile.md files
Content in these folders displayed in different parts of MokoGitea based on viewer access level
Wiki page settings respect public/member-only visibility

Current Behavior

Wiki pages inherit repo-level visibility � either all public or all private. No per-page control exists.

Design Considerations

Permission metadata should be stored in a way that survives git clone/push (frontmatter preferred)
Need to handle search indexing � private pages should not appear in public search results
Consider caching implications for mixed-visibility wikis
Git-based storage means permissions need enforcement at the application layer, not the git layer

Authored-by: Moko Consulting

## Summary Enhance the MokoGitea wiki system with page-level permissions and granular access control, enabling different visibility levels for individual wiki pages. ## Requirements ### Page-Level Permissions - [ ] Each wiki page can be set to one of: **public**, **members-only**, or **private** (specific teams/users) - [ ] Permission stored as frontmatter or metadata in the wiki page - [ ] Default permission inherited from repo visibility - [ ] UI in wiki editor to set page visibility - [ ] Unauthorized users see a "no access" page instead of content ### Granular Permissions - [ ] Team-based wiki access: specific teams can edit specific pages/sections - [ ] Read vs write permissions per page - [ ] Wiki admin role: can manage all pages and permissions - [ ] Audit log for wiki permission changes ### Integration with .mokogitea Org Repo - [ ] The `.mokogitea` org-level repo houses org wiki and profiles - [ ] Folder structure: `private/`, `members/`, `public/` with README/profile.md files - [ ] Content in these folders displayed in different parts of MokoGitea based on viewer access level - [ ] Wiki page settings respect public/member-only visibility ## Current Behavior Wiki pages inherit repo-level visibility � either all public or all private. No per-page control exists. ## Design Considerations - Permission metadata should be stored in a way that survives git clone/push (frontmatter preferred) - Need to handle search indexing � private pages should not appear in public search results - Consider caching implications for mixed-visibility wikis - Git-based storage means permissions need enforcement at the application layer, not the git layer --- *Authored-by: Moko Consulting*

jmiller changed title from ~~feat(wiki): page-level permissions and granular access control~~ to feat: Enterprise Wiki Expansion & Governance Strategy

2026-05-16 15:38:57 +00:00

jmiller added the priority: critical type: feature labels 2026-05-16 15:38:59 +00:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MokoConsulting/MokoGitea#79