How can I hide fields from users?

[Christian Slaviero]

Hello,

Whilst configuring JIRA OnDemand and coming across many limitations and having to put in some less than desirable workarounds, it now also looks like I cannot hide fields from users. Is this correct?

Thanks,

Christian

[Salvador Patton]

Another use case is issue collector with public reporter email, if board is open to public its simply exposing all your user emails to the net. Its so simple functionality Jira team have taught about everything except this very crucial thing. Hiding fields from public view is a must have feature!

[Salvador Patton]

In fact not having hidden fields per user-group makes  Issue Collector and Public users functionality obsolete in Jira.

[Nic Brough -Adaptavist-]

It most certainly does not.  I think you may have misread the conversation above?  As you've not countered what it was saying.

[Nic Brough -Adaptavist-]

JIRA is intended as a collaboration tool, and hiding fields from users runs absolutely counter to the principle of openness that a team needs when its members are working together.  So no, there is no way to hide fields from users.  A field either exists and is available to all, or it does not exist for the issue/project.

If you were on the server version, there is an add-on which will enable this function, but you can't use it on Cloud.

[Martin_Fleurke]

I can give you a perfectly sound use case:

If you have an application with privacy sensitive data (e.g. personal data), and a bug is reported that affects a certain user, then you want to store the data of that person so the developer can use it for debugging. But other people involved don't need to know the specifics of the user. Once the developer has extracted the specifics of that user into a reproducible generic scenario, the privacy sensitive data is not needed any more, and should (by law) be hidden for as much people as possible (e.g. product owners, testers, release managers, even other developers in the project)

This could be accomplished by using a field that is only visible for

- the assignee, if has the project role 'developer'.

[Martin Hilbig _team neusta_]

We have to remember that Atlassian markets Jira not only to small dev teams. We have customers who use Jira for financial or management, which require different levels of access. We have customers who use Jira for quality inspection or non-conformance management in the defense sector. There is a lot of potential for improvement in regard to customisation of user view, that cannot be left to the marketplace alone.

[Peter Blom]

Same here... We co-develop with our clients. We don't want to show them all information. Only the necessary info when logged-in under their account.

[Nic Brough -Adaptavist-]

None of these arguments are a good reason to break collaboration.  The instant you start hiding information on a shared subject, you have changed people's understanding of it and crippled their ability to work on it effectively.  You might as well hide the whole thing from them.

These arguments are a good argument for having different projects with varying visibility, not hiding fields.

[Pouya Nafisi]

@nic That is such a general and terrible response for a company whose primary focus is building products and tools for users to allow them to be more efficient.

Atlassian's customers are letting them know that this is a feature they need in order to work more efficiently with THEIR customers and instead of responding to a feature request that has gotten this much traction across a number of the Jira posts you make an argument that is flipped. Here is some advice for ya, generally if there are this many people walking down a trail that is not paved it might be a good idea to pave it ... people over process. 

[Nic Brough -Adaptavist-]

Ok, if you think that, it just means you have not understood it.

The situation has not changed in the 5 years since I made the statement.

[Martin Hilbig]

"These arguments are a good argument for having different projects with varying visibility, not hiding fields."

having multiple projects with overlapping user bases tacking one problem was a nightmare with information getting lost, people opening and closing issues in the wrong project etc. 

I understand Nics approach but the reality is that our customers dont want to restructure their company to fit a tool they think about buying. They want a tool that is customizable to their work process.

[Nic Brough -Adaptavist-]

"having multiple projects with overlapping user bases tacking one problem was a nightmare..." really supports what I said about working together.

It sounds like you have a problem with working with each other when you say that.  I suspect part of the problem is that people are not sharing everything with each other. Which is why I'd say hiding fields is an anti-pattern - when you do it, people end up not knowing things that they need to. 

 There is no reason to restructure to fit the tool, that's pointless, whatever tool you choose.  Take a step back and look at what you really need to be securing in your data.  You will find that within Jira's model (and that of all it's serious competitors), you need to be hiding issues, not fields.   Jira does that.

Jira is mostly customisable to most work processes.  Where it fails mostly is when the work process is broken. 

I've made a reputation as an Atlassian fan and hence "expert".  But I've made a career of fixing broken process. 

[mai_nakagawa]

Hello Christian,

You can make fields hidden or visible even in JIRA Cloud (formally JIRA OnDemand). Hiding or showing a field section of the page tells you how to.

Cheers,

Mai

[James Strangeway]

You can give a different level of access using permission schemes to project roles and users and you can use different field configurations per project.  But I do not know of a way of hiding a single field to a single user.