Emanuel Y added a comment - 20/Nov/2020 7:41 PM Any plans for Jira Cloud ?

Jonas Andersson added a comment - 10/Jan/2017 3:51 PM - edited REDACTED

Mark Lassau (Inactive) added a comment - 05/Sep/2013 12:17 AM apokharel You can see in our EAP Download page that we have already made a public beta for 6.1 Expect to see a release candidate soon, and then the final some weeks after that...

Mark Lassau (Inactive) added a comment - 05/Sep/2013 12:12 AM intersol I think that the only fix for this is to allow Jira to have "shadow-users" or phantom-unes, Jira must have a way to keep working even if the user vanished from the database… This is true. Even with the fix for this issue, it will still be possible for users to be deleted in certain circumstances (eg you can disable the LDAP user directory), as well as legacy data will exist with missing useres. I think you should raise bugs for any problems you see like the two you list. Link them to this issue, or add in comments and I will do my best to get them to the attention of the right people.

Adhip Pokharel added a comment - 29/Aug/2013 1:20 PM Hi Mark, Do you have any timeline for 6.1? Thanks

Sorin Sbarnea added a comment - 29/Aug/2013 10:39 AM Here we are using Crowd with 4 Jira instances, maybe more in the future and I am aware that due to having a new middle tier it would be almost impossible to prevent the account from being removed from the outside system (crown in my case, but also applies identically if you use AD directly). I think that the only fix for this is to allow Jira to have "shadow-users" or phantom-unes, Jira must have a way to keep working even if the user vanished from the database… and still let you: edit a ticket that has an invalid user as Assignee or Reporter edit filters owned by this users and change the ownership Mainly I do think that this could be implemented by always instantiating an inactive/placeholder user by only having its username, even if this user does not exist in any of the directories. You cannot replace all these invalid users with a generic account because it will loose information and even worse, if the user was temporary removed from the external directory, he would loose everything and the database would be hugely affected: this happened several times, by accident or not.

Fabio Coatti added a comment - 29/Aug/2013 6:04 AM We are using OpenLDAP, I will raise another request, hoping to have some answer. It seems that CWD-2762 asks the same thing, unfortunately without much attention so far.

Mark Lassau (Inactive) added a comment - 29/Aug/2013 3:28 AM cova Which LDAP vendor do you use? JIRA v6.1 will include the ability to synchronise a user's enabled/disabled flag for Active Directory. See CWD-995 for details. For other vendors you should raise a separate feature request.

Fabio Coatti added a comment - 28/Aug/2013 9:36 AM One small comment: on our installation, an user is never removed but the password is locked and the user inactivated, to keep references in logs and history as well. As we are using ldap+jira, this make impossible to have jira inactivate users locked on ldap stored information. It would be advisable to have Jira looking a specific field on ldap, say "inactiveuser" and if it set to true Jira will be proceed inactivating the user.

Adhip Pokharel added a comment - 16/Aug/2013 1:16 PM Mark, Here is the details: https://support.atlassian.com/browse/JSP-169592 I had created a support request before i found this page. Please let me know if you are able to see it.

MikeD added a comment - 16/Aug/2013 1:12 PM I can't speak for Adhip, but we are using the rest api to update issues and it's failing because of invalid users and we are only trying to update one field that has nothing to do with a user.

Mark Lassau (Inactive) added a comment - 16/Aug/2013 12:59 AM apokharel We need a workaround until this feature is in place. We are not being able to edit, resolve or close so many of our open tickets. Can you give some details of how this issue is stopping other users from being able to edit, resolve or close issues? I can only imagine you have an uber-restrictive permission setting? How about you include User Picker on that list? Do you mean User Custom Fields?

Mark Lassau (Inactive) added a comment - 16/Aug/2013 12:55 AM mjdamman I think you are interested in JRA-34161 . I believe that if you upgrade to JIRA 6.0.6 you can search for deleted assignees and reporters in Advanced Mode.

Adhip Pokharel added a comment - 15/Aug/2013 6:48 PM - edited Mark, , Your our statement above : If anyone has good reason to add other reference checks to the veto, then I can consider them, but I also want to keep this checking fairly lightweight as the disabled users will be re-checked on every synchronise. My comment: How about you include User Picker on that list? We are running into this issue on version 6.0.3 as we have used User Picker in so many of our Projects and now we can not do anything to update, resolve or close issues after the employee has left the company.

Adhip Pokharel added a comment - 15/Aug/2013 6:35 PM - edited We need a workaround until this feature is in place. We are not being able to edit, resolve or close so many of our open tickets.

MikeD added a comment - 13/Aug/2013 6:33 PM Until we get this fix, is there a way to query (JQL) for assignee or reporter fields that don't have a valid user anymore?

Mark Lassau (Inactive) added a comment - 05/Aug/2013 1:06 AM - edited f.cilia This feature was eventually developed outside of the "embedded Crowd" subsystem, and has been available in all the 6.1 milestones. The latest milestone is 6.1-m03 and available at https://www.atlassian.com/software/jira/download-eap Edit: Sorry, above comment was in relation to this issue, but I believe your question was actually about CWD-995 "Provide ... support for Active Directory's "Account Disabled" flag" Embedded Crowd 2.7 has been incorporated into JIRA 6.1 and should be available for preview in 6.1-beta1. This should be publicly available on the EAP Download page in 3 weeks or so.

Ubisoft (Inactive) added a comment - 02/Aug/2013 11:53 AM La requête #1004393 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user a été crée. Pour effectuer un suivi, et/ou ajouter un commentaire, veuilliez répondre à ce courriel. Cette requête sera traitée dès que possible. Merci de votre collaboration,Your request 1004393 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user has been created. For a follow-up, and/or add comments, please reply to this e-mail. This request will be treated as soon as possible. Thank you for your cooperation, Votre requête / Your request Neeta Dubey commented on an issue Dear Frederic,We need to test this in our test enviroment first and then only we can implement in the production. We also have to do this during the off hours or may be during weekend.JIRA / JRA-24937 When a user is deleted in AD or Crowd, JIRA could keep the user in JIRA as an inactive user Add Comment This message is automatically generated by JIRA.If you think it was sent incorrectly, please contact your JIRA administratorsFor more information on JIRA, see: http://www.atlassian.com/software/jira

Neeta Dubey added a comment - 02/Aug/2013 11:40 AM Dear Frederic, We need to test this in our test enviroment first and then only we can implement in the production. We also have to do this during the off hours or may be during weekend.

Ubisoft (Inactive) added a comment - 02/Aug/2013 9:52 AM La requête #1004389 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user a été crée. Pour effectuer un suivi, et/ou ajouter un commentaire, veuilliez répondre à ce courriel. Cette requête sera traitée dès que possible. Merci de votre collaboration,Your request 1004389 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user has been created. For a follow-up, and/or add comments, please reply to this e-mail. This request will be treated as soon as possible. Thank you for your cooperation, Votre requête / Your request Frédéric Cilia commented on an issue Hi,Crowd version 2.7 seems to be ready to release.It is possible to add it to version 6.1-mXX of JIRA ?ThanksJIRA / JRA-24937 When a user is deleted in AD or Crowd, JIRA could keep the user in JIRA as an inactive user Add Comment This message is automatically generated by JIRA.If you think it was sent incorrectly, please contact your JIRA administratorsFor more information on JIRA, see: http://www.atlassian.com/software/jira

Frédéric Cilia added a comment - 02/Aug/2013 9:46 AM Hi, Crowd version 2.7 seems to be ready to release. It is possible to add it to version 6.1-mXX of JIRA ? Thanks

Mark Lassau (Inactive) added a comment - 07/Jun/2013 12:43 AM logan.stuart The functionality you speak of is being worked on separately in the "embedded crowd" library that JIRA uses for user management. You can watch it at CWD-995 . You can see by its status that it is being worked on as we speak, so unless something goes horribly wrong, I would hope to see it in JIRA 6.1

Logan Stuart added a comment - 05/Jun/2013 2:53 PM Could this include the functionality that if a user is disabled in AD, JIRA could update the user in JIRA to be inactive?

Ubisoft (Inactive) added a comment - 31/May/2013 12:50 AM La requête #984345 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user a été crée. Pour effectuer un suivi, et/ou ajouter un commentaire, veuilliez répondre à ce courriel. Cette requête sera traitée dès que possible. Merci de votre collaboration,Your request 984345 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user has been created. For a follow-up, and/or add comments, please reply to this e-mail. This request will be treated as soon as possible. Thank you for your cooperation, Votre requête / Your request Kavian Moradhassel commented on JRA-24937 When a user is deleted in AD or Crowd, JIRA could keep the user in JIRA as an inactive user Atlassian, can you please adjust your e-mail filters to deal with the Ubisoft auto-replies? This seems to be occuring on a regular basis, where all the watchers get notified of the comments generated by auto-replies, followed by another notification when you inevitably remove the comment. Over the last couple of years, this has generated hundreds of e-mails to me, so I assume plenty of others are getting the same as well.This message is automatically generated by JIRA.If you think it was sent incorrectly, please contact your JIRA administratorsFor more information on JIRA, see: http://www.atlassian.com/software/jira

Kavian Moradhassel added a comment - 31/May/2013 12:48 AM Atlassian, can you please adjust your e-mail filters to deal with the Ubisoft auto-replies? This seems to be occuring on a regular basis, where all the watchers get notified of the comments generated by auto-replies, followed by another notification when you inevitably remove the comment. Over the last couple of years, this has generated hundreds of e-mails to me, so I assume plenty of others are getting the same as well.

Ubisoft (Inactive) added a comment - 30/May/2013 10:17 PM La requête #984333 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user a été crée. Pour effectuer un suivi, et/ou ajouter un commentaire, veuilliez répondre à ce courriel. Cette requête sera traitée dès que possible. Merci de votre collaboration,Your request 984333 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user has been created. For a follow-up, and/or add comments, please reply to this e-mail. This request will be treated as soon as possible. Thank you for your cooperation, Votre requête / Your request John Garcia [Atlassian] updated JRA-24937 When a user is deleted in AD or Crowd, JIRA could keep the user in JIRA as an inactive user Change By: John Garcia [Atlassian] (30/May/13 5:11 PM) Comment: La requête #982505 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user a été crée.Pour effectuer un suivi, et/ou ajouter un commentaire, veuilliez répondre à ce courriel.Cette requête sera traitée dès que possible.Merci de votre collaboration,Your request 982505 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user has been created. For a follow-up, and/or add comments, please reply to this e-mail.This request will be treated as soon as possible.Thank you for your cooperation,Votre requête / Your request Matt Ryall [Atlassian] updated JRA-24937 When a user is deleted in AD or Crowd, JIRA could keep the user in JIRA as an inactive user Change By: Matt Ryall [Atlassian] (26/May/13 8:48 PM) Comment: La requête #981657 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user a été crée.Pour effectuer un suivi, et/ou ajouter un commentaire, veuilliez répondre à ce courriel.Cette requête sera traitée dès que possible.Merci de votre collaboration,Your request 981657 - [JIRA] ( JRA-24937 ) When a user is deleted in AD or Crowd, JIRAcould keep the user in JIRA as an inactive user has been created. For a follow-up, and/or add comments, please reply to this e-mail.This request will be treated as soon as possible.Thank you for your cooperation,Votre requête / Your request Mark Lassau [Atlassian] updated JRA-24937 When a user is deleted in AD or Crowd, JIRA could keep the user in JIRA as an inactive user Change By: Mark Lassau [Atlassian] (22/May/13 8:08 PM) Fix Version/s: 6.1 This message is automatically generated by JIRA.If you think it was sent incorrectly, please contact your JIRA administratorsFor more information on JIRA, see: http://www.atlassian.com/software/jira This message is automatically generated by JIRA.If you think it was sent incorrectly, please contact your JIRA administratorsFor more information on JIRA, see: http://www.atlassian.com/software/jira This message is automatically generated by JIRA.If you think it was sent incorrectly, please contact your JIRA administratorsFor more information on JIRA, see: http://www.atlassian.com/software/jira

Sorin Sbarnea added a comment - 30/Apr/2013 9:14 AM Add: if the user owns any shared filters, veto. Probably, it should be the same logic that used on the manual remove user admin screen, when jira is showing you what is owned by this user.

Mark Lassau (Inactive) added a comment - 30/Apr/2013 3:16 AM I have completed some work on this with a mind to getting this into JIRA 6.1. During LDAP (or Crowd) synchronise, if a user is deleted on the remote end, then JIRA does some checking to see if we actually want to keep a record of the user or not: Firstly it checks if there is a duplicate record in another User Directory (eg a second LDAP directory, or internal users) for the given username. If so, then it is safe to delete this record and let the other directory define the user. If this is the sole copy of that username, then it checks if we want to veto the delete. If the user is the reporter or assignee of any issues, or has made any comments on issues, then the delete is vetoed. Upon veto, we set the user to inactive. If we detect a user has been added again who was previously removed, then we update their details and set them back to active. This will be available for testing in 6.1-m1 which is probably about 5 weeks away (we have to get 6.0 final out the door first ) If anyone has good reason to add other reference checks to the veto, then I can consider them, but I also want to keep this checking fairly lightweight as the disabled users will be re-checked on every synchronise.

Mark Lassau (Inactive) added a comment - 22/Apr/2013 1:53 AM I also have another script that synchronizes LDAP group memberships to JIRA internal groups since a delegated directory doesn't support LDAP group memberships. There is a flag that was added in about 4.4 or 5.0 that allows group memberships to be synched in Delegated LDAP each time a user logs in. HTH

Phillip Brand added a comment - 08/Apr/2013 4:42 PM I've attached the file we've made to make the single class patch to com.atlassian.jira.crowd.embedded.ofbiz.OfBizUserDao. So far it seems to have worked fine, but we are currently testing with a limited number of users, so be warned

David Yu added a comment - 08/Apr/2013 4:33 PM Just to throw another solution out there, disabling the user is possible if you have a Delegated LDAP directory. It's the setup I find most convenient when I have no power over LDAP. I have a script that searches LDAP and deactivates users in JIRA. I also have another script that synchronizes LDAP group memberships to JIRA internal groups since a delegated directory doesn't support LDAP group memberships. The downsides I've found with this solution so far is the occasional user that gets added into a LDAP group in the middle of the day, and I have to trigger the group sync. Also, users are only added when they sign in for the first time. So you can't assign issues to users that have never signed in for example. Since you're so buried in scripts by now, what's another to sync new users? :-|

Ubisoft (Inactive) added a comment - 08/Apr/2013 3:00 PM We are very interested into a solution like this. the fact it delete the user from our jira instance make this feature simply unusable. @ Phillip Brand , Would you be ready to share on your solution? We could team up into testing

Phillip Brand added a comment - 20/Mar/2013 9:31 PM - edited In our case we have JIRA syncing (read-only) with one of our LDAP servers that only contains active users. When a user leaves, their account is disabled and removed from the LDAP server, then JIRA notices this removal and deletes the account as well. If JIRA would instead mark these missing users as inactive it would take care of our use-case. I thought about writing a script to find inactive LDAP users and mark them as inactive through the API, but that doesn't seem possible after 5.1 ( see this ). Instead I've played around with making a single class patch to accomplish it and have something that looks like it works (though isn't thoroughly tested yet).

Blake Duffey added a comment - 21/Dec/2012 1:51 PM Active Directly has a 'disable' user function, yes, but that misses much of the point of the initial request. Nearly every corporate policy (whether public, private, education, etc) requires that users who leave the entity have their accounts removed. As one of the original requestors of this improvement - the current JIRA implementation simply doesn't make sense when viewed through the reality of modern IT policy. A company or a university who wants to leverage a central user identity database is going to be constrained by corporate/university policy, which requires users who leave the company/university to be removed/deleted. Those users have great difficulty leveraging that 'default' user authentication database with JIRA. And you can't change that policy simply to satisfy a quirk of single application. They'll simply not implement JIRA (or implement it in a standalone fashion, as we have, not gaining the benefits of the shared authentication database).

Mark Lassau (Inactive) added a comment - 21/Dec/2012 5:03 AM Hi intersol Disabled users will not receive notification emails. I agree that this is a very important feature of disabled users, and this will not change. As a remark: LDAP/AD has the ability to disable users instead of removing them. My understanding is that not all LDAP servers implement this, but if AD does, then perhaps it is worth considering an "optional" item for LDAP configuration??? Perhaps that would even make this particular improvement request mostly obsolete? With a handcrafted LDAP-query you can change the LDAP-sync to filter these users, so they will act as being removed from LDAP (and have their account disabled in Jira too) Or perhaps we could just set the active flag in JIRA according to that LDAP property? Do you happen to know the property name for AD? How about for other LDAP servers? Do you know if Open LDAP supports disabling users?

Sorin Sbarnea added a comment - 20/Dec/2012 10:54 AM One important thing for adding this: mail notifications are not send for disabled used, something you do want to happen, if not people that left the company will keep getting emails, will not be able to login to unsubscribe. In same cases not having this can even be a security risk as you are loosing information to "outside". As a remark: LDAP/AD has the ability to disable users instead of removing them. With a handcrafted LDAP-query you can change the LDAP-sync to filter these users, so they will act as being removed from LDAP (and have their account disabled in Jira too) Please note that it's important to make the process reversible, people being reactivated in LDAP should have their account in Jira enabled. Also, add this to 5.x and 5.2.x as it applies for current release too.

MattS added a comment - 04/Sep/2012 9:53 PM Chiming in, the only time I've seen people able to modify users in JIRA is with Crowd. I've never seen a JIRA connecting to AD or LDAP that allowed users' information to be modified in JIRA.

Bryan Rollins added a comment - 04/Sep/2012 9:45 PM I've been doing some research with customers on this improvement request, because it can have a negative effect on some customers who have LDAP set up in a read/write configuration. So far I've encountered no customers who use LDAP who have read/write enabled (everyone I have spoken with has only READ access to the directory configured from JIRA). (And just for clarity, because of concerns around how enabling this for customers could impact them, the current behavior is by design, so it's not a "bug", but it is something we want to improve. I know in the end the need is the same for customers, so calling it a bug or improvement doesn't change the desire to have it fixed! We also didn't have a good way to disable users in JIRA until JIRA 5.1, so now that we have disable user, we have an actual way to implement this, as you suggested.)

Sorin Sbarnea added a comment - 04/Sep/2012 1:27 PM Can we have a response from Atlassian regarding fixing this bug, it's a signifiant problem in any Corporate environment. People come and go every day... or hour. Having issues and projects assigned to phantom users causes lots of problems as people may discover months later that important bugs were assigned to people who left the company. By implementing this should be quite trivial to replace the old "remove from groups" when not found, with "disable" when user not found.

Mark Lassau (Inactive) added a comment - 18/Jun/2012 12:38 AM Mark, not sure how you are using the affects versions but I am using 4.4.4, and I think this affects pretty much all versions, no? Yep, this effects all current versions. Normally I would recommend setting the minimum known version that is affected. 4.3 Makes sense here, as we changed our User Management library in that release which made this improvement possible.

Hans Menzi added a comment - 14/Jun/2012 11:24 AM Mark, not sure how you are using the affects versions but I am using 4.4.4, and I think this affects pretty much all versions, no?

Hans Menzi added a comment - 14/Jun/2012 11:19 AM - edited What I do to get around this currently (which is obviously not optimal) is remove the user from the AD group (which removes them completely from the AD view that Crowd has) and then I add a user with the same username in Crowd and disable that user. It works, but I'd rather not have to do that. Sounds like that is what @Jon is doing in the previous comment as well.

Jon Sword added a comment - 07/Feb/2012 2:58 AM Hi, We have encountered this issue as well. We use user picker custom fields to record people who played a role in an issue (ie: Verified By, Escalation Prime ...etc). When the user is removed from AD the information simply disappears from the issue screen. It would be fantastic if the "delete" method would copy the user info over to the local directory and mark it as inactive. I have found that I can do this manually, but I no longer have access to the users full name etc. (it would be a very time consuming process if there is a lot of churn). I know the userid is still stored in the field (I can see errors in the log whenever someone looks at the issue) but since the value disappears from the issue view - end users will see this as data loss.

MattS added a comment - 10/Jan/2012 5:53 PM I suppose so . It was JIRA 4.2.3 with Crowd. A user is deleted from AD and then an issue that is assigned or reported by that user is edited. More info below. I would have expected that the user name would have been displayed as not a link. Oops - an error has occurred System Error A system error has occurred. Please try submitting this problem via the Support Request Page Otherwise, please create a support issue on our support system at http://support.atlassian.com with the following information: a description of your problem cut & paste the error and system information found below attach the application server log file ( C:\Program Files\Atlassian\Application Data\JIRA\log\atlassian-jira.log ) Cause: com.atlassian.jira.exception.DataAccessException: Error occurred while retrieving user with username 'gmadiv01'. Stack Trace: [hide] com.atlassian.jira.exception.DataAccessException: Error occurred while retrieving user with username 'gmadiv01'. at com.atlassian.jira.issue.IssueImpl.getUser(IssueImpl.java:1163) at com.atlassian.jira.issue.IssueImpl.getAssignee(IssueImpl.java:423) at com.atlassian.jira.issue.fields.AssigneeSystemField.populateFromIssue(AssigneeSystemField.java:492) at com.atlassian.jira.issue.fields.screen.FieldScreenRenderLayoutItemImpl.populateFromIssue(FieldScreenRenderLayoutItemImpl.java:103) at com.atlassian.jira.web.action.issue.EditIssue.doDefault(EditIssue.java:94) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at webwork.util.InjectionUtils$DefaultInjectionImpl.invoke(InjectionUtils.java:70) at webwork.util.InjectionUtils.invoke(InjectionUtils.java:56) at webwork.action.ActionSupport.invokeCommand(ActionSupport.java:433) at webwork.action.ActionSupport.execute(ActionSupport.java:157) at com.atlassian.jira.action.JiraActionSupport.execute(JiraActionSupport.java:54) at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:139) at com.atlassian.jira.web.dispatcher.JiraWebworkActionDispatcher.service(JiraWebworkActionDispatcher.java:168) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.jira.web.filters.JiraLastFilter.doFilter(JiraLastFilter.java:69) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.core.filters.HeaderSanitisingFilter.doFilter(HeaderSanitisingFilter.java:44) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:46) at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:77) at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:63) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.jira.web.filters.accesslog.AccessLogFilter.executeRequest(AccessLogFilter.java:102) at com.atlassian.jira.web.filters.accesslog.AccessLogFilter.doFilter(AccessLogFilter.java:86) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.jira.security.xsrf.XsrfTokenAdditionRequestFilter.doFilter(XsrfTokenAdditionRequestFilter.java:50) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:119) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:55) at com.atlassian.jira.web.filters.PathExclusionFilter.doFilter(PathExclusionFilter.java:118) at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:46) at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:77) at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:63) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.seraph.filter.SecurityFilter.doFilter(SecurityFilter.java:213) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.security.auth.trustedapps.filter.TrustedApplicationsFilter.doFilter(TrustedApplicationsFilter.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.seraph.filter.BaseLoginFilter.doFilter(BaseLoginFilter.java:142) at com.atlassian.jira.web.filters.JiraLoginFilter.doFilter(JiraLoginFilter.java:70) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:46) at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter$1.doFilter(DelegatingPluginFilter.java:66) at com.atlassian.oauth.serviceprovider.internal.servlet.OAuthFilter.doFilter(OAuthFilter.java:69) at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:74) at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:42) at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:77) at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:63) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.util.profiling.filters.ProfilingFilter.doFilter(ProfilingFilter.java:99) at com.atlassian.jira.web.filters.JIRAProfilingFilter.doFilter(JIRAProfilingFilter.java:16) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.jira.web.filters.ActionCleanupDelayFilter.doFilter(ActionCleanupDelayFilter.java:59) at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.jira.web.filters.RequestCleanupFilter.doFilter(RequestCleanupFilter.java:53) at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.johnson.filters.AbstractJohnsonFilter.doFilter(AbstractJohnsonFilter.java:72) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:350) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.gzipfilter.GzipFilter.doFilterInternal(GzipFilter.java:81) at com.atlassian.gzipfilter.GzipFilter.doFilter(GzipFilter.java:51) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:46) at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:77) at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:63) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.core.filters.cache.AbstractCachingFilter.doFilter(AbstractCachingFilter.java:33) at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.core.filters.encoding.AbstractEncodingFilter.doFilter(AbstractEncodingFilter.java:41) at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31) at com.atlassian.jira.web.filters.PathMatchingEncodingFilter.doFilter(PathMatchingEncodingFilter.java:49) at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.jira.startup.JiraStartupChecklistFilter.doFilter(JiraStartupChecklistFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.atlassian.jira.web.filters.JiraFirstFilter.doFilter(JiraFirstFilter.java:65) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:662) Caused by: com.opensymphony.user.EntityNotFoundException: No user gmadiv01 found at com.opensymphony.user.UserManager.getEntity(UserManager.java:259) at com.opensymphony.user.UserManager.getUser(UserManager.java:181) at com.atlassian.core.user.UserUtils.getUser(UserUtils.java:37) at com.atlassian.jira.issue.IssueImpl.getUser(IssueImpl.java:1158) ... 120 more Referer URL: http://localhost:8080/browse/CDM-78 Build Information: Uptime : N/A Edition : enterprise Version : 4.2.3-b590 Build Number : 590 Build Date : Fri Jan 21 00:00:00 PST 2011 Atlassian Partner : null Installation Type : Standalone Server ID : BVI9-VGJB-U0KA-B2OU Last Upgrade : 01/Mar/11 2:43 PM Server Information: Application Server: Apache Tomcat/6.0.20 Servlet Version: 2.5 File Paths: Location of entityengine.xml: file:/C:/Program%20Files/Atlassian/JIRA%204.2.3-b590/atlassian-jira/WEB-INF/classes/entityengine.xml Location of atlassian-jira.log: C:\Program Files\Atlassian\Application Data\JIRA\log\atlassian-jira.log Memory Information: Total Memory: 455 MB Free Memory: 148 MB Used Memory: 307 MB Total PermGen Memory: 256 MB Free PermGen Memory: 186 MB Used PermGen Memory: 69 MB System Information: System Date : Tuesday, 10 Jan 2012 System Time : 09:52:24 -0800 Current Working Directory : C:\WINDOWS\system32 Java Version : 1.6.0_22 Java Vendor : Sun Microsystems Inc. JVM Version : 1.0 JVM Vendor : Sun Microsystems Inc. JVM Implementation Version : 17.1-b03 Java Runtime : Java(TM) SE Runtime Environment Java VM : Java HotSpot(TM) Server VM User Name : SYSTEM User Timezone : America/Los_Angeles User Locale : English (United States) System Encoding : Cp1252 Operating System : Windows XP 5.1 OS Architecture : x86 Application Server Container : Database type : hsql Database JNDI address : java:comp/env/jdbc/JiraDS Database URL : Hidden Database version : 1.8.0 Database driver : HSQL Database Engine Driver 1.8.0 External user management : OFF Crowd integration : OFF JVM Input Arguments : -Dcatalina.base=C:\Program Files\Atlassian\JIRA 4.2.3-b590 -Dcatalina.home=C:\Program Files\Atlassian\JIRA 4.2.3-b590 -Djava.endorsed.dirs=C:\Program Files\Atlassian\JIRA 4.2.3-b590\endorsed -Dmail.mime.decodeparameters=true -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Djava.io.tmpdir=C:\Program Files\Atlassian\JIRA 4.2.3-b590\temp -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=C:\Program Files\Atlassian\JIRA 4.2.3-b590\conf\logging.properties -XX:MaxPermSize=256m vfprintf -Xms128m -Xmx512m Language Info: Installed languages: Catalan (Spain) Chinese (China) Chinese (Taiwan) Czech (Czech Republic) Danish (Denmark) Dutch (Belgium) English (UK) English (United States) French (France) German (Germany) German (Switzerland) Hungarian (Hungary) Italian (Italy) Japanese (Japan) Norwegian (Norway) Polish (Poland) Portuguese (Brazil) Russian (Russia) Slovak (Slovakia) Spanish (Spain) Turkish (Turkey) Default language: English (United States) - System Default Request Information: - Request URL: http://localhost:8080/500page.jsp - Scheme: http - Server: localhost - Port: 8080 - URI: /500page.jsp - Context Path: - - Servlet Path: /500page.jsp - - Path Info: null - - Query String: id=17430 Request Attributes - javax.servlet.forward.request_uri : /secure/EditIssue!default.jspa - javax.servlet.forward.context_path : - javax.servlet.forward.servlet_path : /secure/EditIssue!default.jspa - javax.servlet.forward.path_info : /500page.jsp - javax.servlet.forward.query_string : id=17430 - os_securityfilter_already_filtered : true - jira.session.max.inactive.interval : 18000 - jira.request.time.micros : 0 - atlassian.core.seraph.original.url : /secure/EditIssue!default.jspa?id=17430 - com.atlassian.jira.web.filters.JiraLastFilter_already_filtered : true - javax.servlet.error.servlet_name : action - com.atlassian.gzipfilter.GzipFilter_already_filtered : true - com.atlassian.jira.web.filters.JiraFirstFilter_already_filtered : true - loginfilter.already.filtered : true - com.atlassian.johnson.filters.JohnsonFilter_already_filtered : true - jira.webwork.generic.dispatcher : webwork.dispatcher.GenericDispatcher@1f71eb7 - com.atlassian.jira.web.filters.accesslog.AccessLogFilter_already_filtered : true - javax.servlet.error.message : - jira.session.last.accessed.time : 1326217940653 - webwork.result : Value stack =========== =========== - jira.request.username : admin - com.atlassian.jira.web.filters.RequestCleanupFilter_already_filtered : true - javax.servlet.error.request_uri : /secure/EditIssue!default.jspa - com.atlassian.jira.security.xsrf.XsrfTokenAdditionRequestFilter_already_filtered : true - com.atlassian.seraph.auth.LoginReason : OK - jira.webwork.cleanup : false - jira.request.id : 592x162x1 - javax.servlet.error.status_code : 500 - jira.request.start.millis : 1326217944247 - com.atlassian.jira.web.filters.ActionCleanupDelayFilter : true - com.atlassian.jira.web.filters.accesslog.AccessLogRequestInfoexit.called : true - com.atlassian.core.filters.HeaderSanitisingFilter_already_filtered : true - jira.request.assession.id : 1km7en9 - __sitemesh__filterapplied : true - javax.servlet.error.exception : javax.servlet.ServletException: com.atlassian.jira.exception.DataAccessException: Error occurred while retrieving user with username 'gmadiv01'. Request Logging 0 log statements generated by this request: Listeners - GreenHopper Cache Eviction Listener (com.pyxis.greenhopper.jira.listeners.CacheEvictionListener) - GreenHopper Listener (com.pyxis.greenhopper.jira.customfields.GreenHopperCTFIndexer) - Issue Cache Listener (com.atlassian.jira.event.listeners.cache.IssueCacheListener) - Issue Index Listener (com.atlassian.jira.event.listeners.search.IssueIndexListener) - Label Listener (com.pyxis.greenhopper.jira.listeners.LabelSyncher) - Mail Listener (com.atlassian.jira.event.listeners.mail.MailListener) Services - Backup Service (com.atlassian.jira.service.services.export.ExportService) - Delay: 720 minutes - USEZIP: Zip - USE_DEFAULT_DIRECTORY: true - Mail Queue Service (com.atlassian.jira.service.services.mail.MailQueueService) - Delay: 1 minutes - Service Provider Token Remover (com.atlassian.sal.jira.scheduling.JiraPluginSchedulerService) - Delay: 480 minutes - pluginJobName: Service Provider Token Remover Plugins - Admin Menu Sections 1.0 - Plugin by Atlassian - Enabled - Apache HttpClient OSGi bundle 4.0 - Plugin by Apache Software Foundation - Enabled - Apache HttpCore OSGi bundle 4.0 - Plugin by Apache Software Foundation - Enabled - Atlassian Gadgets OAuth Service Provider Plugin 1.1.5.6 - Plugin by Atlassian - Enabled - Atlassian OAuth Admin Plugin 1.0.12 - Plugin by Atlassian - Enabled - Atlassian OAuth Consumer Plugin 1.0.12 - Plugin by Atlassian - Enabled - Atlassian OAuth Consumer SPI 1.0.12 - Plugin by Atlassian - Enabled - Atlassian OAuth Service Provider Plugin 1.0.12 - Plugin by Atlassian - Enabled - Atlassian OAuth Service Provider SPI 1.0.12 - Plugin by Atlassian - Enabled - Atlassian REST - Module Types 2.1.0 - Plugin by Atlassian - Enabled - Atlassian Template Renderer API 1.1.1 - Plugin by Atlassian - Enabled - Atlassian Template Renderer Velocity 1.6 Plugin 1.1.1 - Plugin by Atlassian - Enabled - Atlassian UI Plugin 3.0.9 - Plugin by Atlassian Pty Ltd - Enabled - Atlassian Universal Plugin Manager Plugin 1.1.4 - Plugin by Atlassian Pty Ltd - Enabled - BND Library 0.0.255 - Plugin by aQute SARL http://www.aQute.biz - Enabled - Content Link Resolvers Plugin 1.0 - Plugin by Atlassian - Enabled - Custom Field Types & Searchers 1.0 - Plugin by Atlassian - Enabled - Embedded Gadgets Plugin 1.1.5.6 - Plugin by Atlassian - Enabled - FishEye Plugin 3.0.22 - Plugin by Atlassian Software Systems - Enabled - Gadget Dashboard Plugin 1.1.5.6 - Plugin by Atlassian - Enabled - Gadget Directory Plugin 1.1.5.6 - Plugin by Atlassian - Enabled - Gadget Renderer Plugin 1.1.5.6 - Plugin by Atlassian - Enabled - Gadget Spec Publisher Plugin 1.1.5.6 - Plugin by Atlassian - Enabled - GreenHopper 5.4.2 - Plugin by Atlassian - Enabled - ICU4J 3.8.0.1 - Plugin by Atlassian Pty Ltd - Enabled - Issue Operations Plugin 1.0 - Plugin by Atlassian - Enabled - Issue Tab Panels Plugin 1.0 - Plugin by Atlassian - Enabled - Issue Views Plugin 1.0 - Plugin by Atlassian - Enabled - JDOM DOM Processor 1.0.0 - Plugin by SpringSource - Enabled - JIRA Activity Stream Plugin 3.0.21.1 - Plugin by Atlassian - Enabled - JIRA Bamboo Plugin 4.1.3 - Plugin by Atlassian Software Systems Pty Ltd - Enabled - JIRA Footer 1.0 - Plugin by Atlassian - Enabled - JIRA Gadgets Plugin 4.2.3-b590 - Plugin by Atlassian - Enabled - JIRA Importers Plugin (JIM) 1.6 - Plugin by Atlassian - Enabled - JIRA Jenkins Plugin 0.6 - Plugin by CustomWare - Enabled - JIRA OAuth Consumer SPI Plugin 4.2.3-b590 - Plugin by Atlassian - Enabled - JIRA OAuth Service Provider SPI Plugin 4.2.3-b590 - Plugin by Atlassian - Enabled - JIRA REST Plugin 4.2.3-b590 - Plugin by Atlassian - Enabled - JIRA Shared Application Access Layer (SAL) Plugin 4.2.3-b590 - Plugin by Atlassian Software Systems - Enabled - JIRA Usage Hints 1.0 - Plugin by Atlassian - Enabled - JQL Functions 1.0 - Plugin by Atlassian - Enabled - JSON Library 20070829.0.0.1 - Plugin by Atlassian Pty Ltd - Enabled - Joda-Time 1.6 - Plugin by - Enabled - Keyboard Shortcuts Plugin 1.0 - Plugin by Atlassian - Enabled - Neko HTML 1.9.12.1 - Plugin by Atlassian Pty Ltd - Enabled - Portlets Plugin 1.0 - Plugin by Atlassian - Enabled - Preset Filters Sections 1.0 - Plugin by Atlassian - Enabled - Project Panels Plugin 1.0 - Plugin by Atlassian - Enabled - Project Role Actors Plugin 1.0 - Plugin by Atlassian - Enabled - ROME, RSS and atOM utilitiEs for Java 1.0 - Plugin by Sun Microsystems - Enabled - ROME: RSS/Atom syndication and publishing tools 0.9.0 - Plugin by SpringSource - Enabled - RPC JIRA Plugin 4.2.3-b590 - Plugin by Atlassian - Enabled - Renderer Component Factories Plugin 1.0 - Plugin by Atlassian - Enabled - Renderer Plugin 1.0 - Plugin by Atlassian - Enabled - Reports Plugin 1.0 - Plugin by Atlassian - Enabled - Shared Application Access Layer API 2.1.0 - Plugin by Atlassian - Enabled - Top Navigation Bar 1.0 - Plugin by Atlassian - Enabled - User Format 1.0 - Plugin by Atlassian - Enabled - User Navigation Bar Sections 1.0 - Plugin by Atlassian - Enabled - User Profile Links 1.0 - Plugin by Atlassian - Enabled - User Profile Panels 1.0 - Plugin by Atlassian - Enabled - View Project Operations Sections 1.0 - Plugin by Atlassian - Enabled - Web Resources Plugin 1.0 - Plugin by Atlassian - Enabled - Webwork Plugin 1.0 - Plugin by Atlassian - Enabled - Wiki Renderer Macros Plugin 1.0 - Plugin by Atlassian - Enabled - Workflow Plugin 1.0 - Plugin by Atlassian - Enabled

Mark Lassau (Inactive) added a comment - 09/Jan/2012 11:38 PM Editing an issue with that user as a reporter or assignee then produces a big ugly trace in the screen. That would be a bug. What version of JIRA are you using? I don't see this behaviour in 4.4 or 5.0.

MattS added a comment - 09/Jan/2012 6:22 PM I just had this very discussion with a large health organization. Their problem is that if a user is deleted from AD, then the user disappears from Crowd and then JIRA. Editing an issue with that user as a reporter or assignee then produces a big ugly trace in the screen.

Blake Duffey added a comment - 16/Nov/2011 4:42 PM This is a huge issue for us - we have no control over the back-end ldap (corporate AD) and would like to integrate without the system falling apart when a user leaves the company. Thanks

Mark Lassau (Inactive) added a comment - 07/Nov/2011 4:42 AM Except JIRA has not concept of inactive users at this stage. See JRA-2220