Auditing users and groups

[Patrick Vijgeboom]

Hello,

I am looking for an audit way to get the following insights:
- Which project settings are changed and by whom.
- Where are users within Jira and what roles do they have within various projects
- What is the best practice for deleting old accounts. Currently we disable the accounts

Maybe someone here have some tips for monitoring users and groups other other tips that is usefull for auditing.

[Rilwan Ahmed]

Hi @[deleted] ,

1. You can go to Admin settings --> System --> Audit logs. This has the information. 

2. You can find then in project settings --> Users and Roles
Or Admin settings -> User management and search  for required users. Against each user there will 3 dots and you can find project roles for that user. 

3. Disabling account is the best option. Because 

When you deactivate a user, that user: 

• Will no longer be able to sign in to Jira.
• Will not count towards your Jira user license limit.
• Can't be assigned issues or added as a watcher to issues whenever issues are created or edited. However:
  • A user who was assigned, was watching, or had reported any issues in Jira before their account is deactivated, will still appear as the respective assignee, watcher, or reporter of those issues. This situation remains until another user is specified as the assignee or reporter, the deactivated user is removed as a watcher from them, or the account is reactivated.
  • A user who voted on any issues in Jira before their account is deactivated will continue to appear as a voter on these issues.
• Will continue to appear on the Jira user interface with "(Inactive)" displayed after their name.
• Can still be used to filter issues in a Jira search query.
• Will not receive any email notifications from Jira, even if they continue to remain the assignee, reporter, or watcher of issues
  
  This is described clearly in https://confluence.atlassian.com/adminjiraserver/create-edit-or-remove-a-user-938847025.html 

[Nic Brough -Adaptavist-]

This is not as simple as you might imagine, and it's worth questioning why you are asking.  

I'll answer your questions in a different order, easiest first:

- What is the best practice for deleting old accounts. Currently we disable the accounts

Do not delete them.  That causes all sorts of problems in the data, including destroying your ability to track who did what (i.e. you can't "audit" stuff with deleted users).  Disabling them is absolutely the correct thing to do, for the reasons Rilwan gave.

- Which project settings are changed and by whom.

Project settings can be changed by project admins and Jira administrators.  Some of these actions are tracked in the internal admin audit log, but it's not as simple as "admin changed project settings".  An admin can change things that a project uses for configuration without changing the project.  Workflows, schemes, fields - all changeable without changing the project.

Jira doesn't have code that tries to track every single change an administrator makes.  The last time I was asked for something like this, I was able to read the proxy access logs and see where our administrators had been hitting admin screens and making change (but not what the change was, just that they'd committed a change).  One week gave us 20,000 lines to analyse.

- Where are users within Jira and what roles do they have within various projects

There are a massive pile of problems with asking for that.  Taking it just as read, in theory, yes, you could just get a list of "user / project / role", but why?  Of what possible use is that to you?

It doesn't tell you what users can do in a project.  It's not useful out of the context of what the membership means.

It's also a difficult thing to get.  You can read each role, look at the people in it and extract that, but you'll also need to read every group that is in a role, and expand that out.

The context then makes it worse.  If you're actually asking for a simple "who can SEE the project", you have to read the permission "Browse project" to see what roles, groups and users are named directly in the scheme.

It then gets 10,000 times worse if you look at other permissions - "who can *edit* an issue" - again, roles groups and users are named, but you are also going to have to read every single issue in the project as well - if you have used a dynamic role (reporter, assignee, project lead) or custom field in the permission, then the people list can vary by issue.

So, I think your best option would be to take another look at the problem.  What do you really want from "a list of users in a project"?  What is it going to be used for?

[Patrick Vijgeboom]

@Nic Brough -Adaptavist- Thank you for your very comprehensive reply. One of the tasks is when an employee leaves employment. We then want to dislike the account and also remove the account from all projects. It is useful to have a list of where this account is used instead of looking project by project to see if the account exists there.

[Nic Brough -Adaptavist-]

Why do you want to remove accounts (that can't do anything) from a project?

What problem are you solving by removing them from projects?

[Patrick Vijgeboom]

@Nic Brough -Adaptavist- Clean Desk so to speak and for our audits. 

[Nic Brough -Adaptavist-]

The data you're asking for is useless for auditing, it doesn't contain the context within which the users can act.

Cleaning up is always a good thing to do, but in this case, it's a hideous amount of work for doing something that is pretty much cosmetic.  A disabled user can't do anything, nor be assigned or otherwise used by other people as new data. 

There's nothing wrong with tidying them out of project roles and groups for simplification, but it doesn't change anything in the way Jira works.

At larger places where I was an admin and they were using the internal users, I had a simple weekly or monthly task to go through the recently disabled users and remove them from the groups.  I also had a policy of only ever using roles unless groups were absolutely necessary, which kept that task simple.  Then we asked project owners/admins to remove deactivated users from the project roles whenever they went into their project roles to add/remove people.