Comment on issue by mail which has security level

[Thomas Heidenreich]

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

[Thomas Heidenreich · Accepted solution]

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)

[Dinny]

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?

[Thomas Heidenreich]

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.

[Dinny]

No worries ^^

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

[Tibor Hegyi _META-INF_]

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

[Tibor Hegyi _META-INF_]

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.

[Nic Brough -Adaptavist-]

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.

[Thomas Heidenreich]

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.

[Dinny]

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 Brough -Adaptavist-]

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.

[Thomas Heidenreich (//S)]

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

[Thomas Heidenreich]

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"

[Nic Brough -Adaptavist-]

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.

[Nic Brough -Adaptavist-]

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)

[Thomas Heidenreich]

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?

[Nic Brough -Adaptavist-]

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)