I have a solid use-case where editors need to be able to add references to unpublished content. They will schedule both the referencing items and the referenced item for publication, and these must not be publicly discoverable until the scheduled time.

Entityreference adds a generic "node_access" tag to the query, but the resulting access check does not appear to respect the "view own unpublished content" permission. I guess the query running over ajax results in the user being anonymous at the server?

It doesn't seem possible to remove the node_access tag via hook_query_alter().

I can hack the node_access tag out as a temporary solution, but that's a potential problem waiting to bite me. Does anyone have any suggestions for a cleaner way to implement this?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

FiNeX’s picture

Status: Active » Closed (duplicate)
j0rd’s picture

Status: Closed (duplicate) » Active

Re-opening this, as author does a good job of explaining a typical use case, and it's not really a duplicate, since the solution in the other thread says to change the view or enable "bypass node access".

For me, I'm not using views, so that's not a solution. And 'bypass node access' has a lot of un-intended consequences as it's used in other contrib modules that permission for important things.

Here's a very simple use case on an end user site.

User A creates Node Z, and references Node Y (which is published).

User B (author of Node Y) unpublishes Node Y.

User A attempts edits and attempts to save Node Z, and is unable to, due to this restriction. Additionally, User A is extremely confused by the error message "The referenced entity (node: 47690) is invalid.", as User A has no idea what a reference, entity or node are.

With out fixing the problem , as more descriptive error message helping users to resolve their own problems might mostly avoid this.

Something like: "[node:type] [node:title] is no longer available. Please remove it before saving your content."

Ideally we'd have the option in the field settings to avoid this check all together:
[x] Allow unpublished nodes to show up in auto complete
[x] Allow unpublished nodes to be saved
[x] Remove unpublished nodes from parent, upon editing parent (i've done this for deleted nodes on my site already to resolve another problem)
[x] Allow own unpublished nodes to be show and saved in auto complete.

j0rd’s picture

Here's a sample hack^H^H^H^H patch which provides an example of how this could get done. The field settings are fully available in query's metadata, so the field settings could easily get extended to allow for more fine grained control.

duckydan’s picture

The patch in #3 worked perfectly for me. I was not able to find another way that was compatible with entityreference_prepopulate.

Ayrmax’s picture

I made a module some time ago. It adds a new selection handler to the entityreference field. This handler enables an author with the "Reference unpublished node" permission to reference to unpublished nodes without the need of the "administer content" permission or node access module.
https://drupal.org/sandbox/Ayrmax/1977458
I used it in multiple projects without any issues.

CMStom’s picture

Issue summary: View changes

I also have run into this issue where I can't reference unpublished content. I went ahead and enabled "Bypass content access control". I'll give Ayrmax's module a try.

hadsie’s picture

Thanks @Amyrax. Your reference module works for me and the code is pretty straight forward. Is there any reason that this shouldn't be incorporated into the Entity reference module? Perhaps it's too specific to nodes?

bsandor’s picture

This is a serious issue here.

Why would a module limit me referencing unpublished modules???

My use case is that users can prepare nodes before publishing it and referencing those nodes from other attached nodes while nothing is published until original node becomes published.

I am stucked. I am thinking of going back to normal select box instead of using this module as of this male function / bug here.

This needs to be fixed for sure.

SOLUTION:
I am thinking of:

  1. a checkbox on all widget instances saying st like 'Enable Referencing Unpublished nodes' OR
  2. at least a hook where I can change what is included, what is not

Changing this issue to 'Mayor'.

bsandor’s picture

Category: Support request » Bug report
Priority: Normal » Critical
bsandor’s picture

Priority: Critical » Major
bsandor’s picture

I have modified @J0rd 's patch just to have a more elegant way. No mayor differences.

This patch works great for me.

dafeder’s picture

Actually #3 is the properly formatted patch :)

dafeder’s picture

I take it back, neither is quite right. Here is a proper patch using @basndor's code.

psychobyte’s picture

any plans for the solution proposed in #8 to get into core module?

Poindexterous’s picture

This is a problem for me also. We (the team I work with) will be testing out this patch shortly. Our use-case involves a content moderation configuration where "content entry" staff roles may only create content as a draft (unpublished node status), which eventually get passed on to an editorial department for approval (published node status). Entity reference fields are common in our content types (we have things like speakers, teachers and location content types that need to be referenced by other node types like events, classes, etc). It would cause havoc for us to give content entry personnel the "bypass all" permission, we reserve that for editorial and admins for good reason. We need to limit permissions in a strict manner to make sure unauthorized content doesn't go live. Entity reference and content moderation modules (where users create unpublished "drafts") are so frequently used in tandem I suspect this may be a more common problem than reflected here.

joel_osc’s picture

Patch worked great for me too, would be good to get this functionality in. Cheers.

tyler.frankenstein’s picture

#13 had no effect for me with either Simple selection or Views selection mode. Using xdebug I can only see this patch being ran when Views selection mode is enabled, but not when Simple selection is enabled. However, after removing this patch I'm still able to use Views selection mode and configure the View's filters to show unpublished nodes. So for me, this patch has no effect, I like the direction it is going though...

tyler.frankenstein’s picture

To follow up, Views selection mode (with a filter allowing unpublished nodes) is a way around this when using the node edit form. But when programmatically updating a node, it still doesn't retain references to unpublished nodes.

Applying the patch in #13 does allow me to programmatically update a node that references an unpublished node, but the issue still stands that when using the node edit form, the patch doesn't allow me to reference unpublished nodes.

tyler.frankenstein’s picture

Status: Active » Needs work
Charles Belov’s picture

So far, the assumption seems to be that this behavior always happen. That's not necessarily the case. I can think of instances where some staff would need it and other staff might find it confusing. As of the latest patch, it appears that everyone gets this behavior whether it's appropriate for them or not.

I strongly suggest, at the very least, that unpublished entities showing up in the autofill need some sort of distinction to explicitly indicate that they are unpublished versions.

For instance:

  • My wonderful page (12345)
  • My wonderful content (12923) Unpublished
  • Another page (12931)
  • Yet another page (18293) Unpublished

On our current website, which also implements Workbench Moderation and adds an Archived (formerly published) revision state, Archived pages with the same names as published pages already turn up in Entity Reference autofills. I have had complaints from staff that this is confusing to them as, if two pages, one published and one archived, have the same title, it's hard to pick the correct (published) one.

That said, it needs to be considered whether this feature needs to have a configuration checkbox to enable or disable it.

kbasarab’s picture

Patch #13 worked great for my use case as well. We have a custom widget built on type of entity reference fields that required referencing unpublished content. This patch has a tag for users to override if wanted but otherwise allows access without allowing bypass node access.

NancyDru’s picture

In my case, we are using ER for a taxonomy term. The node is new and unpublished. The link does not get created and we see The referenced entity (node: 1798) is invalid. in the log. This patch does not seem to fix this issue.

AdamPS’s picture

Category: Bug report » Feature request
Status: Needs work » Fixed

I also came looking for a way to allow a reference to unpublished content, so this issue is useful. However I would say the patch here is not suitable for commit.

I don't see that all sites want to allow references to be made to unpublished content. If node A is published and refers to node B that is not published, this could break the display of node A. So I would say that the existing behaviour is completely valid, and to change it may break existing sites.

Hence this seems to be a feature request "provide an option to allow references to unpublished content". How might this work?

  • Should such as feature go into the "Simple selection"? Well potentially not, because arguably simple is supposed to be simple - without too many options.
  • How about "View selection" mode? No problem - I would expect you can make that work exactly how you want by configuring the view - for example see #1504054: Make it possible to reference a non-published entity reference.
  • Finally if the default widget isn't what you need you can make another one - and @Ayrmax has already done this in #5.

So this seems to be a request for a feature that already exists in a couple of reasonable ways.

Some more specific comments on the patch. These should be resolved if adding this code as an option to the simple widget.

  • It works for nodes, but seems to miss out the equivalent cases for users, comments and taxonomy terms.
  • From reading the code, it seems to allow validation of an existing field pointing to an unpublished node, but doesn't allow a user to alter a field to point to an unpublished node (by means of getReferencableEntitiesentities). This might meet the specific requirement of some users, but doesn't seem like the mainline case to me. I would say that buildEntityFieldQuery ought to return the same data no matter what code is calling it.
John Pitcairn’s picture

@AdamPS: Agreed. Using a view without a "published" filter solves the problem, and that's what I have been using (sorry, I should have followed-up).

nicrodgers’s picture

Category: Feature request » Bug report
Status: Fixed » Needs work

Changing status back to needs work, as the comment in #23 doesn't address tyler.frankenstein's comment in #18 about not being able to programatically edit an unpublished node.

AdamPS’s picture

@nicrodgers I think what you are doing is termed issue-hijacking:-)

The OP has agreed with the resolution I posted for his issue.

It's often the case that related matters arise in the discussion in comments. As I understand it, the consensus in the community is to raise a new issue in the case where the related issue no longer has the same status as the original.

  • This means that future readers looking at the various issues can understand the status of each of them.
  • It clarifies that the remaining issue is specific to programmatic access, which the current title doesn't.
  • A further advantage of doing so is that it leads to a new "Issue summary". For #18 that would mean explaining what the desired behaviour is and why it can't possibly break any existing sites. (Patch as stands seems like it does break existing sites.)
AdamPS’s picture

Status: Needs work » Fixed

No reply from @nicrodgers, so closing this one again. The OP has agreed the problem is solved. Please open any related but different issue separately.

tyler.frankenstein’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

yonailo’s picture

Hello,

I do not understand why this issue has been closed. After the update of workbench_moderation module to version 1.4, there is no more hook_node_grants() and therefore I am not able to reference an unpublished node. This is important for workbench_moderation as it is commonly used to compose a complex page with a lot of references without publishing the referenced nodes until the complex page/content is ready.

A solution should be provided, I dont know if entity_reference is the right thing to hack or if we should go through a hook_query_alter() to modify the original query...

Moreover, I doubt that an entityreference patch is needed. Any module can implement hook_query_TAG_alter() with TAG = node_access to remove the query condition which adds NODE_PUBLISHED

Dubs’s picture

So this comment isn't strictly related to how this thread is progressing but will hopefully help similar configurations to mine.

In my case this error was due to the autocomplete values coming from a view. The view had a node:published filter. Removing this (or changing it to published or admin) fixed for me.

geerlingguy’s picture