microsoft-graph-explorer-v4
microsoft-graph-explorer-v4 copied to clipboard
[User story] Copy API manifest path
As a user, when I click on the 'copy to clipboard' button I want the API manifest path to be copied So I can use it with the Kiota extension on VS Code
Acceptance criteria:
- I want to have a valid API manifest Path
What is an API manifest path?
@thewahome I'm noticing that what we are copying is an encoded value. Originally we encoded that to manage the URL and be able to open directly in VS Code. There's no need to encode anymore. Is there a use case for encoding?
I am not sure @RabebOthmani . @baywet must we encode it for the VS Code extension to pick up the manifest?
both would be supported I believe at this point. But To Rabeb's point, since we don't need to encode it anymore, having it copied to the clipboard not-encoded would be useful to people who want to copy it to do something else with it.
Test scenario
Path generated
{
"publisher": {
"name": "Microsoft Graph",
"contactEmail": "[email protected]"
},
"apiDependencies": {
"graph-v1.0-DelegatedWork": {
"apiDescriptionUrl": "https://raw.githubusercontent.com/microsoftgraph/msgraph-metadata/master/openapi/v1.0/openapi.yaml",
"apiDeploymentBaseUrl": "https://graph.microsoft.com",
"apiDescriptionVersion": "v1.0",
"auth": {
"clientIdentifier": "",
"access": [
{
"type": "openid",
"claims": {
"scp": {
"essential": true,
"values": [
"Chat.ReadBasic"
]
}
}
}
]
},
"requests": [
{
"method": "GET",
"uriTemplate": "/chats"
},
{
"method": "GET",
"uriTemplate": "/chats/$count"
}
]
},
"graph-beta-DelegatedWork": {
"apiDescriptionUrl": "https://raw.githubusercontent.com/microsoftgraph/msgraph-metadata/master/openapi/beta/openapi.yaml",
"apiDeploymentBaseUrl": "https://graph.microsoft.com",
"apiDescriptionVersion": "beta",
"auth": {
"clientIdentifier": "",
"access": [
{
"type": "openid",
"claims": {
"scp": {
"essential": true,
"values": []
}
}
}
]
},
"requests": [
{
"method": "GET",
"uriTemplate": "/admin"
}
]
}
}
}
If I change the scope
The generation
{
"publisher": {
"name": "Microsoft Graph",
"contactEmail": "[email protected]"
},
"apiDependencies": {
"graph-v1.0-DelegatedWork": {
"apiDescriptionUrl": "https://raw.githubusercontent.com/microsoftgraph/msgraph-metadata/master/openapi/v1.0/openapi.yaml",
"apiDeploymentBaseUrl": "https://graph.microsoft.com",
"apiDescriptionVersion": "v1.0",
"auth": {
"clientIdentifier": "",
"access": [
{
"type": "openid",
"claims": {
"scp": {
"essential": true,
"values": [
"Chat.ReadBasic"
]
}
}
}
]
},
"requests": [
{
"method": "GET",
"uriTemplate": "/chats"
},
{
"method": "GET",
"uriTemplate": "/chats/$count"
}
]
},
"graph-v1.0-Application": {
"apiDescriptionUrl": "https://raw.githubusercontent.com/microsoftgraph/msgraph-metadata/master/openapi/v1.0/openapi.yaml",
"apiDeploymentBaseUrl": "https://graph.microsoft.com",
"apiDescriptionVersion": "v1.0",
"auth": {
"clientIdentifier": "",
"access": [
{
"type": "openid",
"claims": {
"roles": {
"essential": true,
"values": []
}
}
}
]
},
"requests": []
}
}
}
@thewahome @darrelmiller the requests are empty once we change the scope to Application and we are not capturing the app permissions required. This isn't the expected behaviour, is it? Please notice that changing the scope also changed the version of the API in the generation without the user changing it (admin beta is generated as V1)
@RabebOthmani GET /beta/admin
isn't actually a valid Graph URL, so it will fail to return permissions. That might be why we are seeing invalid generation for the app only scenario. Try it with GET /users
@darrelmiller GET/users is working, FYI @thewahome which means the conversation should be around the paths so we avoid such cases
The faulty permissions are fixed now @RabebOthmani it's possible that @darrelmiller is looking at the updated values
@baywet Could you please have a look on the VSCode integration? To be discussed.
@thewahome is this in production or do you have a URI for a preview? @petrhollayms I believe the repro scenario has changed a couple of times throughout the discussion here now, do you have clear repro instructions?
It's still in staging. The repro steps are:
- add any two or more paths into a collection
- preview the collection
- in the preview page, click on the "create a manifest" button
- in the new manifest screen, a preview of the manifest containing the resources you selected is visible in a readonly editor
- on the top right of the preview, a copy button exists. Click it to copy the contents into your clipboard
- open visual studio code with the Kiota extension installed
- open the kiota options and click on paste a manifest
- notice that throws an error
Thanks for the details. Can you provide me with the staging link please? (either here or through teams) Any specifics about what you put in the collection (endpoints, authentication scenarios) to cause the error?
Just for clarity here: it's the "Paste API manifest" button that doesn't work properly (I can repro that). When you click on "Open in VS Code" in GE (which is what I was doing to date), it works properly. That's strange since it's supposed to be the same code for both commands. Investigating.
Update: I was able to isolate and fix the bug. However this is now going to consistently fail for both approaches because I also updated the api manifest dependency and the apiDeploymentBaseUrl generated by GE doesn't end with a trailing slash. Could you fix that last detail @thewahome please?
https://github.com/microsoft/kiota/pull/3877
(also application name now seems to be required by the spec)
@baywet, I've added the trailing slash in the apiDeploymentBaseUrl property
Thanks, do you have a staging URL for me to run integration tests? Or were you able to validate end to end with the latest preview of the vscode extension?