Paragraph view access check using incorrect revision of its parent, leading to issues viewing paragraphs when reverted host entities or content moderation is used

I'm running into a potentially related issue where I am building out some content, exporting it via Default Content, and then re-installing the site and importing it's default content. The result is the paragraphs render correctly when viewing the node, but when you edit the layout with "Show preview" checked then you don't see any of the paragraphs render.

I applied this patch and it did not fix the issue for me, unfortunately. I don't want to set to Needs work, however, since I was not testing this specific use case.

I sorted out my previous issue (the inline_block_usage table was not being populated when default content was imported).

I have since moved on to testing this use case, since it applies to us as we are using Content Moderation. After following the reproduction steps I can verify that this issue exists for me, but I can also verify that the attached patch does not resolve the issue, so I am setting it back to Needs work.

Hmm, I just found https://www.drupal.org/project/drupal/issues/3047022#comment-13324107. I applied the most recent patch in that issue and made the 'view' addition to checked operations as you described @Poindexterous and now everything is magically working. Moving this back to Needs work because, honestly, I'm not actually sure what needs work. This is a cluster of a web of issues between Layout Builder, Paragraphs, Block Content, and Content Moderation.

I'm gonna dig in to this a bit but going to leave unassigned because I won't remember to re-assign it otherwise...

I had to tweak the patch in #3 to allow access on paragraphs when editing them in the settings tray in the builder UI after reverting to a previous version of the node.

The combination of this patch (#11) and the patch from https://www.drupal.org/project/drupal/issues/3047022#comment-13339620 have things working for me finally, it seems. I'll keep a close eye on things.

@Poindexterous THANK YOU for documenting this wonderful ticket!

I tested the information in comment #11 and found this correct. You need these two patches:

• https://www.drupal.org/files/issues/2019-11-05/incorrect-parent-revision...
• https://www.drupal.org/files/issues/2019-11-04/3047022-26.patch

just as @lpeabody said. I did not review either patch, only confirmed it resolved the behavior described in the ticket.

Confirming that #11 along with https://www.drupal.org/project/drupal/issues/3047022#comment-13339620 fixed my issues too, thanks so much for the hard work! We definitely need tests here though

EDIT: Spoke too soon, still having problems https://www.drupal.org/project/drupal/issues/3047022#comment-13432352

I was using the patch from #11, but encountered an issue where many paragraphs stopped displaying because of being access denied. The cause of that was that revision field data, e.g. from ERR, can have multiple records that point to the same paragraph revision. That means that this query can legitimately return multiple records.

$revision_ids = $target_entity_storage
  ->getQuery()
  ->allRevisions()
  ->condition($paragraph_target_revision_id, $paragraph_rid)
  ->condition($paragraph_target_id, $paragraph_id)
  ->execute();

Adding a ->sort('revision_id', 'DESC') gave me the result I expected, which is the latest field revision. Attaching a patch with that addition, plus using dependency injection for the entityTypeManger service.

I'm not sure if there's a better way for a paragraph revision to find its true, current parent, when multiple revisions of the parent point to the same revision of the paragraph.

I bumped into another case where the query to get the correct revision of the parent was getting the wrong revision, leading to an access denied. This new case is pretty easy to replicate:

• On a published page that has a block that has a paragraph, placed in layout builder.
• Create a draft.
• Edit the placed block and save it without making any changes. (This creates multiple field revision entries pointing to the same paragraph revision.)
• The paragraphs on the published page disappear.

Because it seems really difficult to reliably load the correct revision of the parent entity for access checking, I've changed approach to just return the current $access_result if the parent entity is a block or paragraph.

So, I am also using Paragraphs on a custom block type, which is then used as an inline block in Layout Builder. I am also using Content Moderation and to make matters worse, this is a multilingual site. I'm pulling my hair out over here. I'm on Drupal 8.8.5. I've tried so many different combinations of patches and I am still having issues when placing the node that contains a paragraph block into draft status. If it was previously published, and then I edit the paragraph block in Layout Builder and then place the node in draft status and then go back to editing the block with the paragraph in it, I get "You are not allowed to edit or remove this {Paragraph}.", where {Paragrpah} is the name of the paragraph.

Is anyone else using a system with all of these modules successfully? I'm just trying to figure out the right combination of patches.

THANKS

@nadavoid unfortunately #17 breaks editing in certain situations, whereas #16 doesn't.

For transparency I have these other patches applied:

Core:
https://www.drupal.org/files/issues/2020-04-27/3131126-3.patch
https://www.drupal.org/files/issues/2019-05-21/3053887-11.patch
Paragraphs:
https://www.drupal.org/files/issues/2019-03-22/2901390-n24.patch

Steps to reproduce issues with #17:
1) Create LB controlled page
2) Add block with paragraphs (doesn't need to be nested)
3) Save the page
4) Edit the page, editing some of the data in the paragraphs
5) Revert to the previous revision
6) Edit the block again
7) You will see the "You are not allowed to edit or remove this ." message

This does not happen with #16

EDIT:

16 still has issues with editing blocks on reverted revisions and adding a new paragraph item - this results in an access denied again :(

Based on your comments I've added update operation to the #17 patch, I'm not sure that it's right handling of this issue, but at least it works for editing flow.

SWEET. It looks like #22 worked for me! THANKS

#22 appears to be working for me.

(Also, anyone experiencing or working on this issue, you are a good person, you are important, don't let it get you down.)

#22 seems to be working when creating a draft but seems to be breaking when reverting to a previous revision. After reverting, when I try to edit and save the block, I get the following error:

The content has either been modified by another user, or you have already submitted modifications. As a result, your changes cannot be saved.

Anyone getting the same thing?

nmwd Yes, can confirm. I get the same error when trying to edit a paragraph that has previously been reverted. I get lot's of form errors and the message you mentioned. Shame, as the patch fixes our other issue :)

The patch from 3053881-32 fixes the issue pointed out in #25 about not being able to edit after reverting to a previous revision.

Like Beanjammin, I'm using patch 22 here with #3053881-32: Reverting entity revisions that contain custom blocks erroneously triggers EntityChangedConstraint and things seem to be working well.

Our relevant core/paragraphs patch stack:

         "patches": {
             "drupal/core": {
                "#3053881 - Reverting entity revisions that contain custom blocks erroneously triggers EntityChangedConstraint": "https://www.drupal.org/files/issues/2020-09-07/3053881-34.patch"
             },
             "drupal/paragraphs": {
                 "#3090200 - Fix Paragraphs when creating inline block in layout builder for blocks that have paragraphs and saving page as draft.": "https://www.drupal.org/files/issues/2020-07-08/access-controll-issue-3090200-22.patch"
             },

We do have a similar issue, but it is connected to nodes that were cloned.
Cloned paragraph items still have the old node as parent id.
If a user doesn't have access to that node - he is not able to edit this node.

Patch #22 and the patch mentioned in #28 seem to work for me. What's needed to help move this forward?

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

(along with https://www.drupal.org/project/drupal/issues/3053881#comment-13814032)

 "patches": {
      "drupal/core": {
        "Reverting entity revisions that contain custom blocks erroneously triggers EntityChangedConstraint": "https://www.drupal.org/files/issues/2022-02-03/3053881-68.patch"
      },
      "drupal/paragraphs": {
        "Paragraphs do not render: access check for 'view' fail": "https://www.drupal.org/files/issues/2020-07-08/access-controll-issue-3090200-22.patch",
        "Integrity constraint violation: 1048 Column 'langcode' cannot be null": "https://www.drupal.org/files/issues/2020-06-25/paragraphs-2901390-51.patch"
  }
}

Access check parent entity revision issue 3084934 and access controll issue 3090200 merge

Just as an update, this applies to simply having a paragraph field in a custom block type. Layout builder is not required to trigger this error.

Combine 3090200-22.patch with another issue 3084934-13.patch(https://www.drupal.org/files/issues/2022-07-21/3084934-13.patch)

Combine 3090200-22.patch with another issue 3084934-13.patch(https://www.drupal.org/files/issues/2022-07-21/3084934-13.patch)

pls use https://www.drupal.org/files/issues/2022-10-26/3084934-13_combine_309020... instead

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);

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 #3084934: Paragraph access check via parent entity incorrectly uses the default revision of the parent instead of the latest 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 #2954512: Store information about a paragraph's parent revision 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 generally seems appropriate. I think we can solve for that now without waiting on #2954512: Store information about a paragraph's parent revision

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 #3084934: Paragraph access check via parent entity incorrectly uses the default revision of the parent instead of the latest 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: #3428635: Allow the 'entity' property of entity reference fields to be aware of its position in the typed data tree, and it also needs the Entity Reference Revisions patch from #3428639: Allow the 'entity' property of entity reference revision fields to be aware of its position in the typed data tree.

Posted a new patch in the ERR issue (#3428639-7: 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

edit: patch #43 worked for me

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

Patch #43 worked for me, it allowed to unblock the situation on both editing, and display on the frontend.

Patch #43 worked for me. Layout builder shows the correct entities in a non published state, and the published version displays the correct revisions.

Can confirm patch #43 worked for me too with Drupal 10.3.1 and Paragraphs 1.18.

Confirming #43 Still works on 10.4.6

Using layout builder, paragraphs, content moderation & entity reference revisions.

Making the patch into a merge request (MR) increases changes for this getting merged. As the issue is tagged with "needs tests" and patch(es) contains none do I push this back to NW.

I've rolled #22 into an MR as that's the patch we've been using in prod for years. I like the idea of #60 but that'll have much wider reaching BC issues for sites using getParentEntity so I'm not sure how viable that'll be. Still NW for tests.

These patches are not right. You need to be extra careful that the paragraphs on your sites don't have private file fields on them otherwise you risk anyone in the world being able to download those files. Maybe for 99% of you that's not the case, but I can't imagine this patch ever getting committed for that reason.

Clarifying the title to indicate that the scope of this issue is related specifically to the view permission of the paragraph and that the issue is present both with forward drafts from content moderation or when reverting host entities (page layouts) to previous revisions. Edit/delete permission should be resolved by this core issue that's hopefully committed soon: #3047022: Layout builder fails to assign inline block access dependencies for the overrides section storage on entities with pending revisions.

Could someone help clarify what patch (if any) would be good for version 1.19?
Thanks in advance

Patch #43 worked for me!

Drupal version: 10.4.7
Paragraphs version: 1.18