Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define an adaptive card within the plugin manifest #6139

Open
thewahome opened this issue Feb 12, 2025 · 3 comments
Open

Define an adaptive card within the plugin manifest #6139

thewahome opened this issue Feb 12, 2025 · 3 comments
Labels
status:waiting-for-triage An issue that is yet to be reviewed or assigned type:feature New experience request

Comments

@thewahome
Copy link
Contributor

thewahome commented Feb 12, 2025

Is your feature request related to a problem? Please describe the problem.

The problem we're trying to solve is the user bringing existing adaptive cards, and wanting to use them in the plugin.

Describe the solution you'd like

Kiota currently must define the adaptive card within the plugin manifest. There are plans to work with TTK to support an external file reference from within the manifest.

Requirements:

  • TypeSpec will reference the external AC file.
  • Kiota must either:
  1. add the adaptive card JSON to plugin manifest
  2. reference in the external AC file

Kiota does not support passing AC file on CLI yet. Kiota must handle the path to the AC on the CLI and TypeSpec must pass it.

Additional context

More details have been mentioned in https://github.com/microsoft/typespec-copilot-skills/issues/140

@thewahome thewahome added status:waiting-for-triage An issue that is yet to be reviewed or assigned type:feature New experience request labels Feb 12, 2025
@github-project-automation github-project-automation bot moved this to Needs Triage 🔍 in Kiota Feb 12, 2025
@baywet
Copy link
Member

baywet commented Feb 12, 2025

@thewahome since there can be one adaptive card per operation, if we request that information from the user in the CLI, we'll need some mapping syntax like /api/path#GET:/pathtoadaptivecard. We'd require also additional UI in the VSCode extension. While this is not an impossible task, this would require significant additional investments for a "sub-part" experience.
We should probably consider only using an OpenAPI extension at the time which TS would emit based of an annotation and kiota would read.
Thoughts?

@thewahome
Copy link
Contributor Author

thewahome commented Feb 12, 2025

Would the conclusion made earlier still suffice?

  • The generated OAD will have the adaptive card in an x-ai extension after Typespec generation
  • Kiota should read the adaptive card OAD extension and write it the card in the static template property

@maisarissi
Copy link
Contributor

Kiota should read the adaptive card OAD extension and write it the card in the static template property

I talked to @darrelmiller about that and we discussed that MVL will handle the external file and inline the adaptive card. Kiota should only add the path provided in the OAS extensions as part of the plugin manifest like below:

{
    "functions": [
        {
            "name": "getActiveTasks",
            "description": "Get Active Tasks",
            "capabilities": {
                "response_semantics": {
                    "data_path": "$",
                    "properties": {
                        "title": "$.content",
                        "subtitle": "$.id"
                    },
                    "static_template": {
                        "file": "path_to_the_file"
                    }
                }
            }
        }
    ]
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:waiting-for-triage An issue that is yet to be reviewed or assigned type:feature New experience request
Projects
Status: Needs Triage 🔍
Development

No branches or pull requests

3 participants