Esri / arcgis-rest-js

compact, modular JavaScript wrappers for the ArcGIS REST API
https://developers.arcgis.com/arcgis-rest-js/
Apache License 2.0
347 stars 120 forks source link

Hub needs ability to search for users outside the currently authenticated user's organization #1119

Closed rweber-esri closed 1 year ago

rweber-esri commented 1 year ago

Describe the problem

The Hub Discussions feature has the concept of "channels", which is an access control mechanism governing what user's can participate in discussions. Channels currently have an access property that can be one of public|org|private, and a groups property which is an array of ArcGIS Online group IDs that can additionally grant participation privileges to users (groups can be outside the currently auth'd user's organization). User's permitted to participate in a discussion can at-mention other users that are also permitted to participate in a discussion (given the target user's profile visibility is set such that other users, internal, or external to their org can view their record). Given the above, Hub needs the ability to search for users that may be outside the currently authenticated user's organization.

Today, both V3 & V4 of arcgis-rest-js only support searching for users from the /portals/self/users/search AGO API endpoint, but it seems that endpoint only searches within the currently authenticated user's organization.

V3:

V4:

The /community/users endpoint seems to be able to access user records outside the currently authenticated user's organization.

Describe the proposed solution

I believe we should either:

  1. Add an entirely new search method, e.g. searchCommunityUsers, that would pass a new searchType of communityUser (or similar) to genericSearch to route the request to the /community/users endpoint.
// existing method
export function searchUsers(
  search: IUserSearchOptions | SearchQueryBuilder
): Promise<ISearchResult<IUser>> {
  return genericSearch<IUser>(search, "user");
}

// new method added
export function searchCommunityUsers(
  search: IUserSearchOptions | SearchQueryBuilder
): Promise<ISearchResult<IUser>> {
  return genericSearch<IUser>(search,"communityUser");
}

OR

  1. Refactor the existing searchUsers method to accept an additional argument, with which clients can provide context into what API endpoint should be called.
// option 2

export function searchUsers(
  search: IUserSearchOptions | SearchQueryBuilder,
  searchType: "user" | "communityUser" = "user"
): Promise<ISearchResult<IUser>> {
  return genericSearch<IUser>(search, searchType);
}

// OR

export function searchUsers(
  search: IUserSearchOptions | SearchQueryBuilder,
  options?: { searchType: 'user' | 'communityUser' },
): Promise<ISearchResult<IUser>> {
  return genericSearch<IUser>(search, options?.searchType ?? 'user');
}

Alternatives considered

See Describe the proposed solution section for both options considered.

Additional Information

Although seemingly not a large effort, I wanted to open this issue to solicit feedback from other frequent contributors to this project before submitting a PR. @dbouwman @gavinr @patrickarlt I'm curious your thoughts? Feel free to loop other contributors into this conversation.

rweber-esri commented 1 year ago

I chatted with @dbouwman earlier today per Hub's needs and my proposed approaches. We were in agreement that option 1 above felt more appropriate. I've submitted a pair of PRs to add a searchCommunityUsers method to V3 & V4

rweber-esri commented 1 year ago

V3 PR-1120 released as v3.7.0 V4 PR-1121 released as v4.4.0