Closed (fixed)
Project:
Drupal core
Version:
8.3.x-dev
Component:
rest.module
Priority:
Major
Category:
Task
Assigned:
Reporter:
Created:
4 Dec 2016 at 09:02 UTC
Updated:
21 Mar 2017 at 22:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
harings_rob commentedComment #3
harings_rob commentedComment #4
harings_rob commentedHi,
Attached I have added the patch. But I am running into a knowledge issue here.
The test seems pretty straight forward, so I guess that I either:
- Completely misunderstand the logic,
- Menu link content permissions don't make sense/Menu link content should be a config entity
CheckAccess seems to always require 'administer menu': \Drupal\menu_link_content\MenuLinkContentAccessControlHandler::checkAccess
Some hints/guidance would be welcome here.
Comment #5
wim leersWoot, thanks Rob!
To answer your questions regarding access handling: you're right that it's strange right now. We have similar strangeness for vocabulary & term entities, we have #2808217: To be able to view Vocabulary config entities via REST, one should not have to grant the 'administer taxonomy' permission + #2824408: To be able to create/update/delete Term entities via REST, one should not have to grant the 'administer taxonomy' permission to fix that. You could open a similar issue for
menu_link_contententities (but please don't do it in this issue, that would be out of scope). I think it'd make sense to add a more granular permission for viewing Menu Link content entities.The other
EntityResourceTestsubclasses also don't have these comments, so let's not start doing so here.All HTTP methods require the same permission for now, so we can simplify this.
Comment #6
webflo commentedComment #8
wim leersWoah, @webflo is in the house! I didn't know you were working on REST stuff :)
Comment #10
webflo commentedI work on it during SprintWeekend.
Comment #11
sumanthkumarc commented@webflo, i'm also working on similar issue, https://www.drupal.org/node/2843750 and following you on this. Any directions for me??
Comment #12
webflo commentedSome progress on hal+json.
Comment #13
webflo commentedComment #15
webflo commentedComment #17
webflo commentedComment #18
wim leersNice improvements to the base test class! :)
This looks perfect, thanks! :)
Comment #20
alexpottCommitted ef0a872 and pushed to 8.4.x. Thanks!
Committed 48ec098 and pushed to 8.3.x. Thanks!
Coding standards fixed on commit.
Comment #25
xjmUnfortunately, this seems to be failing in HEAD, so I reverted it. I'll add retests on the patch.
E.g.: https://www.drupal.org/pift-ci-job/596766
Comment #26
wim leersAh yes, the failing tests make sense: this needs a reroll after #2808233: REST 403 responses don't tell the user *why* access is not granted: requires deep Drupal understanding to figure out.
Apparently the RTBC queue is so long that testbot didn't actually do that yet, despite it landing about 2 days before this got committed.
Comment #27
jofitzPatch applies successfully on both 8.3.x and 8.4.x so does not appear to be a re-roll, but still Needs Work to address test failures.
Comment #28
harings_rob commentedAre the failures happening due to normalization?
Wanted to take a look, but not sure where to start
This seems like an actual bug in the implementation (Meaning test is ok). Needs a new issue?
This looks to me a formatting issue, might be due to my environment.. The same happens on Post and Delete..
Can we trigger testbot again?
Comment #29
wim leers#28: no that means this entity type has unauthorized access error messages that deviate from the default ones. That's fine.
It means we just need to override
getExpectedUnauthorizedAccessMessage(). For an example, see\Drupal\Tests\rest\Functional\EntityResource\User\UserResourceTestBase::getExpectedUnauthorizedAccessMessage().Comment #30
harings_rob commentedOk so what about the other one?
Comment #31
wim leersAll three errors are about that AFAICT :)
Comment #32
Anonymous (not verified) commented#20 coding standards + #29
getExpectedUnauthorizedAccessMessage+ cheat.About cheat:
It seems
neutral()still don't tell anything. But maybe we need bit more refactoring this part of code. Example::)
Comment #33
Anonymous (not verified) commentedone of fix not included :(
Comment #34
shadcn commentedNit: indentation. Thanks :)
Comment #35
Anonymous (not verified) commentedlet's fix it + few commas.
Comment #36
wim leersI compared #17 and #35 by applying both locally, and diffing them. Because it also fixes an indentation issue, I also had to use
--word-diff.This looks perfect.
Comment #38
Anonymous (not verified) commented@Wim Leers, thank you for review! Come back to RTBC.
Comment #40
Anonymous (not verified) commentednit reroll after #2751325: All serialized values are strings, should be integers/booleans when appropriate
Comment #43
wim leersThanks!
Comment #44
wim leersAs of #2577923-106: MenuLinkContent entities pointing to nodes are not deployable: LinkItem should have a "target_uuid" computed property, this is a blocker for #2577923.
Comment #45
alexpottCommitted and pushed e4461e6 to 8.4.x and 0dcbf65 to 8.3.x. Thanks!
I've backported this to 8.3.x as it 99.9% additional test coverage and the remainer just helps with REST adoption and has no BC concerns.
This is the one non test change in the patch and it's helpful and totally non-controversial.
Comment #48
wim leersAwesome :) Thanks, @alexpott, for your thoughtfulness!
Comment #49
Anonymous (not verified) commentedWoot!)
+ return AccessResult::neutral("The 'administer menu' permission is required.")->cachePerPermissions();This change has test coverage too. Without it we have fail:
But if we adding code:
we have other fail:
So change
MenuLinkContentAccessControlHandler::checkAccess()did not come for fun)EntityResourceTestBaseis a very cool, because it makes necessary to correct such places :)Comment #50
wim leers@vaplas: thanks for explaining the reason for that change so clearly! I'm sure it'll be helpful for future readers.
I'm glad you feel that way :)