Required fields in issue template don't work in organization repositories

[fmal]

Select Topic Area

Bug

Body

The same issue template used in a personal repository and in an enterprise org repo behaves differently.

Fields marked as required using

   validations:
      required: true

are correctly marked and validated as required in personal repositories (example https://github.com/michalandrzejczak/issue-templates-test/issues/new/choose), but the very same template moved to enterprise organization repo results in all fields being optional (no asterisks next to field labels and no validation)

Llooks as if validations were completely ignored in enterprise org repos.

[codebydant]

Same problem in my organization

[codebydant]

Related to #45084

[azenMatt]

Hi, this is by design and is documented here - https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms#about-yaml-syntax-for-issue-forms

Would you mind sharing what forms you were looking to create with required fields to help the team better understand the use case?

[Timmmy-nlb]

As I and many others have already written: we want this functionality!
https://github.com/orgs/community/discussions/51500

For the Apache Fondation it was finally also allowed!

[twisterdotcom]

@azenMatt - this is something I check consistently. I and many others have laid out reasons here: https://github.com/orgs/community/discussions/4264#discussioncomment-6071942.

I continually wonder why the decision to enforce the required fields wasn't carried over, yet it's still something we can add to a form is. Is there any possibility this will be coming soon at all?

does not complete the form due to laziness

These forms should help with exactly this —otherwise, they might as well be markdown templates. There's literally no point in them at the moment in our repos. It's just a completely wasted feature. I cannot describe how much benefit this would have to our internal support teams triaging bug reports written by first and second line.

[sgravrock]

I've been trying to work around the lack of a preview feature by testing my issue template changes in a private repo before inflicting them on real users. (Call me old fashioned but I don't think it's a good idea to put un-tested YAML changes into production.) It's really unfortunate that the exact same issue template does different things in different repos.

[dboune]

This severely degrades the utility of issue forms in an org. The ability to require a field would have significantly eased the work required to chase people around asking for more information.

While it is true that the same users creating an issue can edit the issue as markdown without the form, a carefully considered set of required fields and a restriction to prevent initial creation using plain markdown would make a daily difference.

[Timmmy-nlb]

The level of disinterest towards its (business) customers and the inaccessibility of rational arguments is quite impressive/pity.
That people are not given the freedom to decide for themselves how they act internally, just to enforce their own agenda/world view...

[mazlan]

@azenMatt - We also need required validations in our org for at least the Internal repositories. Especially as org admins, we can use GitHub issue templates to intake certain support requests and as people may miss out on filling required information this adds extra toil to reject such requests and going back to team members explaining what they missed, how to actually fill in the form etc. Not sure why this would be by design as it is already an optional attribute for public repos so why not make it the same for internal/private repos? Example of one such template:

[BenjaminEngeset]

Were you able to find a workaround @fmal? I have the same issue and it's also an issue with aplying automatic labels by using:

labels: ["Bug Report"]

This is also something that works great when it's not under an enterprise plan.

[Timonwa]

My labels work fine though, without any issues. Mores when the labels that have emoji in them.

[skylerjokiel]

I found that labels only work if the label already exists in the repo. If it doesn't exist it will not be added.

[mtfunder]

I found out today that not only does the label need to be in the repo that you are creating the issue in, it needs to be in the orgs .github repo as well... Took forever to figure that out. You also have to give anyone you want to add as a template assignee write access to the .github repo....

[jefferyjob]

1. There is no clear indication in the issue form document that private repositories cannot use form validation. I hope the document can be completed. At first, I thought it was a problem with my configuration and searched for it for a long time, 😁
2. We hope to have a private repository that can also support issue form validation

[rantoniuk]

@jefferyjob yes, there is, see the Note: at the last section of https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms#about-yaml-syntax-for-issue-forms.

@azenMatt point me to one person that thinks this would by design be useful only for public organisations. I cannot imagine you need an example of use cases for this, it's like saying we need to provide usecases for existence of Github Issues 😆 unless you want us to go back to Jira... 🚶🏻‍♂️

Selecting whether the issue is for DEV or PROD, requiring the reporter to enter the app version string against which the bug occurred, etc. etc.

[Timmmy-nlb]

Good News: "required" is now working in Internal Repos!
https://github.com/orgs/community/discussions/148713#discussioncomment-12226996