Paragraph access check using incorrect revision of its parent, leading to issues editing and viewing paragraphs when content moderation is involved.

Patch 3084934-13_combine_3090200-22.patch reviewed and it is working. RTBC

Update #43 change andIf to orIf

$access_result = $access_result->orIf($parent_access);

The last submitted patch, 45: 3084934-13_combine_3090200-22-update.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Update #43 change andIf to orIf

That's not right. It should be set back to andIf. Access to view a paragraph requires you have access to view both the paragraph entity AND the parent. Hiding those patches to avoid confusion.

I don't think this current patch is workable. As of the changes introduced in #17, it's just bypassing the parent entity access check entirely if the parent is a block or another paragraph. That seems wrong.

Marked 🐛 Paragraph access check via parent entity incorrectly uses the default revision of the parent instead of the latest Closed: duplicate as a duplicate of this. It's trying to solve the same problem, which essentially is that when a paragraph performs the access check on its parent, it's using the parent's default (AKA "active") revision, when it should be using the revision that that specific paragraph is attached to. I don't think this can be resolved properly until 📌 Store information about a paragraph's parent revision Active is resolved. Once it is, then this issue becomes really simple to solve.

That said, I think loading the parent's correct revision is most important when performing access control for the "view" operation of the paragraph. But for "edit" and "delete", loading the parent's latest revision is appropriate. I think we can solve for that now without waiting on 📌 Store information about a paragraph's parent revision Active

I wasn't able to reproduce this against 9.5.x, but perhaps I'm doing something wrong?

Because of this, paragraphs will not be viewable or editable unless the user has access to view/edit the default revision of the parent entity.

Is it a precondition that the user:

1. Has access to view forward revisions
2. Does not have access to view default revisions

for an entity type?

I finally have another set of steps to reproduce some wonky behavior here:

1. Add a node type with layout overrides enabled.
2. Add a block type with a paragraph on it.
3. Create a node instance and add a block instance to it, saved as Published.
4. Edit the node, add a paragraph item, save it as Draft.
5. Edit the node and observe that the paragraph items are unable to be edited or removed with the message "You are not allowed to edit or remove this item."

These are the steps that I'll follow for acceptance testing once we have a patch that doesn't bypass any pre-existing access checks.

Luke, indeed, I believe the root cause is responsible for both the issue where the paragraph cannot be viewed or edited. The issue with editing was documented in 🐛 Paragraph access check via parent entity incorrectly uses the default revision of the parent instead of the latest Closed: duplicate which I closed as a duplicate of this one.

Curious that in your reproduction steps, the paragraphs is still viewable on the published version of the page?

Yeah, they are still visible on the front end for me.

Wouldn't storing the paragraphs' parent revision be sort of impossible for historical data?

I don't think this current patch is workable. As of the changes introduced in #17, it's just bypassing the parent entity access check entirely if the parent is a block or another paragraph. That seems wrong.

I think I should explain further why this is bad. Imagine you had a private file field on the paragraph which is on the block. Private file fields defer their access control to the entity they're attached to. In this case, it would be the paragraph. This patch, as is, would allow everyone to access the private file.

Patch in #22 works well for the specific issue I was encountering, which is explained in the opening post.

Here's an alternative solution for this problem. The idea is to rely on core's Typed Data system for retrieving the host entity of a paragraph, it's based on the patch proposed in this Drupal core issue: 📌 Allow the 'entity' property of entity reference fields to be aware of its position in the typed data tree Needs review , and it also needs the Entity Reference Revisions patch from 📌 Allow the 'entity' property of entity reference revision fields to be aware of its position in the typed data tree Postponed .

Posted a new patch in the ERR issue ( #3428639-3: Allow the 'entity' property of entity reference revision fields to be aware of its position in the typed data tree → ), which is simpler and doesn't have to wait for the core issue. So all we need to solve the Layout Builder -> Custom block -> Paragraph problems is the Entity Reference Revisions patch and the one above for Paragraphs.

Hi @amateescu
The alternative patch #60 solution for this problem is not working for me. Do we still need waiting for review? Thanks!

@smethawee, have you also applied the patch for Entity Reference Revisions mentioned in #61?

@amateescu Thank you so much for you connected.
Yes, here what I did below anything that I have to add?

Regards,

"drupal/entity_reference_revisions": {
"#3428639-7": " https://www.drupal.org/files/issues/2024-03-16/3428639-7.patch → "
},
"drupal/content_moderation": {
"content-moderation-events-79": " https://www.drupal.org/files/issues/2023-10-11/2873287-content-moderatio... → "
}

i tried patch #60 and the Entity Reference Revisions patch mentioned in #61, and it does render my paragraphs in layout_builder edit mode but they are still locked and uneditable. previously the paragraphs would not even render while editing a layout

Hi @amateescu and @realgt patch #43 is not working for me too. So wondering about this fix. Thanks!