We are currently looking into how the soon to be released privacy settings for users will affect our apps, specifically Tempo Timesheets and Tempo Planner. We are particularly interested in the default state, and the admin tools provided to control these privacy settings for managed accounts.
Our understanding of Atlassian’s plans for introducing the user privacy settings is that for personal accounts, the defaults (other than email) will be public, but for managed accounts the defaults will be private, at least for full name and avatar. Furthermore, our understanding is that 3rd party apps visibility will be limited to public information.
So our concerns are mainly related to how the display of user information will change in our apps when these changes are rolled out. For example, will the full name and avatar of managed users be replaced with public name (which is basically a nickname) and the “obfuscated” avatar, respectively?
How will this appear to users relying on extracting time tracking reports for their employees? Will they no longer see the full name and avatar of their employees - unless each one of them makes changes to their privacy settings?
How will this appear to the end user of the app looking at information about him/herself? In Tempo we have a page which is dedicated to users’ time tracking and planning information. Will an end user looking at this page for him/herself only see the public name (nickname) and avatar placeholder?
Secondly we are concerned about availability of tools for administrators of managed accounts to control which user attribute privacy settings are editable by the end user. In a business environment we don’t think hiding users (employees!) full name in a business application will be useful, or indeed welcomed by their employer. To be fair - in last weeks webinar it was stated that these tools will be available from launch, so perhaps this is not a concern any more.
I would love the get some insights from Atlassian about how these changes will affect business users of Jira. What we are really trying to understand better is how our apps will be affected, particularly for existing users, at time of launch.
It would also be very interesting to hear from other vendors with similar concerns.
Apologies for the delay responding to this topic. I’d recommend following the weekly updates if you haven’t seen them already. One of the topics we’ve been updating status on is Testing Profile Visibility controls so that you can explore product behaviors prior to launch. I’d expect that this testing period will help resolve any uncertainty as well as identify critical blockers. I’d also recommend taking a look at the Guidelines for Testing Profile Visibility controls which provides code examples of user objects post profile visibility controls.
As mentioned to @hlynur in a private conversation, I expect our biggest gap at launch to be the impact of restrictions around access to and use of email addresses. We intend to provide access to email address via a separate API for apps with approved use cases. I’ve just recently published Guidelines for requesting access to email address which will describe the approval process and direct you to the service desk where you can start raising requests.
The issue @hlynur mentioned regarding the versions of name and avatar for users in managed accounts was also discussed privately. This is a known gap, however, applies to a much smaller population (managed accounts are ~1% of Atlassian Account types. The majority (99%) of accounts are personal accounts which would have the same default settings as our products).
Taking a look at my webinar notes now, I don’t think we’ve stated that these admin controls would be available at launch. I apologize if this was a miscommunication. We have started discussing admin controls as a way to remediate the issues with managed accounts but this is planned as a fast follow and not something that would be available at launch. Instead, I’ve begun exploring different ways we could explain to customers with managed accounts what they’re experiencing at launch as a way to gauge impact. I’m open to suggestions.
Semi-related to the profile visibility control topic - if you haven’t seen the comms around updating your app descriptor to signal readiness for the deprecation of user references from our APIs please check out this blog. We really need to increase engagement on the mechanism described for signaling (either gpdr:true if you’re ready or gdpr:false if you’re still working on it). Opting in (gdpr:true) to the new API behaviors won’t change the information you get access to per profile visibility controls but will stop sending legacy user references. Opting out gdpr:false tells us that you’re not ready for the removal of username or user key.
Thanks for the feedback @akassab. The access to the email will be covered with your plans I believe, so I’m not too concerned about this.
What I am trying to achieve, is better understanding of how data will appear to our customers/users after the change. I can take our own usage of Tempo as an example; We use managed accounts and the full name and avatar are always visible in Tempo apps. After you have rolled out the privacy changes, and assuming I have not taken any action - either as admin or just me, the end user - will Atlassian API’s now only return the nickname/display name, and if so, what will the nickname/display name be? We can probably try this out ourselves after March 11th, but I was hoping you could describe what behaviour to expect.
I would also love to understand better the reasoning behind making the full name and avatar hidden by default for managed accounts.
And also, you mention 99% of Atlassian accounts being personal (un-managed). What is the ratio within Jira, which is the only thing we care about at this moment in time? How many accounts using Jira are personal vs managed?
Yes, after profile visibility control settings roll out you will see a string presented in the display name field that corresponds to a user’s public name (aka nickname). The default public name is based off of a user’s full name, however, they can change this at any time. Similarly, avatar URLs will be the masked versions of the avatar which I believe appear as a colored background with the user’s initials.
The Jira user object is designed in such a way that you won’t be able to tell which version you are getting. The public name appears as a string in the DisplayName field. Similarly avatar URLs for unmasked and masked versions appear the same. I’ve included examples of the user object for both personal and managed accounts in the Guidelines for Testing Profile Visibility Controls.
We decided to make full name non-public because we wanted to provide a solution in line with our interpretation of applicable privacy laws. Users need to have control over their profile information and who that information is shared with. When an org admin claims a domain to form a managed account, they disable functionality that allows a user to change their display name and email address - in managed accounts these fields are controlled by the org admin. In order to provide functionality that allows a user to control their profile information we created the public name, which can be changed by an end user, and established default settings that would allow a user to control who their display name is shared with given that they cannot change their full name.
I am checking on this but I can’t imagine that it would be much different just looking at Jira. Atlassian Accounts are global, not product specific.
Thank you @akassab - looking forward to hear about how managed vs personal accounts are distributed in Jira.
Regarding the privacy law, we had our own legal experts advice us regarding the do’s and dont’s of GDPR. So our interpretation is that while individuals are certainly entitled to more control over their personal information, there are perfectly valid reasons for lawfully processing personal information. It is up to the data controller to decide what information to process and how to process it, as long as the the purpose limitation principle, and other guidelines are respected. The controller needs to answer to those decisions. So from our point of view, this is all about giving organisations the right tools to lawfully process, or not process, the data they need.
So we basically think that by giving end users of managed accounts unconditional control over what information is hidden is unnecessary in a managed environment.
Anyway - this is how we see things, and we’re worried about negative effects to our customers.
