Provide mechanism for per-project default issue summary templates

This sounds like a good idea to me.

We have a section in the drupal.org documentation about issue summaries, which already contains a few special-purpose summaries:
https://www.drupal.org/community/contributor-guide/reference-information...

So, I would propose that we create a few more in there -- maybe one for Documentation issues would be good? Probably most projects are either primarily documentation or primarily code in what their issues are about -- or we can create another one if we can figure out another type of summary that would be useful.

Then in the edit-a-project page that lets you put in a default issue summary, we could (in the field description) link to that docs section for people to find examples.

+1 to all of that. Meanwhile, we can create some more templates, like "Including release notes" and "Documentation", if we have time/energy.

This looks pretty good! I went to the dev site and logged in as bacon. I went to node/add, and clicked on Community project. I don't see the new field. It's also missing if you click on Theme engine project.

For the other types of projects (core, module, theme, distro), it looks good. I don't see translation in node/add, so I didn't test that.

Setting to Needs Work because I think this needs to be added to theme engine and community projects
https://project-drupal.dev.devdrupal.org/node/add/project-theme-engine
https://project-drupal.dev.devdrupal.org/node/add/project-drupalorg

Note to self: I didn't yet test whether, if I made a project with and without a customization for the template, what issue summary would be used for new issues.

I tested this again: logged in as user "bacon" on the dev site, and created 5 test projects of the 5 types available to me. All of them had the new issue summary default value override field available, as well as the guidelines override field. So, I did a variety of overrides and no overrides in my 5 bogus sandbox projects. Here's a list of the projects:
https://project-drupal.dev.devdrupal.org/project/user/717216
The description fields say whether the field is overridden or not (I also tested overriding or not overriding the issue submission guidelines, just for fun, although that has not changed in this patch.)

On all the projects, after saving the project node, I got this error message:

    Warning: array_values() expects parameter 1 to be array, boolean given in _field_filter_items() (line 517 of /var/www/dev/project-drupal.dev.devdrupal.org/htdocs/modules/field/field.module).
    Warning: Invalid argument supplied for foreach() in list_field_validate() (line 393 of /var/www/dev/project-drupal.dev.devdrupal.org/htdocs/modules/field/modules/list/list.module).
    Warning: array_values() expects parameter 1 to be array, boolean given in _field_filter_items() (line 517 of /var/www/dev/project-drupal.dev.devdrupal.org/htdocs/modules/field/field.module).

This could be related to the fact that on the dev site anyway, the text formats for the Description, Submission guidelines, and new Custom issue summary template fields are all broken -- they don't offer me any text format choices. This is perhaps due to the default bogus user account "bacon" not having permission for any text formats? I'm not sure... But when I (still logged in as user bacon) created a Book page content item, I still didn't have text format choices for the Body, but it didn't give the same error when I saved the node. And when I created a Contributor Task content item, which has a formatted text field on it that is not the Body field, and a Contributor Skill, which has several, I didn't get an error... So... ??? not sure.

Anyway, I also tested creating issues, and the ones with overrides got a new issue summary, and the ones without got the default, so it seems to be working.

I did find another bug: The new issue summary override field is being shown at the bottom of project pages, if it has a value -- that needs to be removed from Manage Display. See
https://project-drupal.dev.devdrupal.org/sandbox/bacon/3160628
for an example.

Yes, the display looks good now. I had already tested the other functionality.

(I have a login for the dev server and could have done a drush uli to use a different user, but I didn't.)

I made an issue about the bacon user not having decent permissions for text formats (it is probably in the wrong project, but oh well). Probably one of the times when the d.o roles/permissions were rejiggered, no one fixed the bacon user to have a role that works.
#3161155: Warnings generated when creating sandbox projects

The weight changes like

@@ -6018,7 +6277,7 @@ function drupalorg_projects_field_default_field_instances() {
         'label' => 'above',
         'settings' => array(),
         'type' => 'hidden',
-        'weight' => 17,
+        'weight' => 21,
       ),
       'issuemetadata' => array(
         'label' => 'above',

all cause a field cache clear for each changed field instance, which stack up to minutes of effective downtime for Drupal.org. When rearranging fields, we have to click “show row weights” and do a minimal changes to get the fields in the right order.

One other nitpick:

<a href="https://www.drupal.org/node/3156940">

This leads off of staging/dev and you might not notice that you’re on production. Use site-relative links whenever possible, like <a href="/node/3156940">

Otherwise, this looks like a good direction to go in. I thought about using a file in the repository, but there isn’t anything close to standardized across services - https://docs.gitlab.com/ee/user/project/description_templates.html#creat... vs. https://docs.github.com/en/github/building-a-strong-community/configurin.... If we go that direction later, we’ll still want the field to avoid making another HTTP request while serving the form.

Is that patch up on the dev site? If so I can test it later today.

I tested on the dev server, and it all looks fine:
- The field appears on the project create form for all types of projects that user Bacon has access to
- Manage display is good (you don't see the issue summary template override)
- I tested with one of my existing projects, and if the override is there, the issue gets the overridden template, and if the override is not there, you get the default template.

This seems like a good idea.

So, I am +1 on adding this to drupal.org.

I also took a look at the patch... This bit is concerning:

+++ b/features/drupalorg_issues/drupalorg_issues.features.field_instance.inc
@@ -194,33 +194,32 @@ function drupalorg_issues_field_default_field_instances() {
 
   // Exported field_instance: 'node-project_issue-body'.
   $field_instances['node-project_issue-body'] = array(
+    'bueditor_profile' => -1,

Not sure what it means.

Also just below that in the same file, it looks like the default issue summary has changed... why?

Actually, most of the changes in that file seem weird and unrelated to this projects... Maybe revert that file?

There are also still some concerning weight changes in
+++ b/features/drupalorg_projects/drupalorg_projects.features.field_instance.inc

So... not sure about marking this RTBC?

Also... (maybe a separate issue) -- would it make sense to add a Description on the issue summary field, which would link to both
https://www.drupal.org/community/contributor-guide/reference-information...
(Issue summary field page, node/3156939) and
https://www.drupal.org/community/contributor-guide/reference-information...
(Special issue summary templates section, node/3156941)?

Maybe something like:

A (link)description of the issue summary field(/endlink) and (link)alternative issue summary templates(/link) can be found in the (link)Drupal project issues(/link) documentation.

(that last link would be the same is in the description that is below the Priority and Status fields)

Regarding (b), the change is showing many lines changed, not just the release notes snippet being removed?

Regarding (d), the big blue box is only present on new issues. Field descriptions are there also when you are editing issues. But yes, new issue is probably better.

Added child issue for (d) #3161574: Add links to issue summary info/templates under issue summary field

I saved the field on production for #3161574: Add links to issue summary info/templates under issue summary field, which flushed out some changes like

     'settings' => array(
-      'display_summary' => FALSE,
+      'display_summary' => 0,
       'text_processing' => 1,

Line endings are likely related to #3143101: Fix line endings to make PHPCompatibility happy, I’ve been keeping those as \n-only.

Those are only for the widget / form display config, so I don't think they incur the same awful cost of invalidating the field cache for display. They're necessary to get this new field to appear between the Submission guidelines field and the Enable issue tracker and Version options checkboxes at the bottom of the Issues field group.

Both field bases and instances have that cost. However, if we need to change weights to get fields in a logical order, we need to incur that cost. Depending on the situation, I might break something like that up into multiple deployments - re-weight fields to get them out of the way, then deploy the real change.

This is now deployed!

I had to script one additional bit to run via drush php-script:

foreach (project_project_node_types() as $project_type) {
  $groups = field_group_info_groups('node', $project_type, 'form', TRUE);
  $groups['group_project_issues']->children[] = 'field_issue_summary_template';
  ctools_export_crud_save('field_group', $groups['group_project_issues']);
}

Features isn’t able to export the group_project_issues field group, since it is defined by project_issue module. So this placed the new field in each project type’s group.

Would be great to announce it with change record

This should make the next “What’s new on Drupal.org” at https://www.drupal.org/drupalorg/blog. I went ahead and made a change record: https://www.drupal.org/node/3162437