|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Jeff Turner [Atlassian] - 17/May/04 07:14 PM
Giving this issue a more specific summary so it doesn't get lost.
Abillity to delete a user without losing (closed) issue history is important. Reassigning those would not be correct, and people do change jobs once in awhile...
When a user is disabled, they should also cease being sent notification emails (something the delete-groups workaround doesn't address).
Things disabled user should NOT be able to do:
Things which should still work for disabled users:
Very interesting feature for large companies that have a lot of people coming in and out.
Maybe something like archived versions would work well here. I would also like to be able to hide the disabled users in the user browser.
I would also like to be able to disable users so they don't show up in the drop down boxes. However, I don't want to delete the users for historical purposes. Also, deleting would require reassignment which I also don't want to do.
User archival would be great too so that user management is easier. Just wondering, Matt... if the email is non-existing, like nobody @ jira.com ... does your email application send errors somewhere? That's what I do for employees who have left. I never heard any complaints from I.T. about emails with invalid addresses.
Responding to Neil: yes, our Exchange server will send mails to the bugs account about delayed sending of the email and then warnings appear every minute in the Jira catalina.out logfile. Example of such a warning:
catalina.out.1:36:2005-10-06 10:11:09,289 WARN [service.util.handler.NonQuotedCommentHandler] This user is not in jira so can not add a comment: System Administrator <postmaster@venturiwireless.com> However, if you have the source code, here's a workaround to filter all users who's email address contains "example.com", the official bogus address. From Atlassian Support (Brian Nguyen ) Hi Matt, Unfortunately, modifying the source code is your only option at the Matt's notes: I've attached the modified file for Jira 3.1.1 Professional (the method is actually getRecipients). To compile it, you ought to use the full maven project environment, but I also found that this works: ROOT_DIR=/home/jira/atlassian-jira-professional-3.1.1-standalone/atlassian-jira/WEB-INF MYCLASSPATH=${ROOT_DIR}/classes:${ROOT_DIR}/lib/alt-0.07-jdk1.3.jar:${ROOT_DIR}/lib/propertyset-1.3.jar:${ROOT_DIR}/lib/oscore-2.2.4.jar:${ROOT_DIR}/lib/log4j-1.2.7.jar:${ROOT_DIR}/lib/javacvs-20040721-patched.jar:${ROOT_DIR}/lib/atlassian-core-2.2.9.jar:${ROOT_DIR}/lib/commons-lang-2.0.jar:${ROOT_DIR}/lib/ofbcore-entity-2.1.1-atlassian-06122004.jar:${ROOT_DIR}/lib/ofbcore-share-2.1.1.jar:${ROOT_DIR}/lib/atlassian-ofbiz-0.1.9.jar:${ROOT_DIR}/lib/osuser-1.0-dev-28Jul04.jar
Wow! I didn't know Jira doesn't like this construction: $ { FOO }, without the space. So remove the space where it is used below.
ROOT_DIR=/home/jira/atlassian-jira-professional-3.1.1-standalone/atlassian-jira/WEB-INF MYCLASSPATH=$ { ROOT_DIR }/classes:$ { ROOT_DIR }/lib/alt-0.07-jdk1.3.jar:$ { ROOT_DIR }/lib/propertyset-1.3.jar:$ { ROOT_DIR }/lib/oscore-2.2.4.jar:$ { ROOT_DIR }/lib/log4j-1.2.7.jar:$ { ROOT_DIR }/lib/javacvs-20040721-patched.jar:$ { ROOT_DIR }/lib/atlassian-core-2.2.9.jar:$ { ROOT_DIR }/lib/commons-lang-2.0.jar:$ { ROOT_DIR }/lib/ofbcore-entity-2.1.1-atlassian-06122004.jar:$ { ROOT_DIR }/lib/ofbcore-share-2.1.1.jar:$ { ROOT_DIR }/lib/atlassian-ofbiz-0.1.9.jar:$ { ROOT_DIR }/lib/osuser-1.0-dev-28Jul04.jar
Hey Matt - I see you've stumbled on to JRA-8175 here too.
Anyway, wouldn't it be easier to have I.T. give you a fake email address that you can use, that won't generate errors? It'll just build up in a mailbox that nobody accesses. Things I'd like to see when an account is disabled(mostly what others have said):
Login disabled This will be a big issue for us also. I am in the process of importing a very large number (>150,000) of issues from 2 seperate repositories. In the process, about 2000 users will be created of which only 50-75 are still with the company. User management seems very difficult with that many users.
Another use for a 'disable' flag would be in conjunction with the POP/IMAP mail handler, which creates users automatically for the 'From' address. These automatically created accounts have a random password set initially, but the reporter could click the 'Forgot email' link and access 'their' account. Sometimes this is not desirable, and users created automatically from email should be disabled by default.
Another reason for having a 'disable' flag: When a user has subscriptions and has checked "Email zero results" when subscribing, then JIRA will continue to send them empty subscription emails.
For me I'd like to see:
I would like to be able to do something similar. Perhaps it is a permission? I would like the ability to disable certain users from being assigned/reassigned issues.
That's simple to do. Make sure your permission schemes do not have any assignable users permissions Any news on this issue? The above issues (summarized by David Armstrong in his Nov 29, '06 comments) are legitimate JIRA issues that need to be addressed.
Further to that, we have JIRA version 3.12.1 running in one of our lab servers. After disabling the user (by removing him from all groups): 1. He still shows up in the Browse Users Select List (meaning he still can be assigned to an issue) Thanks. Matt - well, we disabled the Assignee field in our JIRA and use a custom field. The disabed user is still in the selection for this custom field. He also appears in the Reporter dropdown list (which is a JIRA field).
Thanks Here is what I just did and is as of now our "disabling process"
1. Change user password A feature that would disable users would be much more convenient, however. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
User Management: Disable user accounts
