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

JEMH supported features ?

ipguy

This is a question to any JEMH adopter

I'm trying to understand JEMH's capabilities to see if it fits our needs.

I have a Jira/JEMH requirement that I was hoping to get some feedback with:

1) Client emails support.
2) Jira/JEMH creates an account if not already created.
3) Account creation is restricted to JEMH domain whitelist.
4) If user belongs to whitelisted domain they are able to view other issues/tickets submitted from same domain.

Does the above scenario possible when using JEMH ?

Accepted answers

All comments

unknown

Hello,

#1 Yes, clients email a mailbox that JEMH can pickup from via JIRA Mail Services

#2 Yes, you can configure JEMH to do this using a couple of strategies for picking a username, including ldap lookup

#3 Yes, you can configure an approprate regexp for createUsersIDFromEmailDomainWhitelist

#4 Kinda. If you have a single domain, you can nominate a group eg KEY-users, if you grant that group via console 'right to use' then they will be able to log in. If you also allocate that group in the project roles, they will be able to see the project, which is what you desribe.

Mulitple projects is a different ballgame, selectin an auto-join group based on the project key, eg KEY-users, is possible but not written, logged as https://studio.plugins.atlassian.com/browse/JEMH-506

Rgds

ipguy

Re #4, I've only created one project that will be used for the helpdesk/support ticketing system. Currently all automatically created users only see there own tickets I take it then by your answer that #4 is possible ? (just hoping for further clarification)

unknown

Sounds like the project permission scheme needs changing, removing just the 'reporter' for BROWSE and adding the JEMH auto-join group in its place?

unknown

I think we are on the same page, so long as auto-created users (whitelisted @domain.com) are joined to KEY-users. users from @otherdomain fail with whitelist for user creation and wont be able to log in. Comments above regarding permission scheme changes still hold.

ipguy

mmm.. i don't think i understand why i need to do that ?

i just want to make sure @domain.com">*@domain.com can see each others tickets but not tickets from *@otherdomain.com

ipguy

Ok but there "will" need to be multiple domains users from "multiple domains", only thing I need to do is insure domain users see only tickets from there domain. Are we still on the same page ?

unknown

Ah, right. Well perhaps no then. JIRA doesn't/won't support issue level security which is kind of required for what you describe, as you only get one level of 'BROWSE' see https://jira.atlassian.com/browse/JRA-5865

Whislt JIRA security is done at a project level, to implement what you describe can be done but not for one project. You would need mulitple projects (actually one per domain), then a new feature would be required to MAP inbound user domains to specific projects, which is where I came in with -506. Its possible something could be done with custom fields and group pickers in the permission scheme, in conjunction with -506

That would (when written) allow auto-joining to a group that had permissions in the target project. ie, you have to do project setup per domain supported. Of course this can get more complex with automated project creation and so on, but one step at a time.

Features such as this could be implemented after JEMH 1.0, for this expanded case I created https://studio.plugins.atlassian.com/browse/JEMH-510

Im curious so may test out the CF theory.

Welcome!

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

Quick Links

Find more posts tagged with

jira

jemh