You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.