Autocreate for Entity Reference selection handlers that extend ViewsSelection

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.

CI failures in the last few patches.

Such a feature will need a change record.

Curious though if we are auto creating any kind of entity reference. What happens if it's a reference to, say articles, how is it auto creating articles?

Re #87: Fixed CI failures & added CR.

Curious though if we are auto creating any kind of entity reference. What happens if it's a reference to, say articles, how is it auto creating articles?

It will create an article with the title passed in input box.

Update IS also.

Cleaning up credits for bad rerolls

CR looks good.

Tested this out on a Umami Install, since that's what I had running
Created an Entity Ref view that searches for Tags title and filters by just Tags taxonomy vocabulary
updated Article content type to use new handler.
Created an Article and added "This is a test" to the tags field
It was created BUT it was added to the wrong vocabulary. Was added to Recipe category not tags

Hi @smustgrave, Thanks for the review.

Created an Article and added "This is a test" to the tags field
It was created BUT it was added to the wrong vocabulary. Was added to Recipe category not tags

This might be because Store new items in might be selected as Recipe on the created field. If this is not the case, can you please provide a screen recording so that I can reproduce the steps?

Retested on a fresh install and seems to be adding to the correct vocabulary now.

I'm triaging RTBC issues → .

I read the issue summary and then the comments. I then read the change record and scanned the patch. I have found some more things to do here which I will list below.

But first, thanks for working on this, it does look like a handy feature!

1. This is adding to the UI, therefor adding 'usability' tag
2. The proposed resolution has not been updated since this issue was created and there was a change to the approach in #54/#55. That should be checked.
3. The points raised in #60 have not been addressed.
4. #61 points out a change of behavior. I checked the change record and it is not discussed there. The change of behavior should be added there, perhaps in before/after sections. How disruptive is this change?
5. Sadly, I don't see that there has been a code review since #60. There were a lot of rerolls after that but quite a few do not have interdiffs
6. The term 'autocreation' is used throughout the MR but it is not an English word so should be changed. It is not identified because it appears in the core list of misspelled words in core. And there is an issue to correct all the spellings and remove that list.
7. I think the change record needs a more informative title and that the CR itself can be made easier to understand. It should explicitly how/where to use this new feature. That is, that it when adding a reference field to an entity. The screenshot is helpful but I wasn't sure what is new about it. It is just the addition of the new option? Does selecting the option then offer more fields? I also am not sure what 'new referenced entities with title will be created" means. There is some help for this, Write a change record for a Drupal core issue → .

I made a few tweaks to the MR but it still needs work.

I changed the MR to avoid spelling errors and sorted use statements in one file.

There is one test file changed here, \Drupal\Tests\field\Functional\EntityReference\Views\SelectionTest. It adds the test module, 'views_entity_test'. However, if the line is removed the test still passes.

And related to that, what is the purpose of the duplicate plugin in, \Drupal\views_entity_test\Plugin\EntityReferenceSelection\TestViewsWithAutoCreateSelection?

This all make me think the question raised in #58.5 about testing, and answered in #59.5, needs to be looked into again. And a fail test will be needed here as well. If I knew more about views testing I would offer a suggestion.

Adding tags I should have done earlier.

tobiasb → changed the visibility of the branch 2800875-autocreate-entity to hidden.

tobiasb → changed the visibility of the branch 2800875-autocreate-for-entity-D8 to hidden.

tobiasb → changed the visibility of the branch 11.x to hidden.

tobiasb → changed the visibility of the branch 2800875-autocreate-for-entity to hidden.

I added a new constraint AutoCreateEntityBundleExists; but I have no idea how to test it on the drupal way. I know there are other constraints, but their looks easier.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Re-rolled the patch from #86 for 10.3.x - this is just a crutch for now, ultimately the merge request is the better option.

I'm just going to try that again, this time with the missing new files.

Thank you @lisagodare !

Applied the patch #109 with core 10.3.1 and it solves this creation issue i had with a custom bundle, + entity reference & views selection.

Patch was working with Drupal 10.3.*, but doesn't work with Drupal 10.4

Hi @vija ! Here is an update of the patch for Drupal 10.4.

@urashima82 thanks, man!

#112 is indeed working perfectly with Drupal 10.4.x :)

Patch #112 applied cleanly to Drupal 10.5 too but it doesn't work for creating Users.

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null: INSERT INTO "users_field_data" ("uid", "langcode", "preferred_langcode", "preferred_admin_langcode", "name", "pass", "mail", "timezone", "status", "created", "changed", "access", "login", "init", "default_langcode") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14); Array ( [:db_insert_placeholder_0] => 7 [:db_insert_placeholder_1] => it [:db_insert_placeholder_2] => it [:db_insert_placeholder_3] => [:db_insert_placeholder_4] => [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => [:db_insert_placeholder_7] => Europe/Rome [:db_insert_placeholder_8] => 0 [:db_insert_placeholder_9] => 1751017446 [:db_insert_placeholder_10] => 1751017446 [:db_insert_placeholder_11] => 0 [:db_insert_placeholder_12] => 0 [:db_insert_placeholder_13] => [:db_insert_placeholder_14] => 1 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 817 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).