Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to hide a project from project list for other users?

I want a solution for hiding project for other users who are not working on the particular project. And hiding level should be when they login in jira they only can see there project not other project.

2 answers

0 votes
Joe Pitt Community Leader Apr 22, 2019

You need to remove permissions. Since you're new here I'm posting answers to common newbie questions, including this one. 

First, by default JIRA has a horrible permission scheme that violates security best practices by allowing everyone that can logon to do just about everything.

 

JIRA works by GRANTING access. You can't restrict access. By default, it grants access to the group used to logon (see Global permissions to see the "can use" groups and admin groups).  This is where users are getting their access.

 

  1. The FIRST thing you need to do to get control is to remove any groups with logon privileges from the permission scheme unless you absolutely want everyone to have that permission.
  2. Then I suggest you setup Project Roles for the various functions like, tester, QA, Browse Only, etc.
  3. By using project roles, one permission scheme will cover all projects. The project admin controls project role membership
  4. If the project leads want everyone that can logon access to the project they can add the logon group to a project role with the desired permissions.

 

This may be a big effort, but it will pay off down the road by making it easy to control access.

 

Most of the 'old timers' use project roles. It meets the best practice for security and gives complete control to the project lead for access to their project. JIRA comes with many project roles, but you can add more if you have a special need.

 

Do not delete issues. When you delete it is GONE. Hardly a week goes by without someone wanting to restore an issue. Deleting issues will come back and bite you when it is the most inconvenient. I suggest closing with a resolution value of Deleted anything you want to delete. I implement a special transition only the project lead can execute and it requires filling in a reason field from a select list (such as entered in error, OBE, Duplicate, Other) and explanation text.

Deleting issues destroys historical data. Missing issue numbers will eventually cause a question about what it was and why was it deleted even if it was done properly. Missing data always brings in the question of people hiding something that may have looked bad.

 

The only viable way to restore an issue is to create a new instance of JIRA and restore a backup that has the issues. Then export them to a csv file and import them to your production instance. You will lose the history.

 

Do not delete users

Users should be made inactive not deleted. JIRA uses a pointer to the user’s DB entry to display user information. If you delete a user when you open a JIRA issue the user worked on anywhere the user that would be displayed will cause a SQL error. Even if the user never logged on or were assigned a ticket the history of the ticket will get an error when you display it.

 

Resolution Field

Resolution Field can't be made optional. DO NOT put the field on any screen except the one presented in the transition where it is to be set. Resolution is a special field in JIRA. It has an initial value of ‘Unresolved’, which means the field is NULL in the database. It is ALWAYS required when it appears on the screen. ONLY display it on the screen during a transition to the status where you want it set. Once it is set the issue ID will appear with as strikethrough. If you re-open an issue the transition from closed to reopen needs to have a post function to CLEAR the resolution field to set it back to Unresolved.

 

Limiting resolution options

You can do it with workflow properties. Use the jira.field.resolution.include property. copy/paste https://confluence.atlassian.com/adminjiracloud/workflow-properties-776636709.html

 

Put JIRA under CR

 I STRONGLY suggest you treat JIRA like a production system, put it under change control (CR), and track all requests for any updates, especially new projects, new custom fields, changes in any of the schemes, etc. That way at least the reporter will know when the actions happen and you'll have a audit trail. I've worked many similar tools to JIRA and too many times no one knows anything about why they are configured why they are because there is no requirements or CR. Things are just done based on emails that have disappeared and hallway or lunch conversations.  

 

If you don't already have a separate change control tool create a JIRA project. I use a basic workflow with a few custom issue types:

 

Custom field: with a select list of create, update. The description would be to create a new field or modify a current select list, buttons, etc. of a current one

 

Create Project: I would have text fields for issue types, custom fields, select list/values, per issue types

 

New Issue Type: description would include all fields and workflow desired.

 

Workflow: Select list of Create, update, delete. Description of what needed.

 

Other: Select list of Notification Scheme, permission scheme, field configuration, other

 

This should get you started. If you aren't familiar with your CR process there should be a configuration management person to talk to.

HI. I think this doesn't solve @abhimanyu95 's issue. By doing as you say (I did it), users will not have access to the project issues but they will still see the projects listed when they chose "all projects" and will also see the respective boards (even though empty).
We need a solution where the user only sees on, that the "all projects list", the projects he is envolved with.

Like abhimanyu95 likes this
gruber I'm New Here Jun 25, 2020

Exactly. Has this been solved already?

+1

Has this been solved already?

I am still facing the issue, By doing your given solution its not helping and tried some other method in project permission but still the same issue persist. User is not having permission to access project issue but he still able to see the all project when he goto all project list. 

We need solution for user who can only able to see which project he involved with in the all project list. 

Joe Pitt Community Leader Aug 23, 2020

I don't use cloud or new generation project. However, I believe new generation projects are marked public or private. I think if it is marked public it is available to everyone. If it is a new generation project check the public/private

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you