We have the same issue here. We test a lot with new roles as we use a bunch of Atlassian products, so it is necessary to test the user view, especially when they have problems finding a ticket or a field.

can't Belive this is still an issue i look all comments from 2016 to date, is there any plan for adding this fix??

You could notify only the admins, not the users in question (in Dropbox Business this is how it happens).

Hi,

Can't believe this is still an issue and we can't turn off as admins?

Please consider this request!

I have the same issue and would prefer to be able to enable or disable it globally. That allows each instance to set their policy.

As it is currently, my workaround is to use group-based permissions and assign the same permissions to a test user - who I then log in as.

Hi,

This is an important feature to us. We do need to occasionally log into JIRA as one of our customer users in order to test what they see for example.

However, when the customer gets the email alert it raises lots of questions and dialog with the customer which is all unnecessary. In other systems we use e.g. Salesforce, you can log in as users and they do not get email alerts.

At the very least the email alert to the user should be optional. We as admins already have access to all data and admin settings so why would the customer need to know we are logging in as them?

Please reconsider adding this request to your roadmap.

Niall

I've been thinking on this topic.

While not sending a notification would be the easiest and most straightforward solution for doing things that can currently be done only by impersonating users (therefore, having to ask for permission and/or provide explanations), I agree that it would be a better approach (though slower) to implement new administration features for minimizing the need for user impersonation.

Hi @mfitzbaxter

I'd like to add some comments about the arguments used for not implementing this feature:

(...) stop potentially malicious or disgruntled administrators from transacting on behalf of others with the intention of gaining information, misrepresenting a users opinion, or just general mischief.

Reversely, a user who had recently received an email that states that you (a JIRA admin) have logged in with their account and can perform actions on their behalf, can maliciously blame on you for their own evil actions.

Besides, even honest users may suspect that you are the responsible of their own mistakes just because "things were as they should, then I receive this email, and after that, things are no longer as they should".

Mind that this kind of thought is likely to arise even if their mistake happened several days after that, specially with people which are generally reluctant to admit their own mistakes (a more than frequent personality type than one might expect!).

However, I think that security should be granted by registering this kind of impersonation in the audit log (see ID-6171).

Sending an email notification to all admins each time an administrator logs in as another user would be better than forcibly sending an email notification to an end user.

Needless to say that a JIRA administrator currently has many different ways for doing bad things.

Allowing admins to 'log in as user' without sending an email to the user:

• has many legitimate usages including, but not limited to: configuring personal dashboards & filters, set foreseeable custom user preferences, fixing sharing of user filters/dashboards/boards, fixing private filter JQLs, assessing whether or not a status/custom field can be deleted from the instance by reviewing its usage in personal filters (btw, this one is worth a new feature request)... and so on.

• is the* most efficient and scalable way for doing things that need to be done* without having to invest time in explaining to users what needs to be done. Many times, they don't mind at all, or are not able to really understand the need for entering their accounts.

I am the only JIRA admin in charge of the administration of a 500 users instance, so the reduction of the investment of time I must spend on doing a task is critical for me.

• prevents the user from panicking because of reading that someone might perform actions on their behalf. Even if they receive an explanation, they are not granted to trust you.

Please, reconsider implementing this suggestion.

Kind regards,

Ignacio Pulgar

Hey Mike, thanks for taking the time to read and respond.

I totally agree with you, from a philosophical point of view - if anything, the past years have demonstrated the value of identity and privacy.

But I will be the devil's advocate on this one: your clients are the administrators, not their own customers.
While it is good to have the latter's interest at heart also, it is counter-effective to implement feature that can work against your main target audience.

If we finance (and in my case, it is quite an investment for the companies I work for) a tool and provide it to users, so that we can help them and drive better outcome, it should be our decision on how we can use it.

As I wrote, in our case we do not snoop on our users or anything - we need to test what they see, because most are members of the general public using the Service Desk to report issues with their software, or ask a team of traders to re-balance their portfolios.
Since one of our SD is open to all, we end-up with customers creating several accounts (almost a new one each time they post a request) due to a typo in their email or something - then they complain that they don't receive updates or cannot see them once logged in.
Not your problem at all, but definitely something we would mitigate easier with the "log in as user".

I have to also be honest and state that, if the setup for our specific cases was easier to do in Jira, we would probably not need to impersonate our users in the first place.
Unfortunately, because of specific use-cases that our own organisation is bringing, we have many issues with permissions and notifications.

I know it is not possible to cater for all, and you can quote me as a big Jira fan and long time user. I am the Jira champion in my business and I use it from Agile user requirements gathering to Online Support, with a strong history using Tempo in the past and JIra capture - stuff that will always be a point of difference with the likes of Zendesk and Freshdesk.

But, as the end-client to Atlassian, I wish I could bend Jira more to my requirements on some stuff

Hi Chris,

thanks for the feedback. As I'm sure you can imagine, there are many uses for Atlassian products and we need to provide an identity platform that works for all. In your scenario, where you have specific user requests to the administrator to ensure information is properly hidden it might make sense to allow the Administrator to disable the notifications to end users.

Please understand however that there would be an equally valid reason to leave this feature enabled to stop potentially malicious or disgruntled administrators from transacting on behalf of others with the intention of gaining information, misrepresenting a users opinion, or just general mischief.

Putting the option to turn this feature on or off in the hands of the administrators would be giving the keys to protecting users identity to the wrong person. If we were to implement this feature at all it might be to allow a user to enable the "hide further notifications about an administrator accessing my account" within their profile (although this has not been discussed as a feature internally to date).

Perhaps if an administrator has a valid reason for accessing the user account they should be upfront with the user about the impending access and welcome further security notifications. If users are genuinely seeing unusual access to their accounts you would surely want them notified and in turn reaching out to you to confirm the access is legitimate and not the result of a stolen administrator account?

We are constantly looking to improve the security tools we give to users and administrators to protect access to sensitive content and we are looking to announce soon a raft of new security tools to better protect your users. These tools can include the ability to enforce 2FA on accounts, and provide SAML authentication options to allow you to manage your users within your own corporate identity provider.

We are always looking to improve the notifications we send our users, and at present we believe that users need the ability to understand when anyone is accessing their account on their behalf.

If you feel administrators need better tools to notify people about impending access and the reasons for needing access, before the access takes place then whilst it certainly isn't currently on our roadmap we would be interested in hearing what that might look like.