[#JRA-11773] CLONE -Add "reporter domain" permission

JIRA

CLONE -Add "reporter domain" permission

Created: 15/Dec/06 10:04 AM Updated: 10/Apr/07 01:02 PM

Component/s:

Permissions Security

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

Issue Links:

Cloners

This issue is derived from:

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

Reference

This issue relates to:

JRA-9014 Add "Reporter Group" Permission

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

JRA-5509 Reporter Group permission

Participants:	=Neal Applebaum, Brett Adam and Reid Sayre
Since last comment:	1 year, 25 weeks, 6 days ago
Labels:

Description

« Hide

Currently, we have an issue security scheme that specifies a security level of "Reporter plus support." Of course, the "Users/Groups" for this level is "Reporter" plus the group of users that comprise the support folks. This has worked really well for us.

Some of our "customers" have more than one user that submits issues, and they would like to see all the issues reported by their "company."

Rather than try to manage this with separate groups (one for each customer, I would like to try this:

We need something like a "Reporter Domain" user/group and when this is specified, security checks would work similar to the "Reporter" user. But instead of comparing the id of the current signed-on user with the id of the reporter of the issue, compare the e-mail domain of the signed-on user with the "reporterdomain" custom field (that is implemented by one of the Atlassian supplied plug-ins) in the issue.

We would like to see this as both an issue security level and as a transition condition.

Clearly the execution code change is very small. The trick is going to be getting this configurable, translated, documented, etc.

A portion of this is already implemented in that we already have the "reporterdomain" field configured.

Of course, using e-mail for this introduces it's own set of requirements on registration. For example, there needs to be a flag in configuration to require e-mail verification. That is, it should not be possible for someone to register with an e-mail address of tom@mycompany.com and then be able to look at all issues reported by anyone at mycompany.com without at least going through mycompany's e-mail system first.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Brett Adam added a comment - 15/Dec/06 10:06 AM

Nick,

JRA-10364 by itself doesn't address the need for security levels tied to groups of users. While a so-called "DynamicGroup" solves the group-membership problem, since there will be many such groups (one per domain let's say) there's still no way to create a security level that resolves to the "DynamicGroup" that the Reporter is a member of.

Thus, while projects could be configured one per customer group, issues posted to shared projects cannot be partitioned without manual intervention and the creation of one security level per customer group.

I think you should reopen this issue with a clearer (narrower) goal perhaps.

[ Permlink | « Hide ]

=Neal Applebaum added a comment - 15/Dec/06 01:50 PM

Brett,

I use a user-contributed plugin to achieve this. It sets security based on group of reporter, so multiple users at the same site can see each other's issues.

[ Permlink | « Hide ]

Reid Sayre added a comment - 10/Apr/07 08:47 AM

Neal,

The user contributed plug-in doesn't help much in that it still requires some manual (or maybe automated) process to add users to particular groups. We are looking for something more dynamic.

Here is the functional story we are looking to solve:

User1 registers with an e-mail address user1@company1.com. This user can not assign his own password, but a random generated password is sent to his e-mail address so that we know his e-mail address is valid.
User1 creates an issue.
User2 registers with an e-mail address user2@company1.com, same as User1 above.
User3 registers with an e-mail address user3@comapny2.com, different e-mail domain from user1 and user2 above.
With NO ADMINISTRATIVE INTERVENTION OR PRE-EXISTING KNOWLEDGE OF THE COMPANIES INVOLVED, user2 can see the issue created by user1 but user3 cannot.

Now, somewhere in the JIRA code the question is asked: "Can this user see this issue?" The answer, of course, is related to issue security. The solution we propose is to add "reporter domain" to the types of access on the "Add User/Group/Project Role to Issue Security Level" page. If this access type is specified, then the following kind of code would be run when JIRA decides whether or not the current user can see the requested issue:

Find e-mail domain of current user
Find e-mail domain of reporter
If they are equal, current user can see the issue.

Of course, conceptually, it seems pretty easy. But the internal JIRA details are complex and it depends on e-mail address verification. And we might want to not do this for domains like gmail.com, yahoo.com, and a few others. And this must be a configurable list, not a code change.

[ Permlink | « Hide ]

=Neal Applebaum added a comment - 10/Apr/07 01:02 PM

There might be some other similar issues like this (e.g. JRA-5509), but relying on the actual domain name of the user's email address is not, IMHO, the way to go. I have a private installation so users cannot sign up themselves, (nor can they change their email addresses). In the scenario you described above, I see a potential security risk where, by changing my email address, I could see others' issues. Also, I have the need for my clients to view each others' issues even though they don't have the same domain name (e.g. company1.com, company1.ca, or a 3rd party consultant a company2.com). Your comment about gmail.com already touched on that.