User can't reference unpublished content even when they have access to it

Closed 🐛 "Create referenced entities if they don't already exist" does not respect published/unpublished default Closed: duplicate as duplicate.

It seems like the SelectList widget is also not listing the unpublished nodes even if we have the permission.

Why don't we add new permissions to handle this use case?

• "Reference own unpublished [node_type] entity"
• "Reference own unpublished [vocabulary_name] term"
• "Reference any unpublished [node_type] entity"
• "Reference any unpublished [vocabulary_name] term"
• etc.

Giving the ability to a role to see an unpublish content doesn't mean you want this role to be able to reference unpublished entities.
You might allow an "administrator" role to have those permissions and disallow a "content contributor" from having them.
That would be a more granular (but also more complex) way to handle this.

@MacSim,
Sometimes we talk about how Drupal Core should handle 80% of common use cases. What you're describing sounds like an edge case, so contrib is probably the better place for something like that to live.

@dalin,

I am sorry but I can't totally agree ; Drupal is also about logic and granularity and a lack of logic/granularity oftenly leads to a new opened issue.
In #55 you said

We need to rally around one of the options, or propose a new one.

That's exactly what I am doing ;)

On this issue, the quick workaround is to give a powerful "Bypass content access control" permission to the roles we want in order to allow people referencing unpublished entities. Since it can have security implications, we're hereby talking about the best way to resolve this issue.

And as usual with an issue there's a quick and dirty way to resolve it and the hard but prettier way.

Using a "view" permission to handle a "reference" action doesn't make sense to me.

Since we already have those permissions model in drupal core to view / edit / delete own/any entities it sounds more logical to me to add a "reference" permission following the same model rather than cheating with another already existing permission.

Why would we only answer to 80% of common use cases when we can reach a 100% working a bit more?
Why would we leave the last 20% on the road especially when we noticed an issue and are working to resolve it?
Why would we need to develop and maintain a contrib module that people might not found if its name is not explicit enough to handle 20% of use cases that could have been fixed in core directly?

I am facing the same issue on core 9.5.10
May I know if there is any solution?

Rerolled against 11.x.

Thanks to everyone who has contributed towards fixing this bug! My attempt to summarize:

1. The existing behavior is definitely unexpected and undesired in many cases.
2. Some sites might depend on the current behavior.
3. Drupal Core needs to worry about BC in general, and doesn't even use new major releases for disruptive changes (except dropping deprecated code). Alas, #57 is not really an option.
4. Therefore, we probably need a setting to control this behavior, default to the expected thing for new installs, provide a post_update to set the legacy behavior for existing sites, etc. See #26, #28.
5. #43 still needs to be addressed. #43.2 is under debate. I tend to agree that the point of fixing this bug is changing that weird behavior and things that rely on it. We need clarity from the framework / release managers on how we want to scope this. Regardless, #43.1 and #43.3 are still necessary before we can remove "Needs tests" and therefore get this to RTBC.
6. #70 also needs to be addressed.
7. #73 also sounds like a bug in the current implementation that better test coverage would reveal.
8. Re #75 + #77: I'm reluctant to add Yet More Permissions(tm) to solve this. Seems more like a widget setting to me (e.g. a "[x] Include unpublished entities the user has access to view" checkbox or something).
9. We need to convert this to an MR against 11.x, maybe starting from #38 so that "fixing tests" doesn't necessarily mean removing all the coverage we had. 😅

Tagging to be smashed. I'll ping some folks in #bugsmash to try to get scope decision / approval before we go further.

Thanks again!
-Derek

@dww,

I'm reluctant to add Yet More Permissions(tm) to solve this. Seems more like a widgetselection plugin setting to me (e.g. a "[x] Include unpublished entities the user has access to view" checkbox or something).

If we absolutely can't just change the existing [unexpected and undesired] behavior, then I think a widget setting is a very good idea. Because it will allow to override the default behavior on an individual field level, not on a site level. Who know, maybe someone will need different behavior in different parts of the same site?

A setting is a great idea. It would need to be on the selection handler rather than the widget though.

Re: #82: Indeed, that's what I had previously edited comment #80 to say, should have called it out explicitly. This needs to be a selection handler setting, not a widget setting. Seems like this has direction to proceed again, if anyone's got time to run with it.

Thanks!
-Derek

I've noticed there's been a lot of discussion on this topic, and I'd like to contribute by sharing my findings:

1. I successfully replicated this issue on version 11.x as well.
2. Could we consider making the following change in the code:

-      $query->condition('status', NodeInterface::PUBLISHED);
+      if ($this->currentUser->hasPermission('view own unpublished content')) {
+        $or = $query->orConditionGroup()
+          ->condition('status', NodeInterface::PUBLISHED)
+          ->condition('uid', $this->currentUser->id());
+        $query->condition($or);
+      }
+      else {
+        $query->condition('status', NodeInterface::PUBLISHED);
+      }

It seems to yield the expected results, displaying unpublished content for which the user is the author, while the default remains Published only.

I would appreciate your thoughts and feedback on this.

Thank you.

Gently bumping this to major for all the above and for the following scenario, cannot save content with unpublished entity reference:

1. An editor creates content that references a term or other content.
2. An editor unpublishes that other content or term.
3. An editor edits the content and cannot save it while receiving a baffling error: "Leadership (value 3)" and over on that field, "This entity (node: 792) cannot be referenced."

No further explanation to add "because it is not published." No link to the content that needs to be published to be able to save the current piece of content.

Even though the editor may have the permissions to fix the error themselves and try re-saving, they are often (repeatedly, even for experienced, motivated editors) unable to.

That's the experience using the default autoselect widget.

With the Inline Entity Reference it will have something like "Error message: 1 error has been found: Partners" and then repeat in four places on that field "This entity (taxonomy_term: 1582) cannot be referenced." (at the top of the field, for the "Add existing" autocomplete, below the "Add" button, and for the "Create new" button— but not on the offending term, which does not have an ID next to it so it is even harder to identify the culprit.

Oh, and if the widget is a select list dropdown or checkboxes? The editor can save the content no problem— the unpublished reference is simply removed. Boom, data loss!

Two very different scenarios, one leading people to be stuck unable to save content they have edited, the other silently deleting a reference, based merely on the form display.

So yes, it is of major importance that people be able to reference unpublished content, especially that they have access to. I'd like to add messages warning people that they have referenced unpublished content from published content (and Drupal will not display it), but that can and likely should be done in contrib.

Last two patches, reroll of the main approach in #79 and the alternate approach in #84 do not cover taxonomy terms.

The patch is an update to the one in #79 against Drupal 10.2.3.

One test class was moved:
Old path: core/modules/system/tests/src/Functional/Entity/EntityReferenceSelection/EntityReferenceSelectionAccessTest.php
New path: core/modules/system/tests/src/Kernel/Entity/EntityReferenceSelection/EntityReferenceSelectionAccessTest.php

mohit_aghera → changed the visibility of the branch 2845144-user-cant-reference to hidden.

Note: This is the different approach compared to all the uploaded patches. So be cautions if you are replacing this with your existing patches. This is based on comms in #80and #82

I've refactored the implementation based on discussion from #80 #82 and #83

Updates on #43
- Fixed point 1 and point 3.
Removed new test for validating both the permissions and removed changes in edit callback.
Reverted un-necessary changes made to the test callbacks.
- Reverted point 1.

I've ignored changes done in-between #50 to #69 since all are removing existing test cases and changing things in node handler.

#70
I'm somewhat confused about content owned by user 0.
I've added the changes and test case changes in commit. I think we can refactor it depending on the feedback.

So this seems to be adding a new setting to the form, issue summary should contain a screenshot of the change being added.

Will eventually need a change record.

One of the remaining tasks is to get usability sign off on the labels so tagging for that.

Rerolled #67 for 10.2.5.

Rerolled #67 for 10.2.5.
Patch attached this time.

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-03-22 Fixed . The recording of the meeting can be found here: https://youtu.be/0ktdZlth-FA?si=ECoI-aaRngvQuEgB&t=773

For the record, the attendees at the usability meeting were @benjifisher, @rkoller, @simohell, @skaught, and @worldlinemine.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

At first apologies the overdue comment. There was a chain of unfortunate circumstances. In our testing by switching between the applied- and none-applied MR state while having two user accounts switching between two different browser windows got things mixed. That lead into a few misconceptions so that at the end of the meeting we had no clear consensus, several loose ends, and not agreed on who will comment on the issue. After noticing the missing comment, uncovering the misconceptions during renewed testing, it took a while to get that patchwork of information into a coherent and hopefully comprehensive order.

The first misconception, it looked like that the other form display widgets for autocomplete would already provide the option to display unpublished nodes. In consequence we were drawn between the following three options at the end of the meeting:

1. Take the patch as is, so it adds this new configuration option to the autocomplete widget
2. Unconditionally change the behavior of the autocomplete widget to make it consistent with other widgets and always give the behavior as if this new option was ticked all the time.
3. Don't do anything and leave it the way it is

The second misconception, in the context of scenario 1 and permissions, we were under the impression that the user would have the permission to view any unpublished content with any content type and that the label include unpublished entities the user has access to view isn't reflecting that fact. But while writing up this comment, those two misconceptions turned out false assumptions when i've retested the functionality. So after this brief outline of our stumbling blocks along the way a summary of out main takeaways. It has to be noted that the group agreed to revisit the topic at a later point since we haven't got to a clear consensus during the meeting but that was mainly due to our false assumptions.

So it is save to say that the group agreed that the functionality the MR provides is useful and it is a good thing to have the option to enable the feature on a per content type basis. There are two points to note we came across during the meeting that apply in any way:

In regards of permissions @skaught has taken another look after he got word about our misconception in that regard. I'll paste his comment from Slack in here:

📌 Add a container parameter that can remove the special behavior of UID#1 Fixed yes, userone has a service setting now (but, still exists) and is still defaultly engaged.
I think I was thinking around what if userone can add a node any -- even if that node has some custom Node Access Permission overriding it. But then another user edits that later, then this item (being altered thru something in drupal (:) would not fall into the combined logic of permissions the routine is checking for, but now this editor drops an item.

The main usability related points are in regards of situational awareness for the user. Those points could either be covered within this MR or moved into followup issue(s):

• At the moment you are unable to distinguish between published and unpublished nodes while scrolling the list of available results. Unpublished nodes should be labeled in the list of options in the autocomplete field in some way.
• In the example given in the steps to reproduce section the author might be unaware publishing a node that is linking a yet to be published still unpublished node. There are several more scenarios publishing or unpublishing a node with linked nodes. It should always be a deliberate informed decision for the persons editing, no matter if a node, or the nodes linked, are getting published or unpublished. Otherwise that might lead into a mess in regards of publishing states. One solution might be simply adding a confirmation step informing the user. In case of the example from the steps to reproduce section the user would have to confirm are you sure you want to publish this node since you are linking a node that is still unpublished. But the different potential scenarios would have to be explored and tested, but those are definitely out of the scope for this issue

I'll leave the needs usability review tag since we plan to revisit and discuss the issue at a later point.