We use revisions and content moderation heavily on node and sometimes owner of the node changes during article updates (node have published default revision + editor works on new version which is not published yet). It makes problem for second user, he is not able to edit the paragraphs he sees the lock icon on the paragraphs. If i check what user gets in ParagraphAccessControlHandler::checkAccess he gets default revision of the node in method getParentEntity() which is not correct... actually on the form he works on different revision and thats the reason he sees lock. Am I alone with this problem and we do have some issue on our project or is it an issue in the module / getParentEntity?
| Comment | File | Size | Author |
|---|---|---|---|
| #23 | Screenshot from 2023-01-31 22-26-51.png | 39.06 KB | artyom hovasapyan |
| #23 | Screenshot from 2023-01-31 22-34-04.png | 37.95 KB | artyom hovasapyan |
| #23 | Screenshot from 2023-01-31 22-17-34.png | 33.46 KB | artyom hovasapyan |
| #19 | 3084934-18.patch | 4.93 KB | artyom hovasapyan |
| #17 | interdiff_14-17.txt | 2.73 KB | mrshowerman |
Comments
Comment #2
snitta commentedSame here.
In my case users with specific roles couldn't edit paragraphs even when they could access node edit page if the following conditions were met:
1. the node's default revision and latest revision are different
2. the users can't edit the default revision
As mkolar noted the cause is getParentEntity() loading wrong revision.
Comment #3
sukanya.ramakrishnan commentedFacing the same issue!
Comment #4
sukanya.ramakrishnan commentedOk, the issue is the way the parent entity is referenced in the access check. Instead of getting the current revision, the default revision is getting loaded.
We need to check if the parent entity is revisionable and check the latest version for access!
Comment #5
sukanya.ramakrishnan commentedAdding a basic fix to get things going! Experts kindly advise if the revision is being loaded correctly! Needs extensive testing for non revisionable entities and translations!
Thanks
Sukanya
Comment #6
sukanya.ramakrishnan commentedSetting to needs review, thanks!
Comment #7
bkosborneClarified title
Comment #8
idebr commentedAttached patch implements the following changes:
Comment #10
idebr commentedAttached patch implements the following changes:
Comment #11
lendudeNeither the comment nor the IS mention why this would only be the case for Translatable content. Is there a reason? Or should we also cover non-Translatable content here?
Comment #12
aloneblood commentedAdd multilingual support for 3084934-10.patch
Comment #14
aloneblood commentedAdd multilingual support for 3084934-10.patch
Comment #15
mrshowermanI have the same issue, but a slightly different use case:
Expected result: paragraphs A and B are visible, due to the fact that the latest revisions of both paragraphs are published.
Actual result: paragraph A is visible, but not paragraph B. This is because the aforementioned parent entity access check for paragraph B looks at paragraph A's default revision, not the latest one.
Since the "view" permission had been ignored since #10 for good reasons, I had to add some more permission checks. Hope this doesn't fail the tests.
Also tried to address #11.
Comment #17
mrshowermanThought again about the right way to determine if we should check the latest parent revision when the permission is "view".
The other test fails might be related to PHP 7.3, not sure why that version was used in the test.
Comment #19
artyom hovasapyan commentedUpdate #17 change andIf to orIf
Comment #20
le72This is still an issue in our project. Any progress here? Patch #17 and/or #19 are looking promising.
Comment #21
mrshowerman#17 passes test when run against PHP 7.4, so setting back to NR.
@Artyom Hovasapyan, can you explain your change and also provide an interdiff?
Comment #23
artyom hovasapyan commentedOur project like this
1` enable drupal core module workflow (revision levels)
2` have translator roles (can only translate content)
3` when I created Node(draft version) and that time translator can not change paragraph(it's OK) but when change draft to In translation that moment Translator can not translate paragraph (It's wrong)
Thereby I offer change andIf to orIf . It's work correct (for me).
Comment #24
bkosborneIs loading the latest revision really the solution? Shouldn't the access check load the revision of the parent that this specific paragraph revision is attached to? That's not necessarily the latest revision, is it? I guess for the use case of editing, it is true that the latest revision is what should be loaded. But for viewing, I don't think so. For example, if I'm reviewing an older revision of a node, when the access check is run on the paragraph on that node revision, it should be checking if the user has access to view that specific revision of the node, not the latest revision of that node.
I don't think there's a way we can solve this because paragraph entities don't actually know what revision they're attached to. They only know what the entity ID is.
I think this cannot be solved correctly until #2954512: Store information about a paragraph's parent revision.
However, for the edit operation, I suppose we could assume that it's safe to always check the latest revision, which is something we can do.
Comment #25
bkosborne#3090200: Paragraph view access check using incorrect revision of its parent, leading to issues viewing paragraphs when reverted host entities or content moderation is used is basically the same as this issue, though that one primarily deals with the "view" operation not working right, and this issue deals with the "update" operation not working right. At the root of both is the problem that Paragraphs don't know what revision they are attached to. The latest patches in both these issues is essentially identical, they're both trying to load the latest revision of the parent which is not correct. In any case, I'm going to close this issue as a duplicate so efforts can be concentrated. That issue has more comments & activity and the issue summary is more detailed.