-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Complete draftIssue and add slash commands to default config #1087
Complete draftIssue and add slash commands to default config #1087
Conversation
It looks like this actually overlaps in a way with this PR I submitted to resolve the fact that referencing params wasn't working for any existing slash commands: #1084 |
@justinmilner1 Part of the goal with generating a link was to give users a chance to modify the issue before it originally gets published. When you create via API, I think it just immediately creates the issue, is this how that works? I think it would be nice to have a verification flow where users don't need to fear that the model outputs something scary without a chance to review. Can you think of any kind of in between solution? I don't know if there's an API for generating drafts, or if perhaps we just need to generate a more obvious link (possibly an h1 with a link rather than the small text at the bottom, or just better messaging, like "please click here to create the issue") |
@pzaback Good catch! Just tested and pushed up your fix to avoid using 'this'. @sestinj I definitely agree. Feels very wrong to publish the issue without manual editing or confirmation, even if the issue is heavily labeled a draft. ...Unfortunately, github doesn't have a draft option for issues currently. I think two changes should be made:
These are fairly heavy changes but I think they're necessary for this feature to really be valuable. Any thoughts? |
@justinmilner1 it's not a direct API that they have, but you can create a URL that opens up a draft of an issue when clicked. This is what I was going for with the link at the bottom of the slash command ( continue/core/commands/slash/draftIssue.ts Lines 51 to 53 in 98521a2
As an example: https://github.com/continuedev/continue/issues/new?title=Testing&body=HelloWorld I think you're right though that it would be nice to have more prominent button. I wonder if there's a method of creating buttons in markdown. If this was possible it would be useful in many other slash commands as well. In |
@sestinj Ah I think I understand where my confusion is coming from: When I click on the link you provided, I am not taken to a draft page - instead I'm directed to the template page. When I use the issue feature on the preview branch, it takes me to 404. I added issue templates to my repository, and still am able to reach the draft page - so I think the ability to draft the issue is indeed about repository ownership. Note: The api is able to create issues both on repos I own and don't own. So what to do?: Is it worth it?: |
@justinmilner1 Oooh this explains everything, I hadn't realized that at all. A bit unfortunate, but nevertheless I think the larger point about user confirmation/input is important. I would say this is interesting enough that we should go ahead and try it. Probably the first attempt won't be the exact thing that lasts forever, but would love to experiment. The first problem to solve is probably just how to best display a button from the markdown view, and once that is accomplished, rather than making some large refactor so that slash commands can emit buttons in a general way, it might be good to just do something that allows for this to be tested more immediately |
@sestinj Got it. I'll experiment with how the button could be displayed. |
@sestinj Looks like it's very easy to render a button in markdown - but it's not straightforward how the button's functionality would be initialized, or how slash commands would listen for button activity, or how we would track issue generations to button activity. My takeaway is that it's something which could be done - and that's good to know! ...but I think it's better to wait until we have more (quantity and importance) use cases for a change this large - what do you think? |
@justinmilner1 I agree with the conclusion. Let's close this PR then, but link it for future reference. I've created an issue (#1264) that I believe describes where this work will go next, but please add any context I might have left out! |
Description
Resolves:
Related bug: #1035
I added:
Evidence:
On gitlab: