A user can usually still see a Jira project because they still have Jira app access and a project visibility path, most often Browse Projects through a group, project role, shared permission scheme, or admin-level permission.
Why this matters
Removing one obvious membership rarely proves access is gone. Jira project visibility is layered, so an admin needs to trace every active path before deciding that access is intentional or unsafe.
For the query why can user still see jira project, the useful answer should help an admin decide what to check now, which rows to hold out, and which proof should survive after the change. That is why this page stays inside a narrow operational boundary instead of becoming a general governance essay.
Working scenario
A contractor was removed from a project role but can still find the project. The admin later finds that the same user is in a department group granted Browse Projects through a shared permission scheme.
Start with app access
Confirm whether the user can access Jira at all. App access and in-app permissions are separate layers; project permission troubleshooting is incomplete if the product access path is unknown.
Trace Browse Projects
For company-managed projects, Browse Projects is the primary visibility permission. Check whether it is granted to a group, role, application access, public, any logged-in user, field value, assignee, reporter, or project lead.
Expand roles into real members
If Browse Projects is granted to a project role, inspect membership for the specific project. A user can enter through a direct role membership or through a group inside the role.
Check shared schemes and admins
A shared scheme can explain why several projects behave the same way. Site and Jira admins may also see projects differently than regular users, so test with the right account type.
Do not confuse work item security with project visibility
Work item security can hide individual work items, but it is not the same as removing project visibility. Keep the investigation focused on the exact thing the user can still see.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| Whether the user has product access before project permissions matter | Confirm the current state, owner, and source before acting. | Preserve the reason and evidence in the review record. |
| Which permission scheme controls the project | Confirm the current state, owner, and source before acting. | Preserve the reason and evidence in the review record. |
| Which project roles include the group or user | Confirm the current state, owner, and source before acting. | Preserve the reason and evidence in the review record. |
| Whether Browse Projects is granted through more than one path | Confirm the current state, owner, and source before acting. | Preserve the reason and evidence in the review record. |
Common mistakes
Most cleanup errors happen when an admin treats a partial signal as a complete answer. These are the failure modes to watch for on this topic:
- Removing the user from one role and assuming every path is gone.
- Ignoring a broad group grant in the permission scheme.
- Testing with a Jira admin account and drawing a regular-user conclusion.
- Treating work item security as the same thing as project visibility.
Checklist
- Confirm the user still has Jira app access.
- Identify the affected project and active permission scheme.
- Check Browse Projects first.
- Expand group grants, project-role grants, and direct user grants.
- Check whether the permission scheme is shared.
- Use Permission helper for a work item-level check when the symptom involves a specific work item.
Official Atlassian references
- Atlassian Support: How does app access work?
- Atlassian Support: Space access and configuration permissions
- Atlassian Support: Check a user's access from a work item
- Atlassian Support: How to determine project visibility in Jira Cloud
- Atlassian Support: Users with Jira access can't view any projects or work items