Support Issue forms and PR forms

[wolfogre]

Implements #20232, an alternative to #20778. Thank @Wazzaps, I got a lot of inspiration.

Screenshots

Click to expand

Create a new issue

Create a new PR

And more.

Features

• Parsing most of Github's syntax for issue forms
• Both issue form and PR form
• Form-style templates show up in the template selector
• Template rendering
• Converts the form fields to Markdown at backend
• File uploading and pasting uploading
• Additional (gitea) features, support regex and is_number validations for input.
• Display template validation errors

Fix

• Use the full path of the template file in URL parameter
  • xx/issues/new?template=test.yaml -> xx/issues/new?template=.gitea%2fISSUE_TEMPLATE%2ftest.yaml
  • Avoid searching in all possible folders
  • Works on both markdown and yaml template
• Compatible with treating description(Github's syntax) as about (Gitea's syntax)
  • I mean the description in metadata not the description in attributes.
  • Works on both markdown and yaml template.
• Add missing support for warning message in templates/base/alert

Useful features but maybe not this time

• Template linting when editing online
  • Maybe another new PR to implement it.
• A way to extract the form fields reliably / programmatically (maybe a webhook during submit?)
  • Maybe another new PR to implement it.
• Form localization
  • Not sure if needed, additional template syntax is required.
• Don't include empty fields? (deviates from GH behaviour)
  • Maybe another new PR to implement it, it could be an option in the config.yml.
• Configuration file config.yml
  • It is the additional configuration for templates, form templates work fine without it, maybe another new pr.
  • For forward compatibility, config.yaml and config.yml will be ignored as a template.
• Preview in a markdown editor
  • The preview button is designed outside the editor now, maybe another new PR to redesign it.

Known issues

• There's an error when creating PR with form template:
  • JavaScript error: Uncaught TypeError: Cannot read properties of null (reading 'codemirror') (http://localhost:3000/assets/js/index.js?v=c513827fa @ 45398:15). Open browser console to see more details.
  • Actually, the form still works fine.
• Form required validation will be ignored by:
  • markdown editor: see Support minlength & required HTML validations Ionaru/easy-markdown-editor#105
  • dropdown: the fomantic-ui doesn't support minSelections for a dropdown, only maxSelections
• Form regex validation doesn't work for input yet

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (main@b7a4b45). Click here to learn what that means.
The diff coverage is 63.09%.

@@           Coverage Diff           @@
##             main   #20987   +/-   ##
=======================================
  Coverage        ?   47.14%           
=======================================
  Files           ?     1007           
  Lines           ?   137294           
  Branches        ?        0           
=======================================
  Hits            ?    64728           
  Misses          ?    64645           
  Partials        ?     7921           

Impacted Files	Coverage Δ
modules/structs/issue.go	0.00% <0.00%> (ø)
routers/web/repo/issue.go	36.40% <15.00%> (ø)
modules/issue/template/unmarshal.go	26.31% <26.31%> (ø)
routers/web/repo/pull.go	30.86% <33.33%> (ø)
routers/web/repo/compare.go	46.38% <40.00%> (ø)
modules/context/repo.go	53.60% <42.10%> (ø)
modules/issue/template/template.go	90.97% <90.97%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[JakobDev]

* Configuration file `config.yml`
  
  * It is the additional configuration for templates, form templates work fine without it, maybe another new pr.
  * For forward compatibility, `config.yaml` and `config.yml` will be ignored as a template.

See #20956

[Wazzaps]

So far the code looks much better than what I wrote, very nice :)

I remember multiple easymde editors in one page causing problems without my JS change, does it work for you?

Also, I started work on placing some fields in YAML front matter instead for easier machine parsing (had no time to commit it yet), Is it in scope or would you like me to open a new PR for that once this is merged?

[wolfogre]

* Configuration file `config.yml`
  
  * It is the additional configuration for templates, form templates work fine without it, maybe another new pr.
  * For forward compatibility, `config.yaml` and `config.yml` will be ignored as a template.

See #20956

@JakobDev Thanks for reminding me, I will wait for it to finish. 😁

[wolfogre]

So far the code looks much better than what I wrote, very nice :)

I remember multiple easymde editors in one page causing problems without my JS change, does it work for you?

Also, I started work on placing some fields in YAML front matter instead for easier machine parsing (had no time to commit it yet), Is it in scope or would you like me to open a new PR for that once this is merged?

@Wazzaps Sorry bro, for "stealing" your idea 😂. I just want to speed up the implemention of this featrue.

I may have overlooked the problems caused by multiple easymde editors, I will check it.

Actually, I have no idea about placing some fields in YAML front matter, so I haven't included it in this PR, I'm glad to see you open a new PR for it.

Thanks again.

[JakobDev]

It would be nice, if you could add a codebox type. e.g.

  - type: codebox
    id: bug-ocde
    description: Paste the code that causes the Bug here
    attributes:
      language: go

That would be like a normal Textbox, but without Markdown and with Syntax Highlighting in the given Language. As someone who created a few Libs this would be very useful, if Users could provide some example code that causes a Bug with syntax highlighting with a issue form.

I know, that GitHub doesn't supports that (from what I could find), so this would be a benefit over GitHub.

[delvh]

But what's the difference to

```go
<code>
```

?

[JakobDev]

you mean a normal textarea with that the markdown code for syntax highlighting as default? Users tend to clear the Box before posting the code. I have seen it multiple times. This would ensure, the syntax highlighter is always set. Moreover, it would allow to syntax highlight the code directly in the form. is that not to hard to implement.

[Wazzaps]

It would be nice, if you could add a codebox type. e.g.

  - type: codebox
    id: bug-ocde
    description: Paste the code that causes the Bug here
    attributes:
      language: go

That would be like a normal Textbox, but without Markdown and with Syntax Highlighting in the given Language. As someone who created a few Libs this would be very useful, if Users could provide some example code that causes a Bug with syntax highlighting with a issue form.

I know, that GitHub doesn't supports that (from what I could find), so this would be a benefit over GitHub.

That's what a textarea with the render attribute is for, just need to implement a code editor instead of a plain textarea

[Wazzaps]

@wolfogre no problem, I just want this implemented, I don't care who does it :)

I'll open the additional features I need as new PRs once this one is merged.

[JakobDev]

That's what a textarea with the render attribute is for, just need to implement a code editor instead of a plain textarea

I completely missed that part of the documentation. Sorry for that. 🤦

[wolfogre]

There may still be some little problems, but I believe it works and is ready to be merged now.

There are some more Screenshots:

Markdown

Textarea

Textarea without render

Input

Input with is_nummber

Input with regex

Dropdown

Dropdown with multiple

Checkboxes

[kdumontnu]

Tested locally and works very well!

Thank you for adding the test cases for errors and documentation. A couple suggestions:

• Can we display the yaml parsing errors to the user? It fails silently right now, which makes it difficult to understand what's going wrong. Perhaps templates/base/alert would be appropriate.
• You have great test cases for error states, but I don't see a test for valid yaml input. It would be great to validate that we properly generate an html template from yaml input in an integration test (to ensure we don't break this in the future).

I can check back in later. If you think these ideas are unreasonable I'm okay approving as is.

[wolfogre]

Tested locally and works very well!

Thank you for adding the test cases for errors and documentation. A couple suggestions:

• Can we display the yaml parsing errors to the user? It fails silently right now, which makes it difficult to understand what's going wrong. Perhaps templates/base/alert would be appropriate.
• You have great test cases for error states, but I don't see a test for valid yaml input. It would be great to validate that we properly generate an html template from yaml input in an integration test (to ensure we don't break this in the future).

I can check back in later. If you think these ideas are unreasonable I'm okay approving as is.

@kdumontnu

I agree, templates/base/alert is a great idea, so I added a warning alert to show invalid templates.

Also, a new test case to validate a valid yaml has been added, please review again.

There're some screenshots of warning alerts:

For creating issue:

For creating PR:

I18n

[kdumontnu]

💯 Excellent PR

This is also probably a good candidate to test with my front-end testing framework once that's merged #20123.

[wxiaoguang]

It seems quite fragile

[wolfogre]

I add a new class .not-under-easymde with the style margin-top: 0, it works, but I‘m not sure if I did it in the right way.

[wxiaoguang]

About the "field and easymde margin", see 233337d

About the JS and EasyMDE: the code was quite complex (and hacky) before, although this time it becomes more complex, no blocker from my side since it works (refactoring is out of this PR's scope).

I have no more questions.