Hi @hlynur, @arek , @remie, @vit -
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.