Problem. GET /users/<user>/orgs/<resources>/ returns different sets depending on whether the request goes through the search index. With search parameters it lists the requester's orgs, not <user>'s. So when <user> is someone else, the same URL gives different results with and without ?q=.
| List |
Without search params |
With q, facets, sort or extras filters |
sources/, collections/ |
<user>'s orgs, filtered to what the requester can view (OrganizationResourceAbstractListView.get_queryset, core/orgs/views.py) |
the requester's orgs (is_members_view in BaseAPIView.__get_search_results, core/common/views.py) |
repos/ |
the requester's orgs (OrganizationRepoListView.get_queryset, core/repos/views.py) |
the requester's orgs |
url-registry/ |
<user>'s orgs (OrganizationURLRegistryListView.get_queryset) |
the requester's orgs |
On the search path, private resources show up only when <user> is the requester or the requester is staff. Visibility there comes from get_public_criteria(): public, or created by the requester. So another member of a shared org doesn't see that org's private resources.
Neither path returns anything the requester can't view. /users/<me>/orgs/... and /user/orgs/... aren't affected either, and oclweb3, oclweb2 and oclmap only request these lists for the logged-in user. Found while reviewing the lists changed in OpenConceptLab/oclapi2#906.
ACs
- Decide what
/users/<user>/orgs/<resources>/ means when <user> isn't the requester. Either it lists <user>'s orgs filtered to what the requester can view, or it only serves the requester's own orgs and refuses other users.
- Sources, collections, repos, URL registry and map projects follow that rule on both the database and search-index paths.
- Tests cover both paths, for the requester and for another user, including a private resource in an org they share.
Problem.
GET /users/<user>/orgs/<resources>/returns different sets depending on whether the request goes through the search index. With search parameters it lists the requester's orgs, not<user>'s. So when<user>is someone else, the same URL gives different results with and without?q=.q, facets, sort or extras filterssources/,collections/<user>'s orgs, filtered to what the requester can view (OrganizationResourceAbstractListView.get_queryset,core/orgs/views.py)is_members_viewinBaseAPIView.__get_search_results,core/common/views.py)repos/OrganizationRepoListView.get_queryset,core/repos/views.py)url-registry/<user>'s orgs (OrganizationURLRegistryListView.get_queryset)On the search path, private resources show up only when
<user>is the requester or the requester is staff. Visibility there comes fromget_public_criteria(): public, or created by the requester. So another member of a shared org doesn't see that org's private resources.Neither path returns anything the requester can't view.
/users/<me>/orgs/...and/user/orgs/...aren't affected either, and oclweb3, oclweb2 and oclmap only request these lists for the logged-in user. Found while reviewing the lists changed in OpenConceptLab/oclapi2#906.ACs
/users/<user>/orgs/<resources>/means when<user>isn't the requester. Either it lists<user>'s orgs filtered to what the requester can view, or it only serves the requester's own orgs and refuses other users.