Clarify effects restricting Public visibility on user info
What does this MR do and why?
This MR updates the documentation on Restricted visibility levels to clarify the impact of checking Public. This is in response to a ticket. It's not immediately clear from the documentation that setting Public would prevent the GraphQL API from returning information about users
. This MR addresses that.
See this confidential issue for more information about how this setting is used and recommended:
Setting Public makes it so that GraphQL queries like the following return an error instead of results:
{
users{
nodes{
username
publicEmail
name
state
webPath
avatarUrl
}
}
}
With Public checked, you'll see something like this instead:
{
"data": {
"users": null
},
"errors": [
{
"message": "The resource that you are attempting to access does not exist or you don't have permission to perform this action",
"locations": [
{
"line": 31,
"column": 5
}
],
"path": [
"users"
]
}
]
}
Wording
In the first bullet, I intentionally used logged in users to match what's in the Admin Area. I adjusted that to authenticated
users for those interacting with the GraphQL API. I'm very open to alternative approaches but I wanted to clarify that what I did was intentional and provide some context on why I did it.
- user profiles are only visible to logged in users via the Web interface.
- user attributes are only visible to authenticated users via the GraphQL API.
Screenshots or screen recordings
These are strongly recommended to assist reviewers and reduce the time to merge your change.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.