Closed
Description
We need to enhance the plugin generation process in Kiota by implementing validation rules. These validations will ensure that the generated plugins function correctly.
Some of these validations address current limitations that may be resolved in the future. However, it is crucial to ensure that the generated plugins work with the current constraints.
### Tasks
- [ ] https://github.com/microsoft/Microsoft.Plugins.Manifest/issues/255
- [ ] https://github.com/microsoft/kiota/issues/5164
- [ ] https://github.com/microsoft/kiota/issues/5381
- [ ] https://github.com/microsoft/Microsoft.Plugins.Manifest/issues/259
- [ ] https://github.com/microsoft/Microsoft.Plugins.Manifest/issues/256
- [ ] https://github.com/microsoft/Microsoft.Plugins.Manifest/issues/257
- [ ] https://github.com/microsoft/kiota/issues/5380
- [ ] https://github.com/microsoft/Microsoft.Plugins.Manifest/issues/258
Requirements
- Requirement 1: Validate all the above rules before generating a plugin and only generate the plugin if there are no issues.
- Requirement 2: Warn the user if their OpenAPI is not valid for plugin creation and don't generate the plugin
- Requirement 3: Inform the user which selected endpoints are failing validation and the specific reason. For example, one has 10 endpoints selected to create a plugin and just 1 fails due to nested objects in the PUT method; notify of the specific endpoints and the reason for the failure.
Metadata
Metadata
Assignees
Type
Projects
Status
Done ✔️
Relationships
Development
Participants
Activity
maisarissi commentedon Aug 14, 2024
Tasks:
Only authorization code are supported as OAuth grant flowsAPI Key in custom headers, query params or cookies are not supportedDual authentication flows (API Key AND OAuth token) for single API endpoint are not supportedCan be resolved with #5071
baywet commentedon Aug 14, 2024
I do have a bunch of questions about those rules...
What qualifies as nested object? an inline object type definition? or are you referring to properties that are of object types in general? (e.g. assigned licenses for user in Graph)
This is how we define inheritance (entity<-directory object<- user), which would in effect rule out most API definitions out there. We need to be much more specific here.
Likewise we have plenty of those in Microsoft Graph. E.g. a User has a manager property which is a user... Also should we consider multiple degrees of separation? (e.g. user.memberof ->group, group.members -> user)
Providing examples would help here.
Examples please.
Examples please.
Considering 3.1.0 is not supported yet by OAI.net we should revisit this one for our current timelines.
Or in simple terms "should start with https://, case insensitive"
petrhollayms commentedon Aug 16, 2024
@maisarissi Shall we move it from Proposed to Todo? (meaning, is it a must-have for GA?)
maisarissi commentedon Aug 23, 2024
@baywet I've added the examples and details around the validations in each of the new issues created.
After talking to @darrelmiller, I've created validation issues in the validation library. On top of the validations in the validation lib, linked to this epic, In Kiota we should still validate:
If any above validation fails, we need throw an error.
For inheritance (allOf, oneOf, anyOf) in request bodies, I've created a new issue for Kiota to handle the scenario: #5164
For the circular reference we should list all selected paths that are causing the error.
I'm good with moving to Todo @petrhollayms
29 remaining items