Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
entity system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
11 Dec 2013 at 11:23 UTC
Updated:
19 Mar 2015 at 20:31 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
amateescu commentedDuplicate of #2120871: Rename EntityListController to EntityListBuilder.
Comment #2
andypostSo let's simply rename the issue
Comment #3
andypostComment #4
xjmComment #5
berdir3: 2154435-entity-access-3.patch queued for re-testing.
Comment #8
andypostComment #11
andypostproper merge
Comment #12
andypostAnd one more
Comment #15
andypostFinally green and waits for reviews
Comment #16
andypostAs was discussed this should be a handler because actually this kind of classes introduce access checker but the name used by routing
Patch also unifies all doc blocks and comments
Comment #18
andypostFix broken test
Comment #19
andypostAnd a bit more comments fixed
Comment #21
andypostFix last broken test
Comment #24
tstoecklerI actually thought EntityAccess was quite a nice name and more inline with where we're going with EntityStorage, EntityList, etc.
Comment #25
berdirEntityList has been changed to EntityListBuilder as it's not an entity list, it is something that builds a list of entities. Just like this isn't an entity access, it handles/checks access to entities.
Comment #26
berdirEntityStorage is different, because it actually represents the storage, so I'm fine with that.
Comment #27
andypostre-roll
Comment #28
tstoecklerAll right, I'm fine with it. #25/ #26 is very arguable, though. EntityStorage isn't the storage either, the DB (or whatever) is the storage, EntityStorage is the one that provides access to the storage. So it could be named StorageHandler as well. Also we have a thing called FormInterface but that actually *builds* forms (i.e. FormInterface::buildForm()) but we apparently conceive it as *the form* conceptually. So EntityList could just as well be conceived as *the list*.
Again, don't want to hold this up just wanted to point that out.
Comment #29
effulgentsia commentedJust to play devil's advocate, why not leave this one as AccessController, since "access control" is standard software terminology?
Comment #30
andypostbecause controllers used for different purpose ;) in current core
Comment #31
effulgentsia commented"controller" has a well established meaning in MVC terminology and in Symfony routing. But "access control" also has a well established meaning in software systems. So while I get the benefit of renaming "controller" as a generic Drupalism away from the entity system, I'm not yet convinced of the need to remove "AccessController". Can you clarify what the problem is in having the overlap, given that it's not an overlap we're inventing?
Comment #32
andypostre-roll
Comment #33
andypostRe-roll, pushed to
sandbox/yched/1736366.gitbranch2154435-entity-access-handlerComment #34
andypostComment #35
andypostComment #36
andypostre-roll
Comment #38
andypost36: 2154435-entity-access-handler-36.patch queued for re-testing.
Comment #39
andypostre-roll after #2120871: Rename EntityListController to EntityListBuilder
Comment #40
andypostfixed wrong merge
Comment #42
berdirNew suggestion from @alexpott: EntityAccessControl.
Let's discuss this in person before we continue here.
Comment #43
xjmI'd prefer either
EntityAccessControlorEntityAccessControlHandler.Comment #44
andypostEntityAccessControlHandlerlooks great!So how to rename
EntityManager->getAccess()?just a test of re-roll
Comment #46
xjmComment #47
effulgentsia commentedHaving spent some time the past few days with our route access check(er)s in #2222719: Use parameter matching via reflection for access checks instead of pulling variables from request attributes, I'm actually left wondering whether
AccessCheckerwould be the best suffix. I kind of like it. What do you all think?As a separate issue, I wouldn't mind us renaming all of the routing ones from
*AccessCheckto*AccessCheckeras well. If we felt a need to disambiguate between route access checkers and entity access checkers, then we could make the route ones*RouteAccessChecker, or the entity ones*EntityAccessChecker, or both, but at the moment, I don't really see a need for that disambiguation as there's other context cues for whether you're dealing with a route or an entity.Just floating the thought out there. If other than me, there's consensus on EntityAccessControl or EntityAccessControlHandler, go ahead with that. It's hard to please everyone, so I'm willing to go along with whatever people generally like most.
Comment #48
effulgentsia commentedOh, and one more comment on why I think it's ok for route access classes and entity access classes to have the same suffix: it's just like *Storage. We have php storage, keyvalue storage, config storage, entity storage, etc., and classes implementing any of those is simply named *Storage, and IMO, there's no confusion with that. So I think the same would be true for access checking.
Comment #49
berdirHm, while it is true that we have many storage things, they all do have different names.
Assuming we'd rename both to checker, then we'd have two EntityAccessChecker classes, and one would be using the other to check access. Having two layers of access checks is already pretty confusing, and giving them the same name wouldn't help.
We had this situation with entity lists, where we had a route controller EntityListController that called the other EntityListController to build the list of entities which were then returned, I think that was pretty confusing.
Comment #50
effulgentsia commentedIn the case of the literal class EntityAccessCheck(er), we could rename that one to EntityRouteAccessCheck(er). And similar for others where the entity type name and the route access type name are too similar. But I think there are very few of those.
Comment #51
andypostre-roll pushed to sandbox, so can we get consensus here? or better to postpone this one on rename routing to
EntityRouteAccessCheck(er)Comment #52
andypostComment #53
berdir51: 2154435-entity-access-handler-51.patch queued for re-testing.
Comment #55
chx commentedWe are not rearranging the deck chairs on the Titanic. #2204363: [sechole] Returning TRUE from hook_entity_access()/hook_ENTITYTYPE_access() must not bypass EntityAccessController::checkAccess() has priority.
Comment #56
chx commentedComment #57
xjm@chx, does this really need to be postponed on that? It seems like #2204363: [sechole] Returning TRUE from hook_entity_access()/hook_ENTITYTYPE_access() must not bypass EntityAccessController::checkAccess() would be pretty easy to reroll for the class renames.
Comment #58
chx commentedWhen are we going to stop blowing security holes into Drupal and deprioritizing the fixes?
Comment #59
chx commentedOf course, it's easy to reroll that but in my opinion (which is quite strong due to that bug still being open and the title XSS ) we do not have our priorities straight when we say "oh it's just a slight inconvenience" yes it is but it's a security issue and we should not inconvenience security fixes. Give not an inch. Thou shalt not suffer a sechole to live. etc.
Comment #60
chx commentedAt the time, let's move forward with this and re-debate when it gets to commit. I do understand the need to work :/
Comment #61
mparker17The patch in #51 no longer applies to 8.x HEAD.
When I tried to re-roll the patch, I got a bunch of merge conflicts :S
Comment #62
xjmI think we should just go with FooAccessControlHandler since it's explicit and less likely to be confused, so that we can go forward here and get this in.
@mparker17 is working on a reroll now. :)
Comment #63
mparker17Note that the patch in #51 did not rename the "access" key to either "access_control" or "access_control_handler" as discussed in #1976158: Rename entity storage/list/form/render "controllers" to handlers, so this re-roll doesn't either.
Because there are so many changes to 8.x HEAD since the last patch, because re-rolling has so many merge conflicts, because it's difficult to generate an interdiff, and because I'm a n00b, I'm going to post the steps I took to re-roll the path. I'd appreciate it if @andypost could review these to make sure I didn't mess up somewhere.
Using PHPStorm 7.1.3:
\Drupal\Core\Entity\EntityAccessControllerInterfaceto\Drupal\Core\Entity\EntityAccessHandlerInterface, using the following options:EntityAccessControllerInterface.phptoEntityAccessHandlerInterface.php, I say "yes".EntityAccessControllertoEntityAccessHandler, I say "yes".\Drupal\Core\Entity\EntityManager::getAccessController()to\Drupal\Core\Entity\EntityManager::getAccessHandler(), using the following options:get('entity.manager')->getAccessController()withget('entity.manager')->getAccessHandler().\Drupal\Core\Entity\EntityAccessHandlerfrom "Controller" to "Handler".Note
\Drupal\filter\FilterFormatAccessshould be re-named to\Drupal\filter\FilterFormatAccessHandler.At time-of-writing, here are the subclasses of EntityAccessHandler I knew about:
\Drupal\node\NodeAccessControllerto\Drupal\node\NodeAccessHandler.\Drupal\language\LanguageAccessControllerto\Drupal\language\LanguageAccessHandler.\Drupal\system\DateFormatAccessControllerto\Drupal\system\DateFormatAccessHandler.\Drupal\filter\FilterFormatAccessto\Drupal\filter\FilterFormatAccessHandler.\Drupal\contact\CategoryAccessControllerto\Drupal\contact\CategoryAccessHandler.\Drupal\field\FieldInstanceConfigAccessControllerto\Drupal\field\Handler.\Drupal\views\ViewAccessControllerto\Drupal\views\ViewAccessHandler.\Drupal\comment\CommentAccessControllerto\Drupal\comment\CommentAccessHandler.\Drupal\block\BlockAccessControllerto\Drupal\block\BlockAccessHandler.\Drupal\config_test\ConfigTestAccessControllerto\Drupal\config_test\ConfigTestAccessHandler.\Drupal\node\NodeTypeAccessControllerto\Drupal\node\NodeTypeAccessHandler.\Drupal\menu_link\MenuLinkAccessControllerto\Drupal\menu_link\MenuLinkAccessHandler.\Drupal\system\MenuAccessControllerto\Drupal\system\MenuAccessHandler.\Drupal\taxonomy\TermAccessControllerto\Drupal\taxonomy\TermAccessHandler.\Drupal\user\UserAccessControllerto\Drupal\user\UserAccessHandler.\Drupal\block_content\BlockContentAccessControllerto\Drupal\block_content\BlockContentAccessHandler.\Drupal\shortcut\ShortcutSetAccessControllerto\Drupal\shortcut\ShortcutSetAccessHandler.\Drupal\user\RoleAccessControllerto\Drupal\user\RoleAccessHandler.\Drupal\search\SearchPageAccessControllerto\Drupal\search\SearchPageAccessHandler.\Drupal\entity_test\EntityTestAccessControllerto\Drupal\entity_test\EntityTestAccessHandler.\Drupal\shortcut\ShortcutAccessControllerto\Drupal\shortcut\ShortcutAccessHandler.\Drupal\system\Tests\Entity\EntityAccessTestto\Drupal\system\Tests\Entity\EntityAccessHandlerTest.core/modules/system/core.api.php'sentity_apianduser_apisections so they refer to "access handlers" instead of "access controllers"\Drupal\entity_test\Entity\EntityTestDefaultAccessso it refers to "access handlers" instead of "access controllers".@seeline that does not end with a period.Comment #65
mparker17Note that the patch + instructions-for-rerolling in #63 don't include @xjm's suggestion in #62. And testbot doesn't like it either :S
Comment #66
mparker17Oops, apparently I didn't rename the file containing EntityAccessHandler. Hopefully testbot will like it now.
Comment #67
mparker17Oops, I need to set it to "needs review" in order for Testbot to pay attention to it. :P
Comment #68
andypostAlso the doc blocks should be updated to new name
Comment #70
mparker17Umm... I don't see how any of those test-run errors are related to the changes made in this patch.
Comment #73
berdirThose errors mean that unit tests are failing, run them locally with cd core; ./vendor/bin/phpunit to see the actual fails, testbot is not able to report fatal errors from unit tests properly.
Comment #74
andypostFixed re-roll
Comment #75
andypostNow patch is green, so I pushed the code to sandbox and will try to rename all this again
Comment #76
andypostShould this named as getAccessControlHandler?
Comment #77
berdirRe-rolled this based on the sandbox, pushed updated branch.
Did not yet rename it, do we have an agreement on AccessControlHandler now? If so, then I'm going to do the rename...
Comment #78
berdirBad timing, menu_link is gone now, so another reroll.
Comment #79
dawehnerGreat patch! Will RTBC this one when the question is answered.
Given that there is a node specific access interface wouldn't make it sense to typehint here?
OT: do we have a followup to drop tis script again?
Comment #80
xjm@dawehener, re: point 2: yep, #2277739: Remove core/scripts/switch-psr4.sh is "revisit before release candidate".
Comment #81
berdirRe-uploading the file, crosspost killed it.
Comment #82
xjmWe discussed yesterday with @effulgentsia, @berdir, @yched, @timplunkett, and myself that we will go with EntityAccessControlHandler for the name.
Comment #83
berdirYep. Leads to some pretty long names, but otherwise, this should be OK. No traces of "AccessHandler", "AccessController", "entity access controller", "entity access handler", "access_handler" or "access_controller" left in core/.
Interdiff was as big as the actual patch, so leaving that out...
Comment #84
berdirUpdated issue summary a bit.
Comment #85
berdirUpdated issue summary a bit.
Comment #86
xjmSkimming the changes in this patch, I definitely think this is the right way to go. Everything is automatically less confusing in code and documentation alike with that terminology.
Comment #89
berdirRe-roll.
Comment #90
andypostLet's get this in and finish renames
Comment #91
alexpottNeeds a reroll
Comment #92
berdirTrivial context conflict, sometimes I'm wondering why git isn't smarter about some of those conflicts, patch apply I can understand but git merge hat the same problem. The method above getAccessControlHandler() is now getFieldMapByFieldType() instead of getFieldMap(), that's all that changed, see manual patch diff. So keeping at RTBC.
Comment #93
alexpottCommitted 258856a and pushed to 8.0.x. Thanks!
Let's update all these CRs https://www.drupal.org/list-changes/published/drupal?keywords_descriptio...
Comment #95
berdirFinally!
Working on the change records.
Comment #96
berdirOk, all traces of access controller and AccessController updated, only mention left is in https://www.drupal.org/node/2200867, as the old name.
Comment #98
kerby70 commentedNote for related searches:
change EntityAccessControllerInterface to EntityAccessControlHandlerInterface