sebastian23 Also see my previous comment about "hiding" and using the CUTE for JIRA Plugin.

How is this solved/closed now? Because I still don't find any official solution for the required feature (hide fields for certain user groups).

Update:
Nevermind, I found a clear (and indeed disappointing) statement in https://jira.atlassian.com/browse/JRA-1330.

guys, if anyone is still looking for a solution: we described a pretty low level (i.e. soft-hiding, on the client side) approach to this issue here. Please feel free to look onto this and come back at me in any case of questions.

Disclaimer: this solution requers a small plugin of which we are the developers. Better be honest upfront

Henk,

This is almost a direct duplicate of JRA-1330 and if we can't do JRA-1330, we won't be able to do this. We will look at re-opening smaller issues that were incorporated into JRA-1330, but we wont reopen an all encompassing duplicate.

Cheers,
Nick

Can this issue please be reopened again??? see the last comment of Scott Farquhar [Atlassian] and see call JRA-1330

Guys,

We have two issues that are for the same thing - JRA-3417 and JRA-1330. I'm closing JRA-3417 for the following reasons:

• JRA-1330 has more information
• JRA-1330 has more votes and watchers
• JRA-1330 is the older issue.

I'll add everyone from JRA-3417 to be a watcher on JRA-1330.

This is the reply I gave via email to Steven, who contacted me personally:

Unfortunately this issue is not likely to be implemented this year.
This is because we are working on other areas that are both causes of
complaint (editable worklog, editing workflows), core components
(improving issue searching, sorting, notifications), and architecture
improvements (improving plugins, the build system).

There is also a lot of architecture improvements that we want to do under
the hood, and in the administration UI before we add this feature,
otherwise it will be too complicated for our users to use effectively and
easily (as I fear we have done with screen schemes / workflows).

I'm sorry that your feature isn't at the top of the list, but we do try
to listen to everyone, and we do implement the most voted for features,
but in this case we have to do other features first.

Please vote / comment on the issue, it keeps it at the forefront of our
minds, and we do use this feedback when implementing features.

Hi guys,

Unfortunately, this issue is still not scoped for a specific release yet. Though it is one of our top priorites issues and do hope to get it resolved sooner rather than later. We try to very open and transparent with our processes and have posted our selection criteria for new features.

We will post a comment when this issue is scoped.
Sorry for the inconvienience.

Cheers,
Nick

Any update on when this will be added? My organization needs this also.

Jose,

This is not recommended but if you have very simple and static requirements and are prepared to get your hands dirty you could edit the JSPs directly. You'd need to edit.

\jira\src\webapp\includes\panels\issue\create_fields.jsp
\jira\src\webapp\includes\panels\issue\edit_fields.jsp

If you wrap a field in the tag

<webwork:if test="/remoteUser/inGroup('jira-administrators') == true">
.....
</webwork:if>

Then the edit field will only be available to jira-administrators.

eg.
<webwork:if test="/remoteUser/inGroup('jira-administrators') == true">
<webwork:if test="id == 'environment'">
<ui:textarea label="text(./nameKey)" name="id" cols="'70'" rows="'2'">
<ui:param name="'description'"><webwork:property value="fieldDescription" escape="false" /></ui:param>
<ui:param name="'mandatory'" value="../required"/>
</ui:textarea>
</webwork:if>
</webwork:if>

This will hide the environment field. etc.

For custom fields, you may wish to look at an Admin CF Type example at: http://confluence.atlassian.com/display/JIRA/Customizing+Custom+Field+Types+Tutorial

We can't really support this hack much beyond this nor can we guarantee that it will be compatible in future upgrades (should be fine for the upcoming 3.1 release). It could provide a solution for some with very basic requirements.

Cheers

Mark C

6 months ... sounds like a long time, but i think i can handle it and look forward to

Sorry, in the last comment I mean :
hide a field in the edit ISSUE page.

While we wait, how can we workaround this limitation? Maybe edditing the jsp page and hardcoding sobe permission schemas? Can you show me some example code to hide a field in the edit fields page?

We're currently making some fundamental changes to the way fields work in JIRA at the moment. This will enable us to implement the much request field level security. We definitely plan to implement this feature in the next six months.

Cheers

Mark C

We also really need Per-field security.

when is it due?

This THE MOST WANTED FEATURE in our company.

It would be great to give the field-layout page another coloumn, so that i can "Add Groups" to each field, for which this field is visible. If one user does not belong to any of the groups associated with that field it is not visible.

You should really consider it. Can you tell me if something like this is already in your development pipeline?

I just downloaded a copy of the 3.0 Beta and under Permission Scheme I still see:

Resolve Issues
Ability to resolve and reopen issues. This includes the ability to set a fix version.

I would like to see the "ability to set fix version" be it own category. As mentioned previously right now I need testers to be able to reopen resoved issues, but I don't want them to have the ability to set which version they will be fixed in, so I would like to restrict the visibility of the Fix Version field to developers only.

Andy,

I think you're after something different to what JRA-3417 is about. You can limit workflow progression in the forthcoming 3.0 release.

For our needs we would like to see the ability to Resolve or Reopen an issue separated from assigning a Fix Version/s.

In our implementation we have developers and testers. we would like testers limited to closing and reopening issues, but they lose the ability to reopen if they are not granted field permissions to resolve issues. However, allowing testers to Resolve issues also opens up the ability to assign a Fix Version which we would like to restrict to developers only.

I hope the per-field security feature will be available in the release after 2.7.
It's a big requirement of our organisation : some projects have 30 fields and users are rejecting these issue forms because there's too many fields, even if there's only 5 fields that they are responsible for.
In fact, an issue goes through 6 different teams in our organisation and people claim that cannot find easily the information because there's too many fields they are not concerned with.

Hilary,

Per-project, per-type issue layout schemes will be in 2.7 Enterprise. Per-field security is still a way off.

We are also very much interested in this issue for the same reasons mentioned above.

In addition, we would also like to show/hide field depending on the Issue Type.

For example, we have created custom fields specific to Bugs but are irrelevant to Tasks. We would therefore like to hide these fields if a Task is created instead of a Bug. I apologise in advance if this additional request has been overed elsewhere, I am still looking.

We need this too. My idea on how to implement this is:

The "Create Custom Field" page has an additional control where one can add a group or a person granted read or write access to a custom field (very similar to the existing controls for defining permission schemes). If the person is not in that group he can't view or modify the field.

It would also be great if this concept could be extended to system fields too. Many companies would make their JIRA available to their customers, but they don't want them to see the work log, for example.

It's exactly what is also required in our organisation : some fields are used by business people, some others by technical people. Business people does not want to see technical fields.
Consequently, in the Field Layout Scheme, we should be able to defined the hide/show/required/edit attributes of a field depending on the user/group/role. Today, these attributes are defined staticly for a couple project/field.