I currently have the following problem:
My questions are
Hope someone can help...
Thanks in advance
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
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)
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)
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.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
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!
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