Recently we started restricting access of contractors. They have our company.com accounts, but we removed them from the Company Users group that we were using to gate access to all projects.
Instead they're now in Contractors - Department groups that we use to grant them access to specific projects.
Additionally we have external users from externalcompany.com invited to access certain projects that are members of a External Company group
A user noted that his filters use:
assignee NOT IN membersOf("Company Users") AND assignee NOT IN membersOf("External Company")
And it is now unexpectedly turning up Contractors that are not in either group.
SO, the Contractors are considered Managed Users since they're in our domain. Is there any JQL hack to let us query on users with the same domain name?
Hello @Darryl Lee
If every user is a member of one and only one of the three groups (Company Users, External Company, or Contractors - Department) the filter as written will return issue where the assignee is in the Contractors - Department group.
Assignee not in ("Company Users") - gets all issues where the assignee is in Contractors - Department or External Company
Assignee not in ("External Company") - gets all issues where the assignee is in Contractors - Department or Company Users
The intersection of AND-ing those two filters is all issues where Assignee is a member of Contractors - Department.
The filter excludes users who are members of either group, which matches your statement:
And it is now unexpectedly turning up Contractors that are not in either group.
...except that this is exactly the expected result.
Can you provide more information about what you are trying to get with this filter?
You said it is to find query for Internal vs. External users. But what does that mean? What denotes an "internal" user and what denotes an "external" user? And which of those are you trying to get through this filter (knowing that the filter is returning issues assigned to the users, not the users themselves)?
Hey @Trudy Claspill so what happened was:
kevinthecontractor@company.com and
darryltheemployee@company.com
Both used to be in Company Users. So I think the query was supposed to identify if any issues were assigned to Other External Company, or something like that.
And this worked until Contractors were removed from Company Users as part of our tightening of access, and moved into their respective Contractor - Department groups.
So I think the solution may be to just identify which Contractor - Department groups need to be added to the query.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If JSM and Assets are available another option would be to have the users defined as objects in a schema and include an attribute that can be used to identify the user as "internal" or "external", and work that into the filter rather than relying on group memberships.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Darryl Lee
There is not really a native JQL way to do this by email domain.
Jira can check whether the assignee is in a group by using membersOf(), but it cannot do something like “match everyone with the same company domain.” Because of that, the more reliable approach is usually to stop trying to infer internal vs external from the account itself and model it directly.
The cleanest setup is to keep one umbrella group for everyone who should be treated as internal, even if access is still managed through separate department groups behind the scenes. Other Way you get lost fast.
Automation is probably the better option. On issue creation and whenever the assignee changes, check the assignee’s group membership and set a custom field like Assignee type = Internal / Contractor / External. Then your filters become much simpler, because you can query that field directly instead of trying to guess from domains or missing groups.
That is usually far more reliable than trying to make JQL infer it indirectly.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.