Parent entity access check throws PHP notice because $nid nor $vid are set

I'm sorry I got this into a release. We were in a hurry to bring out a security fix.
Does this patch fix it? It turns the $op into 'create' when the entity is new.

I thought of a simpler patch.

Is it possible this issue is back again? Currently using latest dev.

@RaF7 can you tell me the line of the notice?

Notice: Undefined property: stdClass::$nid in node_access()

This notice is triggered during entity access check on line 285 of paragraphs.module.

if (entity_access($check_parent_op, $entity->hostEntityType(), $host_entity)) {
      $permissions[$account->uid][$cid][$op] = PARAGRAPHS_ITEM_ACCESS_ALLOW;
      $parent_permissions[$account->uid][$parent_cid][$check_parent_op] = PARAGRAPHS_ITEM_ACCESS_ALLOW;
    }

This happens when you add a new node that has to possibility to contain paragraphs.
During the paragraph item access check the host entity is being fetched as an object without a 'nid' while node_access() checks if the entity is an object or just a string (ex: node bundle)

$cid = is_object($node) ? $node->nid : $node;

What version of the entity API are you using?

Hi Jeroen,

Currently i'm using entity-1.6

Hi,

Getting this issue too with paragraphy fields within a field_collection on a node:

node
- field_collection
-- paragraph 1
-- paragraph 2

Using Entity API: 1.6, Paragraph 7.x-1.0-rc4 & Field Collection 7.x-1.0-beta11.

Attached patch seems to fix it but not 100% sure of any access implications as I'm not so familiar with this module yet.

Cheers
Tom

Just noting:

The fix in #5 is not in the present dev version of the module. I also acknowledge that may not be the most appropriate fix any longer

; Information added by Drupal.org packaging script on 2016-04-22
version = "7.x-1.0-rc4+1-dev"
core = "7.x"
project = "paragraphs"
datestamp = "1461369540"

That could be right. I totally rewrote the access checking because there were quite some issues with it.

@thomjjames, I'm currently trying to get the quality of the code up to par with the D8 version.
That mostly just means we need to add many tests to make sure we won't break anything.
Are you able to create a unit test for this? (and provide 2 patches: 1 with the fixed code + test, 1 with the test only. that way we can see the test actually confirms it is fixed now).

Thanks for patch #14, worked for me

Same issue, with latest version of paragraphs (7.x-1.0-rc4) and entity API (7.x-1.8).

Patch from #14 works fine, but I can't tell if it's a good practice to set $host_entity to NULL.

Put $host_entity to NULL is quite huge.
I think to set $host_entity->is_new = true should be enough and could do the job.

Just stumbled over this issue too.
Patch looks good to me and solves the issue - so I'd say RTBC.

See #17. We need to get some tests going to cover this.

When debugging I noticed the $hostEntity actually is a user object instead of a node? Of course this object does not have the 'is_new' property nor a nid...
Can anyone confirm that they also see a user as $hostEntity? This does not seem OK allthough I'm not familiar with this module's code.
But passing a user as 3th arg to entity_access is not correct and adding a 'is_new' to this object (patch #20) is not correct either allthough it fixes the warning...

Still have this issue in rc4 with latest entity and entity API modules

Patch 14 doesnt really fix the issue.
By doing "$host_entity = NULL;" it will break the permission.

You have to do "$host_entity->is_new = true" like said on comment #20.

Thank you to @Sebastien @Actualys !

Patch in #20 is working for me!

@lorenzs #17: The values you are seeing are the default values added by the node module itself, see http://cgit.drupalcode.org/drupal/tree/modules/node/node.pages.inc?h=7.x...

@eelkeblok #22: What exactly do we need tests for? This issue is fixing a notice, not changing any APIs?

That would be a question for @jeroen.b, I suppose. I was just relaying his request for tests from #17, I had not given the question on how exactly test for this condition any thought (ideally, we *should* be testing for this condition to not occur).

With the patch #20, it's ok for me !!!

Patch in #20 fixed the issue. Thanks !

+1 on #20 too.. worked for me.

#20 fixed the issue.

I'm increasing the priority of this to critical, as it appears to fix an issue that is causing Paragraphs to fail all automated tests, thus holding up other issues in the queue.

+1 on bumping priority on this as it is holding back other issues.

This indeed does not need tests. Committed, thanks!

Coool ! Thanks!