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.

[dtcMLOps]

Same problem in my organization

[dtcMLOps]

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?

[thoutbeckers]

@azenMatt can you perhaps share the underlying design decision why GitHub made this division between public and private? As in, what use case did GitHub foresee in public issues that do not exist in private ones?

Perhaps this will teach us something, e.g. maybe GitHub sees a better alternative specifically for private repos?

[datfinesoul]

@azenMatt , I agree with @thoutbeckers' comment. Understanding why GitHub thought the need for required fields only exists for public repos is not really clearly explained in the documentation. I understand that it's a current limitation, but it does reduce the usefulness of these forms for internal workflows. Empty form submissions are just to easily done, and ultimately just generate issue spam.

[JSMike]

@azenMatt What can be done to enable this for enterprise? I'm not sure why this wouldn't be a setting for organizations to choose, especially as organizations are paying to use the platform. This would be a very impactful feature for my org.

Has anyone come up with an action to enforce, until we can enable this for enterprise?

Our use case is internal library support.

[sky-lackner]

@azenMatt adding my request to enable this feature for private repos. This would be extremely useful to make sure devs have the necessary info to actually act on and respond to a created issue.

[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!

[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.