You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 24, 2018. It is now read-only.
While working on #701, I realized that context = edit can be passed to any GET /wp/users request to get full user details. Which, in hindsight, makes sense, because if a user has the list_users cap, they conceivably can get all of those details out of the Manage Users table.
However, we'll shortly need to remove the current list_users cap check at the beginning of each method because a basic amount of user data will need to be exposed if the user has at least one published post (#695).
The master branch has json_check_post_permission(), which no one is really a fan of.
In short, the relationship between contexts and capabilities is a bit muddy right now. We should make it much clearer.
While working on #701, I realized that
context = editcan be passed to anyGET /wp/usersrequest to get full user details. Which, in hindsight, makes sense, because if a user has thelist_userscap, they conceivably can get all of those details out of the Manage Users table.However, we'll shortly need to remove the current
list_userscap check at the beginning of each method because a basic amount of user data will need to be exposed if the user has at least one published post (#695).The
masterbranch hasjson_check_post_permission(), which no one is really a fan of.In short, the relationship between contexts and capabilities is a bit muddy right now. We should make it much clearer.
Maybe we should reintroduce
check_context_permission()for controllers? https://github.com/WP-API/WP-API/pull/421/files#diff-08b662d17a90b99fbd5dc8592dafd6c9R124Related #605