There are situations when we need to have user accounts in JIRA/ Confluence used only for mass mailing. We create a user account with a generic username and a mailing list address, for example user is 'my-list' and email is 'firstname.lastname@example.org', and then subscribe to the updates/ filters using that account. Or else, add that account as a watcher.
For security reasons, this user must not be able to log in and also must not be able to reset the password through Crowd. Disabling the account won't work because user won't receive e-mail when disabled.
Is there any user attribute that Crowd administrators can manually set so that user won't be able to log in?
I believe there's no easy way to do this (source: I'm a Crowd developer).
The closest you could do is to set the password to some unknown value in Crowd, and set up some alert to watch for the password reset email coming through the mailing list. Or filter the password reset message from being allowed to get onto the mailing list by passing it through some interceptor account first.
Or write a script to reset the password of the user every 15 seconds.. but that still leaves you open to attack by any determined attacker.
You could try removing the jira-users group from that particular user account, but I suspect that the user won't receive notification emails from JIRA if you do that.
(As a more hardcore solution, you could modify the reset password action in Crowd to protect against resetting that hardcoded user's password and then rebuild and reinstall it from source, but source modifications like that are unsupported so you may not want to go down that route.)
You'd also need to ensure that the user can SEE the Jira issues for which they need to be notified, which usually means they need to be in the role of "users" and the usual way to do that is to put the "jira users" group in there.
The obvious workarounds would be to enable anonymous browse in the projects (although that would let non-logged-in users see the issues), or include them some other way that does not involve using jira-users. I'd be tempted to create a role like "snoop" or "user mail", and grant that "browse" in the permission schemes. Or put all these not-really-users into a big group and put that in the schemes.
For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events