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; } } }

Jira as Support Desk - Project Security

Richard O'Riord

Hi,

I've set up Jira to parse incoming emails and have it automatically set up issues in a project called SUPPORT. I've edited the permission scheme for this project. Browse Projects is set to Group (Anyone) and Create Issues is set to Group (Anyone). I've done this so that when Person A emails in and ccs Person B an issue is created and one of our developers gets an email about it. When they reply this email it is then sent to both Person A and Person B, which is great. unfortunately we have one or two users in our Jira with login details and we don't want them to be able to browser the SUPPORT project. I am wondering what is the best way to achieve something like this?

Ideally I would love to go into the permission scheme and set browse project to Group(Anyone) AND NOT Group(group_not_allowed_see_support) but this doesn't seem possible or am I missing something.

What I'm thinking of doing is setting the browse projects to Group(user_allowed_to_view_support). But to do this I'd have to add new users to this group automatically. I can either do this is 2 ways I think. I could add a trigger to the underlying database or write some script/plugin in Jira for this? I would be very unfamiliar with the latter.

So I am wondering if I am going about this the right way? Or have I missed something basic in Jira? We have only started using it in our company. Is there something with the Issue security scheme that could help me out? Is there already a plugin that solves my problem.

Thanks for taking time to read my question,

Rick.

Accepted answers

Peter Van de Voorde

Hi Richard,

We use the JEMH plugin for our emailing needs and it can automatically create inactive users (based on the emailadresses) and add these users to a user group.

JEMH: https://marketplace.atlassian.com/plugins/com.javahollic.jira.jemh-ui

You could then grant browse access to only this user group and your project roles.

Best regards

Peter

All comments

Peter Van de Voorde

Hi Richard,

We use the JEMH plugin for our emailing needs and it can automatically create inactive users (based on the emailadresses) and add these users to a user group.

JEMH: https://marketplace.atlassian.com/plugins/com.javahollic.jira.jemh-ui

You could then grant browse access to only this user group and your project roles.

Best regards

Peter

Richard O'Riord

Peter, Thanks for the quick response. I'll install this plugging and play around with it. Will report back on how I get on.

Nic Brough -Adaptavist-

No, you cannot do "not". All permissions are based on grant-first, with no "but exclude X" option.

You've got two basic approaches here I think:

1. I'd recommend removing the "anyone" from the permission scheme, using a role based permission and putting all your support people in that role, either by group or individually. Obviously, you'd leave out the two exceptional users. The reason I recommend this approach is that at the moment, you've got a setup where the whole world can see your data (ok, probably only within your network), which is fine (apart that you do want some restrictions), but you've also allowed people to update your data anonymously, which is not good. Acceptable in some fields, maybe, but I work in places where you can end up in a cell if you don't track who changed what properly.

2. Use issue security. This needs a bit of code, and it won't stop them seeing the project, just some (or all) of the issues within it. You'd set up an "issue security scheme" which says "user must be in a group X to see the issues" and then use a bit of code to set the security on all new issues.

In both cases, Adding your group "user_allowed_to_view_support" is a very good approach. There's an extra trick - if you add that group to the global permission "can use Jira" (you'll probably find the group "jira users" is in there already) , then all new users will be added to it automatically. You'd then need to *remove* new people you don't want seeing the projects, but that's a lot more simple than having to add all the new users!

(One last note - " could add a trigger to the underlying database" - No. Never amend a Jira database while Jira is running. It's a last resort even when it's not running, and you often need to reindex after doing it)

Richard O'Riord

If I add the group to the global permission "can use Jira" won't this affect my jira licence? I am only allowed to have 10 Jira Users under my current licence So if I set up the group "user_allowed_to_view_support" how do I add users to it automatically? When somebody emails in I can see that a profile for them has been created (maybe these are called non-jira users?). I am just using the default jira email handler for this. How do I automatically add them to "user_allowed_to_view_support" as you have suggested? Maybe I've misunderstood your trick. I only want people to be able to email in and create issues not to be able to log into jira. I have 10 users who can log into to Jira and two of them should not be able to see the support project.

Thanks for the heads up about the underlying database. I will try to avoid this option.

Nic Brough -Adaptavist-

Ah, I didn't know you have a limited licence. You are correct, adding the users will contribute and max your seats out.

Your options are more limited then. The "user allowed" group is still the right route to go, but you'll need some code to do the automatic add - either the JEMH as Peter says, or you'll need to write something yourself.

(It's not a case of "avoiding" doing this in the database - for your use case, you'd need to stop Jira every time a new user needs creating. It's a case of not doing it in the database)

Richard O'Riord

Sorry Nic, I should have been clearer in my question. I will look into the JEMH thanks. When you say "write something yourself". Do you mean something like like https://developer.atlassian.com/display/JIRADEV/Plugin+Tutorial+-+Writing+a+Custom+Message+%28Mail%29+Handler+for+JIRA

I've only breifly read up on stuff like jelly runner, and script runner etc.

I must admit I don't really understand why Jira would need to be stopped if I changed the underlying database. My logic would be, if Jira can read and write to the underlying database while it is running .....then why can't I? But I think this my be off topic so feel free to ignore it.

Welcome!

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

Quick Links

Find more posts tagged with

jira

permission

atlassian-support