Lantern

Appearance

GitHub Issue Visibility - Private Repository ​

Quick Answer ​

Q: Will GitHub issues be publicly viewable?
A: No. Your repository is private, so issues are only visible to users you explicitly add to the GitHub organization with Read access.

How GitHub Private Repository Access Works ​

What "Private" Means ​

  • Only users who are members of your GitHub organization can view anything
  • Issues, code, PRs, wikis - all private
  • Even issue links won't work for non-members (they see "404 Not Found")

Current Setup: Private Repository ​

Repository: cattreedev/lantern_app (private)

Who can view issues:

  • ✅ Organization owners/admins
  • ✅ Users you invite with "Read" access or higher
  • ❌ Public (no one outside your organization)
  • ❌ Anonymous users (can't even see issue exists)

Access Levels ​

RoleView IssuesCommentCreate IssuesEdit Code
Read✅ Yes✅ Yes✅ Yes*❌ No
Write✅ Yes✅ Yes✅ Yes✅ Yes
Admin✅ Yes✅ Yes✅ Yes✅ Yes
Public❌ No❌ No❌ No❌ No

*GitHub account required to create issues manually, but bot/web form creates them programmatically

For Organization Members (Read Access) ​

When a user with Read access clicks a GitHub issue link:

  1. ✅ GitHub asks them to sign in (if not already)
  2. ✅ Verifies they're an organization member
  3. ✅ Shows the full issue with all details
  4. ✅ They can comment, react, subscribe to updates

For Non-Members (Public) ​

When someone without access clicks a GitHub issue link:

  1. ❌ GitHub shows "404 - Not Found"
  2. ❌ No information about the issue
  3. ❌ Can't see title, description, or even that it exists
  4. ❌ No option to request access

GitHub protects private content completely.

Your Implementation: Hybrid Approach ​

Submission Methods ​

Discord Bot (Internal Team)

  • Users submit via /feature or /bug commands
  • Posts to Discord channels (#features, #bugs)
  • Creates GitHub issue (private)
  • Who can see Discord posts: Anyone in your Discord server
  • Who can see GitHub issues: Only organization members

Web Form (Authenticated Users)

  • Users submit via app at #/feedback
  • Requires Firebase authentication
  • Creates GitHub issue (private)
  • Who can see GitHub issues: Only organization members

Result:

  • Team can discuss in Discord (internal server)
  • Issues tracked privately in GitHub
  • Non-technical staff can view issues via GitHub (Read access)
  • Public cannot see anything

Adding Users to GitHub Organization ​

Option 1: Add Individual Users ​

For each employee:

  1. GitHub.com → Your organization → People → Invite member
  2. Enter their GitHub username or email
  3. Select role: Read (recommended for non-technical staff)
  4. Send invitation

What happens:

  • User receives email invitation
  • They accept → gain Read access
  • Can now view all issues/code in private repos

Option 2: Create Teams ​

Better for larger organizations:

  1. GitHub.com → Your organization → Teams → New team
  2. Create team: "Employees"
  3. Add repository with Read access
  4. Add members to team

Benefits:

  • Easier to manage many users
  • One-click access for all team members
  • Can create multiple teams (e.g., "Developers" with Write, "Staff" with Read)

Security Implications ​

What Users Can Do with Read Access ​

✅ Safe Actions:

  • View all issues (private repository)
  • View all code
  • Browse commits and PRs
  • Comment on issues
  • Create issues manually (via GitHub UI)
  • Download code
  • Fork repository (creates private fork)

❌ Cannot Do (GitHub Blocks These):

  • Push code changes
  • Merge pull requests
  • Modify settings
  • Delete issues
  • Change labels
  • Manage webhooks
  • Add/remove users

Key Point: GitHub enforces permissions automatically. Even if a user tries to push code, GitHub rejects it. No manual policing needed.

For Non-Technical Staff ​

Q: Can non-technical staff accidentally break the code?
A: No. GitHub prevents it at the platform level.

Even if they:

  • Try to edit files via GitHub UI → Blocked
  • Clone repository and try to push → Blocked
  • Use git commands → Blocked

They can only view and comment.

Testing Issue Visibility ​

Test 1: As Organization Member ​

  1. Click GitHub issue link from Discord/web form
  2. Expected: Issue loads, you can view all details

Test 2: As Non-Member ​

  1. Sign out of GitHub (or use incognito)
  2. Click same GitHub issue link
  3. Expected: "404 - Not Found" error

Test 3: Invite Someone with Read Access ​

  1. Invite a colleague with Read role
  2. They accept invitation
  3. They click issue link
  4. Expected: They can view issue but cannot edit code

Future: Public Submissions ​

If you later want public community feedback, the documented roadmap (in discord-bot/README.md) recommends:

Create separate public issues repository:

  1. New repo: cattreedev/lantern_app-issues (public)
  2. Main codebase stays private: cattreedev/lantern_app (private)
  3. Bot routes submissions:
    • Internal employees → private repo
    • Public users → public issues repo
  4. Manually promote public issues to internal tracker

Benefits:

  • Code security maintained (private repo)
  • Community engagement (public issues repo)
  • Control over what's shared publicly

This is a future enhancement - not currently implemented.

Comparison: Public vs Private Repository ​

FeaturePrivate Repo (Current)Public Repo (Alternative)
Code VisibilityOrganization onlyAnyone on internet
Issue VisibilityOrganization onlyAnyone on internet
Who Can Submit IssuesAnyone (via bot/form)Anyone (directly or via bot)
Who Can View IssuesOrganization membersAnyone on internet
GitHub Links Work ForOrganization membersAnyone
SecurityHigh (code hidden)Low (code visible)
Use CaseInternal companyOpen source projects

Your choice: Private repo = Correct for internal product development.

Access Control Best Practices ​

Do This ✅ ​

  • Add all employees to organization with Read access
  • Use "Read" role for non-technical staff
  • Use "Write" role only for developers
  • Use "Admin" role only for tech leads
  • Review organization members quarterly

Don't Do This ❌ ​

  • Don't make repository public to "make links work" - this exposes your code
  • Don't give everyone Write access - limits security
  • Don't share GitHub tokens - they're equivalent to passwords
  • Don't skip invitations - all access must go through GitHub

Summary ​

QuestionAnswer
Are GitHub issues public?No, repository is private
Who can see issues?Only organization members (Read access+)
Do I need to give everyone access?Yes, invite employees to organization
Can non-technical staff edit code?No, GitHub blocks Write access
What happens when non-members click links?They see "404 - Not Found"
Is this secure?Yes, GitHub enforces permissions strictly
Can I make it public later?Yes, but not recommended (use separate public issues repo instead)

Quick Setup: Adding Your Team ​

Step-by-step for first time:

  1. List all employees who should see issues

    • Developers
    • Product managers
    • Support staff
    • Executives
    • Anyone who needs visibility

  2. Gather GitHub usernames

  3. Invite to organization

    GitHub.com → cattreedev organization → People → Invite member
- Enter username or email
- Role: Read
- Send invitation

  4. They accept invitation

    • They receive email
    • Click "Join organization"
    • Done

  5. Test access

Time per user: ~2 minutes

Documentation for Your Team ​

When onboarding new employees, tell them:

"To view our issue tracker and codebase:

  1. Create a GitHub account (if you don't have one): https://github.com/join
  2. Email your GitHub username to [admin]
  3. You'll receive an organization invitation
  4. Accept it
  5. You can now view (but not edit) our repository: https://github.com/cattreedev/lantern_app/issues

Note: You can comment on issues but cannot modify code. This is intentional for security."

Need Help? ​

This ensures your code stays secure while giving your team the visibility they need.

Built with VitePress

Copyright © 2026 Lantern