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

feat: Enterprise Wiki Expansion & Governance Strategy #79

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

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 commented 2026-06-06 14:36:49 +00:00
Author
Owner
Copy Link
Copy Source

Enhancement: Hierarchical folder navigation with auto-generated sidebar

See #506 for the full proposal. Key points:

  1. Folders as menu items in a sidebar navigation tree
  2. README.md inside folders serves as the section landing page
  3. Auto-listing of files inside each folder (no manual homepage updates needed)
  4. Collapsible sidebar shows folder structure, expands current section
  5. Backward compatible with existing flat wiki URLs

Closing #506 as duplicate - this is the canonical wiki feature issue.

Authored by Jonathan Miller (@jmiller)

## Enhancement: Hierarchical folder navigation with auto-generated sidebar See #506 for the full proposal. Key points: 1. **Folders as menu items** in a sidebar navigation tree 2. **README.md inside folders** serves as the section landing page 3. **Auto-listing of files** inside each folder (no manual homepage updates needed) 4. **Collapsible sidebar** shows folder structure, expands current section 5. **Backward compatible** with existing flat wiki URLs Closing #506 as duplicate - this is the canonical wiki feature issue. --- *Authored by Jonathan Miller (@jmiller)*
jmiller commented 2026-06-06 20:59:15 +00:00
Author
Owner
Copy Link
Copy Source

Testing Complete - Wiki Folder Navigation

Verified on Production (v1.26.1-moko.06.08.04)

Test Result
Sidebar folder tree renders on wiki home PASS
features/ folder shown with directory icon PASS
Children (Custom-Fields, Custom-Statuses, README) listed under folder PASS
Active page highlighted in tree PASS
Folder tree auto-generated from wiki git repo structure PASS
Breadcrumb navigation for nested paths PASS
Creating pages with slashes creates real folder structure PASS
Git tree shows proper features/ directory PASS

Screenshot Evidence

Wiki home page showing sidebar tree with features/ folder expanded:

  • Root pages: Branding, Deployment, Home, License Management, Org Branch Protection API, Project API, roadmap
  • Folder: features/ with children: Custom-Fields, Custom-Statuses, README
  • Table of Contents sidebar rendering alongside folder tree
  • Home page marked as active in tree

Known Limitation

Folder URL navigation (/wiki/features) requires authentication. Unauthenticated users see 404 (repo requires login). When authenticated, folder navigation works with README.md index fallback.

Authored by Jonathan Miller (@jmiller)

## Testing Complete - Wiki Folder Navigation ### Verified on Production (v1.26.1-moko.06.08.04) | Test | Result | |------|--------| | Sidebar folder tree renders on wiki home | PASS | | features/ folder shown with directory icon | PASS | | Children (Custom-Fields, Custom-Statuses, README) listed under folder | PASS | | Active page highlighted in tree | PASS | | Folder tree auto-generated from wiki git repo structure | PASS | | Breadcrumb navigation for nested paths | PASS | | Creating pages with slashes creates real folder structure | PASS | | Git tree shows proper features/ directory | PASS | ### Screenshot Evidence Wiki home page showing sidebar tree with features/ folder expanded: - Root pages: Branding, Deployment, Home, License Management, Org Branch Protection API, Project API, roadmap - Folder: features/ with children: Custom-Fields, Custom-Statuses, README - Table of Contents sidebar rendering alongside folder tree - Home page marked as active in tree ### Known Limitation Folder URL navigation (/wiki/features) requires authentication. Unauthenticated users see 404 (repo requires login). When authenticated, folder navigation works with README.md index fallback. --- *Authored by Jonathan Miller (@jmiller)*
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 Medium
Type Feature
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#79
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?