[#JRA-10364] Create dynamic groups - groups that automatically add users based on domain name of user's email address

JIRA

Create dynamic groups - groups that automatically add users based on domain name of user's email address

Created: 06/Jun/06 12:08 AM Updated: 18/Dec/07 09:53 PM

Component/s:

User Management

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

Issue Links:

Blocker

This issue is blocked by:

JRA-3619 Validate email addresses of users who sign up

Duplicate

This issue is duplicated by:

~~JRA-10689~~ Add "reporter domain" permission

~~JRA-10882~~ Issues entered by several persons from the same company should be mutually visible

Reference

This issue is related to:

JRA-14162 email service: createusers=true creates same user permissions regardless of address defect report was sent to.

JRA-11773 CLONE -Add "reporter domain" permission

JRA-9014 Add "Reporter Group" Permission

~~JRA-10689~~ Add "reporter domain" permission

Participants:	Benjamin Naftzger [Atlassian], Brett Adam, Nick Menere [Atlassian] and Reid Sayre
Since last comment:	62 weeks, 3 days ago
Labels:

Description

« Hide

To assist with many different use cases, most noteably, allowing all users from a single customer to be able to easily sign up to JIRA and then see and comment on all the issues created by the colleagues we need: 'Dynamic Groups'.

The Dynamic Group will allow one or multiple domain names to be associated with it.

E.G. A JIRA Administrator wants to ensure that any users from their customer Domain that sign up to JIRA are automatically included in a group that has been setup for the company Domain which has permissions to view certain issues and projects. To do this:

1. A Dynamic Group called 'Domain' would be setup with two domains defined: domain.com, sub.domain.com.

2. Then when a user signs up to JIRA, if their email address features domain.com or sub.domain.com they will automatically be added to the 'Domain' group.

3. All Domain employees that sign up to JIRA will therefore automatically be allowed to see all Domain accessible JIRA content (dictated by Permissions and Issue Security Levels which refer to the group Domain).

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Benjamin Naftzger [Atlassian] - 06/Jun/06 12:13 AM

I should point out that before this is implemented it is possible to build your own User event listener's that could automatically add users to groups if their domain name matched a nominated domain name. You can read more about creating listener's in JIRA here:

http://www.atlassian.com/software/jira/docs/latest/listeners.html

[ Permlink | « Hide ]

Nick Menere [Atlassian] - 06/Jun/06 02:59 AM

Ben,

We don't require authentication when users sign-up though. They can put in any email address they wish. I could then sign-up and put a email addess for my competitor in and then get access to all tehir issues and perhaps data.

not good....

Cheers,
Nick

[ Permlink | « Hide ]

Benjamin Naftzger [Atlassian] - 06/Jun/06 03:04 AM

Great point. Well the feature request should incorporate the inclusion of
authentication - asking users to activate their logins via email.

[ Permlink | « Hide ]

Benjamin Naftzger [Atlassian] - 25/Jul/06 07:15 PM

We need email vertification to be implemented before this issue can be implemented.

[ Permlink | « Hide ]

Reid Sayre - 18/Aug/06 09:55 AM

As I understand this design approach, a group would have to be defined for each customer prior to the first user of that customer registering. Then, when the customer user registered, he or she would be added to that defined group. This might work OK for a small number of customers, but I believe it gets messy when the customer set gets large. Refer to ~~JRA-10689~~ for a more automated approach.

Either way, registration needs to be verified some way. One way would be to have a system attribute that specifies, for example, that the registration process does not allow the user to enter his or her own password. A randomly generated password will be sent to the e-mail address and then the user can log on with that password and change it. I admit that I do not know how all this works with LDAP or other external authentication.

[ Permlink | « Hide ]

Brett Adam - 15/Dec/06 09:26 AM

Wouldn't this be better termed "AutoGroups"?

Dynamic implies dynamically resolved - i.e. a group which is defined by a parametric query that is eval'd whenever the group membership is requested.

Your description here is not dynamic in this sense, it is merely automated.

Note also that the approach proposed here requires automated removal of users when they change their email addresses.

A true dynamic group would not since it would always return the users that matched the criteria based on their email addresses at the time of each request.

[ Permlink | « Hide ]

Reid Sayre - 10/May/07 08:40 AM

JIRA 3.8 has added wrinkle here that might help.

There is a new function that enables an administrator to set a property for each user. One property might be "company".

Now we need a way to authorize visibility of issues based on the "company" property of the user.

One way would be to have an option in the security levels to match user properties, and to be able to configure which property would be used for this function.

Again, here is the use case, from the outside:

Two users, Alice and Bob, that work for one company.
Alice creates an issue and is set as reporter. Security level is something like "reporter company".
Bob comes in and tries to browse Alice's issue
Since the "company" property values for Alice and Bob are the same, Bob can see the issue.
And we don't have to define a group and a security level for Alice and Bob's company.

We really need this or something very like it.