Hiding issue fields in case of limited permissions
Hello,
in the Process Template it is possible to configure the tabs and sections of editors.
Example:
As key, something like hideIfEmpty is supported, but not "hideIfNoPermission" or something else.
How to I hide issue fields in dependency of a role or permission?
E.g., how to I hide internal fields that should not be visible for customer? And, in case it works, how to I avoid those fields are included in searches, reports etc. in case a user does not have according permissions resp. roles.
Where can I find details about those security topics?
Thanks,
Uwe
in the Process Template it is possible to configure the tabs and sections of editors.
Example:
...
<configuration-data id="com.ibm.team.workitem.editor.configuration.presentations" xmlns="http://com.ibm.team.workitem.editor/presentations">
<tab id="com.ibm.team.workitem.tab.history" layout="builtInHistoryLayout">
<section sectionId="com.ibm.team.workitem.section.history" title="History">
<property key="hideIfEmpty" value="true"/>
</section>
</tab>
...
As key, something like hideIfEmpty is supported, but not "hideIfNoPermission" or something else.
How to I hide issue fields in dependency of a role or permission?
E.g., how to I hide internal fields that should not be visible for customer? And, in case it works, how to I avoid those fields are included in searches, reports etc. in case a user does not have according permissions resp. roles.
Where can I find details about those security topics?
Thanks,
Uwe
3 answers
Hi Uwe
It is not possible to hide a field depending on permissions. The problem
is that a role will have different permissions in different team areas.
In the workitem editor, the team area is computed out of the Category
and the 'Planned For' value. This would mean that changing the category
(or planned for) would require the editor to re-layout, which is unwanted.
Hiding fields in searches etc. based on permissions is, to my knowledge,
not supported either.
In the workitem editor you could achieve the desired behavior by
providing an own editor presentation (contribute to the respective
extension point), and implementing it in a way that it shows different
values (or none at all) if the owner or workitem has a specific property.
HTH
Marcel
Jazz Workitem component
u.voellger wrote:
It is not possible to hide a field depending on permissions. The problem
is that a role will have different permissions in different team areas.
In the workitem editor, the team area is computed out of the Category
and the 'Planned For' value. This would mean that changing the category
(or planned for) would require the editor to re-layout, which is unwanted.
Hiding fields in searches etc. based on permissions is, to my knowledge,
not supported either.
In the workitem editor you could achieve the desired behavior by
providing an own editor presentation (contribute to the respective
extension point), and implementing it in a way that it shows different
values (or none at all) if the owner or workitem has a specific property.
HTH
Marcel
Jazz Workitem component
u.voellger wrote:
Hello,
in the Process Template it is possible to configure the tabs and
sections of editors.
Example:
..
configuration-data
id="com.ibm.team.workitem.editor.configuration.presentations"
xmlns="http://com.ibm.team.workitem.editor/presentations"
tab id="com.ibm.team.workitem.tab.history"
layout="builtInHistoryLayout"
section
sectionId="com.ibm.team.workitem.section.history"
title="History"
property key="hideIfEmpty"
value="true"/
/section
/tab
..
As key, something like hideIfEmpty is supported, but not
"hideIfNoPermission" or something else.
How to I hide issue fields in dependency of a role or permission?
E.g., how to I hide internal fields that should not be visible for
customer? And, in case it works, how to I avoid those fields are
included in searches, reports etc. in case a user does not have
according permissions resp. roles.
Where can I find details about those security topics?
Thanks,
Uwe
Hello,
thanks for the answer.
Does this mean that there are no differences between JAZZ and JIRA (or several other "simple" tracking systems) in this area?
Look at http://jira.atlassian.com/browse/JRA-1330. There are so many people that would like to see those features. In JIRA, it cannot be implemented since the kernel was not designed to do this.
Team Concert / JAZZ is completely new, and it will only be possible be reworking the whole Work Item UI? And never for reports etc.?
Maybe I'm wrong, but permissions can also be defined on the Team Area level. Perhaps this could be used to implement the desired behavior in JAZZ. That would mean the issue is shown with the same layout, independently of the team area.
Regards,
Uwe
thanks for the answer.
Does this mean that there are no differences between JAZZ and JIRA (or several other "simple" tracking systems) in this area?
Look at http://jira.atlassian.com/browse/JRA-1330. There are so many people that would like to see those features. In JIRA, it cannot be implemented since the kernel was not designed to do this.
Team Concert / JAZZ is completely new, and it will only be possible be reworking the whole Work Item UI? And never for reports etc.?
Maybe I'm wrong, but permissions can also be defined on the Team Area level. Perhaps this could be used to implement the desired behavior in JAZZ. That would mean the issue is shown with the same layout, independently of the team area.
Regards,
Uwe
Hi Uwe
What the workitem team will do for RTC 1.0 can be seen in the
'Foundation & Work Items 0.6' plan
(https://jazz.net/jazz/web/projects/Jazz%20Project#action=com.ibm.team.apt.viewPlan&id=_hzfgkG0REdyZstz7MQT3tA&page=overview),
especially that general visibility of attributes (field level
permissions) and read permissions are post RTC 1.0 features. We however
plan to support comments that are only visible for members of a group
for RTC 1.0.
Regards
Marcel, Jazz Work Item team
What the workitem team will do for RTC 1.0 can be seen in the
'Foundation & Work Items 0.6' plan
(https://jazz.net/jazz/web/projects/Jazz%20Project#action=com.ibm.team.apt.viewPlan&id=_hzfgkG0REdyZstz7MQT3tA&page=overview),
especially that general visibility of attributes (field level
permissions) and read permissions are post RTC 1.0 features. We however
plan to support comments that are only visible for members of a group
for RTC 1.0.
Regards
Marcel, Jazz Work Item team