I agree with @marc that the user directory visibility is a breaking change from an app’s point of view, although the limit of the breakage should be limited to only that for any well-behaved app (meaning that any extra space/page leakage should have already be addressed through the regular permissions model).
In terms of the user-picker itself, having an easy way to identify guest users in all contexts would be ideal, and I think some holes are missing in what is provided to apps (as described above).
But it seems like Atlassian could already fix this on their own, without vendor interaction or rolling out new APIs, by having the user search API return an appropriately-filtered list of users. This should already happen automatically on the front end without any vendor intervention. On the back end, this would require that the app vendor use ACT_AS_USER for the user search call, so it is possible this might require a change…but having the user picker run on the back end rather than front end seems like more of an exception than a rule to me.
This brings up two other points:
-
Is “is a guest user?” actually the correct information to be surfacing to apps? Would this not be more appropriate as a “Can see user directory?” value, given that guest users are not otherwise special from a space/page permissions perspective? This also becomes a future-proof decision if Atlassian decides to provide the ability to limit user directory access in other ways.
-
Blocking all apps for guests seems to go in the opposite direction of making the ecosystem seamless. We have first-class features built into Confluence and Jira that always have access to the entire platform, but we are starting to see more features shipped that were not planned with the ecosystem in mind (including the very feature we are discussing). This leads to apps being second-class citizens with broken or limited functionality. For example, try using Confluence macros on Jira Project Pages. While it is a balancing act, I think Atlassian needs to figure out how to provide a full experience for guest users to those third-party products that are able to support it. An opt-in approach seems like it would satisfy @marc’s needs as well as the greater community’s.