-
Suggestion
-
Resolution: Unresolved
-
None
-
0
-
Ability to email more than 50 users
- Ability to add multiple emails for Send Mail automation action - Currently, when creating a Send Mail action on your automation rule. You have to enter each 'To' email address separately. I currently have 55 to add and have to do it 4 times, but if we had the functionality to copy, I could have done it once and simply copy and pasted the action. If you enter something like this; email1@test.com; email2@test.com; then it simply combines it into one email address and nothing happens when you run the rule. It would be good if we can simply copy a list of email address and paste into the To field and it would separate each email. On MS Outloook, using email1@test.com; email2@test.com; separated the email so maybe the same functionality can be added?
- Send Email action will only send to the first 50 users in a group (if group is greater than 50) - The Send Email action will only send to the first 50 users in a group with size > 50. This limitation is currently coming from the downstream Identity API which imposes a 50 user limit. We should send to all users in the group.
Currently, Automation for Jira has a limit when using roles, automation conditions don't support roles with more than 50 users, it would be helpful to don't have this restriction.
User condition or using groups in the "to" address of Send email action doesn't work if the role has more than 50 members
- duplicates
-
AUTO-1119 When using Groups in the TO, CC or BCC fields for "Send Email" action, it only fetches up to 50 users
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
ENT-946 Failed to load
- is related to
-
- Gathering Interest
- mentioned in
-
Page Failed to load
-
Page Loading...
-
-
-
-
-
[AUTO-127] Automation for Jira, remove the role user limit in conditions and the "to" address of the Send Email action (currently limited to roles with 50 users)
Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?
Thanks! I will try it also. Would be good for someone at Atlassian to confirm that this is now supported 89403358cf11?
No warning message. I tried to fail the rule multiple times and it hasn't (so far)
Interesting, thanks 57dc0eacecd2 .
Do you still see the warning message around 50 members even though it looks to work for you now?
Atlassian appears to have resolved this. I created a simple rule that copies the Reporter to the Assignee field.
- If the Reporter is a part of the Developers role (that role is associated with a group containing 3000+ users), it will copy the Reporter value to the Assignee field.
- If the Reporter is not a part of the Developers role, it will email me to notify me that the user needs access to the project.
Both of the scenarios worked for me!
if you have a Jira instance of over 500 people this already becomes very limiting. Why is the limit there at all...?
Please fix this limit. 50 users is an insanely small number...I cannot believe this is an actual limitation and the bug has been open for 4 years.
I don't understand if this is actually a bug or something that needs a feature update. There is also a bug report for this same thing: https://jira.atlassian.com/browse/AUTO-1066
In either case, it should be resolved. I am sure MANY of your customers have more than 50 members with the role Service Desk Team, especially since you keep adding more and more (good) features to JSM. However, if you are going to have an automation at all that can target users in a role, it should certainly support more than 50. Our main project currently has over 100 SDT members and we can't do easy things we can on smaller projects like auto-assign an issue to someone who resolves it if the assignee is empty IF they are in the SDT role (don't want it getting assigned to customers). This works great in smaller projects and is much easier to maintain than with groups.
Our team would love this too. We often have assignment rules that fail because of an inactive user.
Who decided that a cap of 50 would be a wonderful idea? 
This limit doesn't make sense for roles like Service Desk Team. I still get the 50 limit error