nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Create issues ONLY via email, not via JIRA frontend

Kai Gottschalk

I am wondering if there is any possibility to allow users X to create an issue by email in Project Y and do not grant the same users X the permission to create an issue via Frontend.

Usecase:
We've a complex multi-project environment in our JIRA and have one pool project where most users create issues in (which will moved later on in the according project). If we now grant more and more users creation of issues (via frontend) in a rising number of projects, confusion about the correct project might follow.

Thus we think about granting a subset of all users the possibility to report issues via email without cluttering the create issue dialog.

Any hints, even workarounds, are highly appreciated!

Accepted answers

unknown

A solution can be reached using JEMH. Without modifying project security, remote users can create issues by email (helpdesk scenario), the sender email address can prefix the comment (with as little or as much related information as is available) so you know where it came from. Issues in this mode are created through a configured fallback User that needs to have appropriate permissions in your target project.

Remote user emails get stored in a custom field, so that JEMH driven notifications can occur. Such notifications can be customised as well as being enabled/disabled on a per-event basis, reducing in the amount of email notification the remote users get.

Happy to discuss further if the configuring the default handler is not working out for you.

All comments

Ramiro P

Hi Kai, if you already know how to configure the create issues via mail thing then the rest it's easy.

I can think in one possible way:

You can create a new role for the projects (for example 'via-mail' role) and give them permissions for whatever except the 'Create Issue' permission in a project. This will avoid the possibility of creating issues inside Jira for that role.

In the other project you can have a different permission scheme where this 'via-mail' role has the 'Create Issue' permission.

So basicaly in one project they can create normal way and in the other not.

However, this is just an idea that came now, not sure if it would work.

Hope this helps!

Kai Gottschalk

Hi Ramiro,

thanks for your quick response. Yes, the email setup does already work fine. Most likely I have not pointed out clearly what I want to achieve:

Let's pretend we are simply working with one project. We only have one user and this user should be able to open up an issue via email in this project but not via the JIRA frontend (although logging into JIRA, browsing, commenting, etc. shall be possible for him).

As both, creation via email and creation via frontend depends on the "Create Issue" permission, I see no easy solution for this task, do you?

I was already trying the "default reporter", but still the sender of the email does require to have "Create Issue" permission.

Cheers

Kai

Chris Martin19

Do you want the user putting in the issue through email to be assigned to the issue as well? I see no reason why the email handler couldn't assign the issue to someone else, and not even know who put in the issue. Since anonymous users can put in issues through email and they don't have to have create permissions, I think it's almost the same thing.

Or I'm completely off the mark and that's not what you want to do at all!

Kai Gottschalk

Hi Chris,

the issue created by email should be handled as if it was created in the frontend: It shall be assigned to the component lead.

We do have authentification via LDAP > CROWD > JIRA and as I've not checked "Create Users", no anonymous/unknown users are able to create issues.

Thus JIRA forces me to grant the user the "Create Issue" permission, see error message

Cheers

Kai

unknown

Happy to discuss further if the configuring the default handler is not working out for you.

Kai Gottschalk

Hi Andy,

thanks for pointing me to the JEMH. Definitely a great plugin, as I did already a lot of research in this direction before (for an other project).

Currently I am trying hard to solve our usecase without any third party plugins. Nevertheless I am really interested in /curious about your comment:

"Issues in this mode are created through a configured fallback User that needs to have appropriate permissions in your target project."

With the built in default mail handler we have the possibility to use a fallback user (here it is called exactly "Default Reporter") as well, at least I thought:

I configured this user (e.g. JIRA_Mail) and added it into the field "Default Reporter". Afterwards I tested it and still received the error message above:

"Reporter (kai.gottschalk) does not have permission to create an issue..."

Assumption: While the "fallback user" in JEMH seems to be a real fallback user, creating the issue in case the email sender is not a valid reporter, the built-in "Default Reporter" will not be the reporter of an issue, if the mail sender has no permission to create an issue.

Any idea how to solve it without external plugins?

Cheers
Kai

As we use already an unlimited license, my request is no trial to cheat with the license count :-)

unknown

Hello Kai,

As you see, I think the problem you have is that the incoming addresses relate to users, so are used, I may be wrong, I dont spend a lot of time on the default handler workings these days!

I like to thing JEMH solves realistic configuration issues, saving admin overhead. Whilst interacting with JIRA via email is good for remote support, I'd always advocate giving users a seat if you can.

I wonder if JIRA Issue Collectors may be an alternate approach to solving your requirement?

Kai Gottschalk

Hi Andy,

"I wonder if JIRA Issue Collectors may be an alternate approach to solving your requirement?"

Good point. Although it was not 100% the way I wanted to solve the problem I really (!) like the approach via issue collector.

With the marked settings above we could reach what we want, even without any drawback as the reporter and email (which is entered during creation) is also visible in the issue.

I'll close the issue in a second. Well earned karma-points. Thanks!

Kai

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

permission