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?
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!
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.
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'.
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.
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.
@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.
"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.
"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.
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