|
Nick,
Yeah I can see how it could be a part of Field Level Security, especially from a development standpoint. However, since the system already hides links based on browse permission everywhere except the history, there is also the perspective that the designed in security for seeing links has a hole in it. For now, I've worked around the issue by preventing all links from showing in the history by editing the changehistory.vm file. I've attached the file in case anyone else out there also needs links hidden. The original file that I modified is from the 3.4.2 Enterprise edition of Jira. Erik Nick - I don't think this issue is about field level security. Erik is saying that the change history displays a link to an issue that the user cannot see. I've attached screenshots that exhibit the problem.
screenshot-1 is what secure user sees. No link to secure issue in the issue display, only in change history.
screenshot-2 shows what the authorized user sees... the link in the top view as well as the change history.
Neal,
thanks. We understand the problem but in implementing Field Level security we will have to change the change history panel to take permissions into consideration (it currently doesn't do this). Once these permission checks are in place, they will not be able to view the linked issue. Cheers, Hi,
This issue is more serious than I first suspected. The issue links are shown (a bug, not such a big deal) - however what I did not realize until today is that if if you leave a comment when you are linking the issues, it ALSO gets added to the change history. This remains of course even if you remove the link. Does Atlassian not have any policy to get past the vote count on issues. I feel this is a serious security level problem that should be addressed, regardless of how many customers have noticed it. With regards to Erik's comments above, would this work to remove the comments as well as the links? (I am not keen to have to edit this but will look into it as a last resort). Thanks Ian. Ian,
When linking issues and adding a comment, the comment is added to both issues at all times. This is built it behaviour. The request to change this behaviour is JRA-6712. Would the fix to the comment issue be solved if JRA-6712 was implemented? If the comment is sensitive, it is possible to restrict the visibility of a comment to a group or a role. If you need the comment to appear on only one of the issues, you can link issues, then add a comment separately. Cheers, Anton, I'm pretty sure that adding a comment during linking does NOT add the comment to both issues. It used to, in an earlier version, but that got removed (accidentally perhaps) somewhere between 3.2 and 3.6 I think. We've been begging you NOT to put it back in (see
To see this look at TST-13214 which was linked, but the comment only appears on one issue. Neal,
You are absolutely right. I have missed the point altogether here. Thank you for pointing this out. Ian, I am sorry for the confusion. I do agree that Ian, I must admit that I do not fully understand your reference to a "comment" when linking issues. At the moment, when linking two issues, the change history entry is added. As far as I know this happens whether a comment is added at the same time or not. The change history entry only mentions the issue key of the other issue. It does not allow the user who does not have permissions to view the issue, to see any information about the issue, only its key. Would you be able to describe in more detail the problem that you are seeing? Please mention the version of JIRA that you are using. Again, please accept my apologies for the confusion. Cheers, Is this going to be fixed? This is a major security breach for us, as we are using the reportercreate permission in permission-types.xml to disallow our OEM clients from seeing each others projects and thus revealing the nature of their relationship with us. We are using JIRA 3.12.2 Enterprise with a Commercial License.
Hi Erin,
At the moment the fix is not planned. The Change History tab only leaks the issue key information and no information about the actual issue. At the moment, we do not treat issue keys as sensitive information. We have found that in a lot of cases, issue keys get leaked in blurbs of text, such as issue descriptions, comments, and so on. Does the issue key reveal too much information to users? Cheers, It absolutely does in our case. We set up projects for our largest customers with the customer name as the project key. We can't keep things straight with keys like CUSTOMER1 CUSTOMER2. Our staff is trained to keep customer names out of descriptions/comments/etc. And if there is a link we mark the issue private and create a cloned issue (by hand if necessary) for the public facing issue.
– I second this. The key is sensitive in our case also. How loud do we need to complain to get Atlassian to do something about the problem? This issue was created over 2 years ago, I think it is about time it was 'scheduled' ? Do you have a counter for how many votes you need? In development terms I am not convinced this is a particularly difficult problem to fix.
Thanks Ian Anton, yes, our situation is exactly like Matthew's. We have sensitive relations with other major companies who contract with us to brand our products as their own. These companies are extremely large and well-known and in most cases, the relationship has not been made public. Having information about these relationships being made known would constitute a huge liability for us. We have also implemented a policy similar to Matthew's where issues for these projects are often cloned and the "real" issue is placed in a project to which only our employees have access, so the project key issue is the only security issue we have.
Sorry for the delay in replying. It took us time to analyse all of the aspects of this issue as we felt we need to look at the whole picture before making the decision.
The scope is wider than the information that is shown on the Change History Tab of an issue. JIRA has been designed such that project keys are not considered sensitive information, this is an intentional product design decision affecting such areas as adoption, usability and integration with other products. A common usage sees issue and project keys used as primary references for issues and projects outside of the system and as such they are often quoted by people, in JIRA issue descriptions and comments, in external e-mails, documents, conversations, etc. The decision to consider project keys "non" sensitive materialises in a number of places within JIRA. For example, when a user navigates to the View Issue page, the page shown to the user when the issue actually does not exist We could spend considerable effort (now and when implementing each new feature) making project keys secure, however it will probably not prevent them from being mentioned elsewhere. This effort will likely lead to false sense of security and have an impact on usability. If the association of project identity to project key needs to be protected, please consider creating keys that do not contain sensitive information. In this situation the keys can be tracked and displayed easily to internal staff using the all projects portlet which in this case would operate as a lookup table to ensure there is an easy way to match key to project. Due to the reasons described above we will not be implementing this change. We will ensure that this information is better communicated when projects are created. Please see Cheers, It's unfortunate that you're unwilling to make a small change that would meet an immediate, painful, need, with the justification being that you don't want to make an implied bigger change. A number of us have adapted our processes to deal with the "bigger issue" that you clearly don't want to tackle.
To recap: JIRA already prevents the links to non-visible issues from being displayed in the Links area of an issue. Yet it doesn't take the same care in the Change History. Your product appears to have "half implemented" link visibility. Hence, the report of a fine-grained bug. Fix this bug and a number of us will be happy. As I've stated elsewhere in respect of recent Atlassian product management decisions: what has happened to the agile mindset of frequent, incremental improvement? You seem to have become somewhat enslaved to the big-bang-all-or-nothing school of development. As our workaround, you suggest we change the keys to something non sensitive, currently tracked in JRA-2703. This issue has been open 4.5 years!
This is not feasible for a medium sized company with over 200 projects in JIRA. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Resolved
Critical
Change History shows links when main issue view doesn't
Thank you for pointing out. Though I think this is part of a bigger issue - Field Level Security
. This is the kind of thing we wish to address when implementing this feature.
Cheers,
Nick