Comment on issue by mail which has security level

Hello,

I currently have the following problem:

  • All issues have a security level "internal & reporter"
  • The Mail handler creates new users on mail arrival
  • External questions are asked via JETI
  • When the external person answers by mail the comment cannot be created because of the security level (without the security level it works, even if the new user cannot see the issue)

My questions are

  1. Is there a way to allow the creation of comments regardless of security level?
  2. Can I modify the security level, so that the comment is created?
  3. Can I create the user when the mail is sent via JETI and add it to the security level (i.e. saving him in a custom field and allowing users in this field in the security level)
  4. Is there any other solution to the problem?

Hope someone can help...

Thanks in advance
Thomas

4 answers

1 accepted

I resolved it with script runner this way:

  • add a new userselect field "allowed-user" to the security level
  • create a new user with the recipient email after sending the mail (post-function)
  • store this user in "allowed-user" (post-function)

When i click on "Script Fields" under Script Runner it only says: There are currently no scripted fields in the System. Please create one by adding a new custom field.

If I click on that link, wich of the filed types should I choose?

Sorry, I belive this is more complicated that you think. You have to use a regual userselect field and write a script which you attach to your workflow or via listener.

No worries ^^

After a little while I got it to work, wasn't that hard at all :)

0 vote

This is where the problems that JETI and other plugins that bypass security kick in. Jira's security model is basically correct - a person who cannot see an issue should not be emailed about it. Because you are immediately leaking potentially sensitive information.

If you break this model with something like JETI, then you're asking for more security issues, including not allowing incoming email to update the issues.

So, to answer your questions

1. No. If you can't see it, you can't comment on it. That is correct.

2. No. As per 1.

3. Not without some code, but it is possible.

4. Yes. Dump the security scheme, as it's pretty clear you don't actually need it.

Actually I do need the security and was wondering why I worked in the first place (without the security level).

The clean way (and what I am trying at the moment) would be 3.) Any tips to that? I would need it in a post-function - currently trying Script Runner...

(i) Most of my problems are not the code, but where to start - i.e. what packages to import

No, not a new email handler - my soution would be:

  • add a new userselect field "allowed-user" to the security level
  • create a new user with the recipient email after sending the mail
  • store this user in "allowed-user"

Mmm, option 3 would be a new "email handler" - one that can ignore the security. I don't know if the script runner can do email handlers. It's definitely the right place to start, but I've not done it myself. I don't think you need much in the way of imports though - the stuff I've got in the handler I wrote (outside the script runner) was mercifully short.

Oh, I see. Yes, that would work too.

I'd create the user as a post-function or listener (script runner of course), although you'd need to think about how you got them a password and so-on (and it would only work for Jira systems using internal authentication)

As the mail is send in a post-function this would be the place to create the user too. I don't care about the password at the moment (he can hit "forgot password" for now).

The email is entered on the transition screen - how can I get this value in the post-function?

I think it's the same as fetching any other custom field - get custom field value as a string.

You'll need to think about temporarily grabbing admin rights in the post-function as well, or it'll block you creating new users (although you're right about the new user function - I've done something similar and just set the password to a stupidly long random string)

Just to put it right, this problem does not come from JETI "leaking security". It is a general security question that derives from the special needs. The best solution would be a custom mail handler. As JETI can throw events for all emails it sends, an event listener developed with script runner could also work well.

Mmm, that's not quite right. JETI is leaking potentially secure information that the application normally prevents. It is of course possible for other plugins to create leaks, and the leaking can well be deliberate and by design. It's a minor quibble with language, but there's no denying that JETI (and others) enables leaking that the core application normally does not allow.

To comment on that: I find it rather strange, that the plain JIRA mail handler allows commenting to issues which are not visible to the user when he is normally logged in.

Tibor: We are having the same issues with this... Can you specify how we can make a workaround with a custom mail handler? (kinda new to this whole Jira admin thing)

Nic, what I wrote was that Thomas' problem is not caused by the fact that Users can send protected issues to external people.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published 5 hours ago in Jira

5 ways you can make the most of Jira Software and Bitbucket Cloud

As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...

17 views 0 3
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you