Open joncameron opened 6 days ago
@jwd suggested querying for the Teams a user is a member of instead of querying for sharepoint sites generally. Another approach he suggested would be stricter filtering via Regex. Would need to verify that the Microsoft Graph API search function handles Regex.
Documentation on Teams' API for @masaball's future reference: https://learn.microsoft.com/en-us/graph/api/resources/teams-api-overview?view=graph-rest-1.0
Depending on the options available and what is reasonable to implement, we can create a follow-up issue or two for implementation.
@masaball I think this regex will match on the site names that we want to include (sites that correspond to Teams created through the IU Institutional Storage management tool):
(O365-|[Sec]\s|[Sec-E]\s)[A-Z]{2}-[A-Z]{3,4}-.+
Examples:
O365-BL-LIBR-Team Name [Sec] BL-MUS-Team Name [Sec-E] IN-LIBR-Team Name
@joncameron @elynema
Turns out I misremembered and the search param does not support regex searching. We could still potentially implement regex filtering but it would need to be within browse-everything, or an initializer overriding browse-everything, and would filter the results returned from the API before rendering them. Something like:
sites = microsoft_api_call
sites_list = sites.select { |site| site.match?(/regex/) }
Alternatively, there is a /me/joinedTeams
endpoint in the microsoft graph API. For me this returns 3 options (Library Technologies, Digital Accessibility, and Eviada). Using the teams ID, we can query the /groups/{group_id}/drives
series of endpoints to get the child drives and files for each specific team.
I also managed to use some better search terms and found a /me/insights/used
API endpoint which returns documents viewed and modified by the user: https://learn.microsoft.com/en-us/graph/api/resources/iteminsights?view=graph-rest-1.0&preserve-view=true. With proper filtering, that likely could be used to return better results than we currently get. One caveat with this endpoint is that Insights are an Office365 feature that implementers can turn off for privacy/security reasons, so it may not universally work.
Adding the regex filtering to browse-everything would likely be the easiest/quickest approach to take. Maybe a low 2 in effort if everything goes well?
The other two approaches I think would be 2 points each, just more chance of delays from trying to get the endpoint calls just right.
@joncameron @masaball Personally, I think the best solution would be using the /me/joinedTeams
endpoint. Those look like the correct Teams that should be returned for you. I'm assuming you'll also pull in OneDrive.
Since the effort is not that different, I'd suggest we try that out this week. Jon, do you have other thoughts?
+1 to using the /me/joinedTeams
endpoint. That + OneDrive/personal drive seems like it would more closely match what's exposed in the OneDrive UI.
Sounds good. I will go ahead and create a new issue for doing that work. @elynema @joncameron Are we wanting to try to sneak this refinement into 8.0 or are we holding it until next release?
@masaball I'd like to try to sneak it into the 8.0 release if we can get it done this week.
Description
The Sharepoint integration with Browse Everything works very well, but is made difficult to navigate for users due to the large amount of folders that appear in the listing that would usually not in the web interface for OneDrive/Sharepoint.
In the Sharepoint UI Microsoft sorts by the folders / sites you have most recently interacted with to the top. If we can somehow do that in the query, that would be useful. Could the list exposed in Browse Everything match the list users see in the OneDrive interface?
Options
Done Looks Like