Closed (fixed)
Project:
Drupal core
Version:
11.x-dev
Component:
node system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
10 Mar 2019 at 10:56 UTC
Updated:
18 Aug 2025 at 15:44 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
claudiu.cristeaPatch.
Comment #3
claudiu.cristeaComment #4
andypostLooks nice, but how this internal cache will be cleared? I guess it needs extra tests
Comment #6
claudiu.cristea@andypost, We already have the method on the interface:
EntityAccessControlHandlerInterface::resetCache(). We only need to extend it.Comment #7
claudiu.cristeaCover also the case when 3rd party code tries to reset the static cache by doing:
Updated also the CR to account that.
Comment #8
berdirI think adding extra API's to EntityAccessControlHandlers is a bit problematic, but we have quite a few grant related methods there already, so it makes sense I suppose.
We don't do unit tests for functions, as loading stuff then pollutes other unit tests.
I'd suggest to simply make this a kernel test, should be much simpler?
Comment #11
ridhimaabrol24 commentedRerolled patch for 9.1.x
Moved test methods to core/modules/node/tests/src/Kernel/NodeAccessTest.php
Please review!
Comment #14
longwaveNeeds another reroll, also needs the deprecation updating.
Comment #15
vsujeetkumar commentedRe-roll patch created, Also updated deprecations. Please have a look.
Comment #16
vsujeetkumar commentedFixed format issue, Please have a look.
Comment #18
vsujeetkumar commentedFixed fail deprecation tests, Please have a look.
Comment #20
claudiu.cristeaThe following issues we're fixed in MR.
Should avoid dot at the end of message.
New code, let's strict type the return.
#8.2, not fully addressed. We should drop container stuff and file inclusion. Kernel tests offers all.
Comment #21
berdirAdded some comments.
Comment #22
daffie commentedComment #23
daffie commentedFor the unresolved threads on the MR.
Comment #29
acbramley commentedTest will fail until #3514197: ModuleHandler::resetImplementations should reset all properties with hook implementations is fixed.
Comment #30
acbramley commentedComment #31
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #32
acbramley commentedComment #33
smustgrave commentedCan the CR also be updated that drupal_static_reset() with the node_grant key is deprecated.
Comment #34
acbramley commentedDone
Comment #35
smustgrave commentedLGTM
Comment #36
catchOne comment on the MR.
Comment #37
acbramley commentedConverted to use a memory cache
Comment #38
smustgrave commentedThink we missed the 11.2 boat can those be updated to 11.3, reviewed again and closed the rest of the threads as answered.
If you are another contributor eager to jump in, please allow the previous poster(s) at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!
Comment #39
acbramley commentedComment #40
smustgrave commentedThanks! All feedback appears to be addressed
Comment #41
alexpottAdding issue credit.
As per @acbramley, I'm concerned that the focus of this issue is about the use of drupal_static and not the node access API. I think it is great to refactor out usages of drupal static - but this needs to be done with an eye to the resulting API. We have the following node access related functions left in node.module and we should have a plan for them:
Are there issues for the other methods? It feels as though they split down into two groups:
Are there existing issues? I think not looking at #3532197: [meta] Deprecate node.module functions.
I think we need to agree the API shape before doing this issue and once we've done that we should focus the issues on doing that and as a by product remove drupal_static usage where we can.
I think that converting
node_access_grantsandnode_access_view_all_nodesto a single service makes sense. I also think the service should be marked as @internal because it is API glue and if you want to affect this API you sure be implementing the hooks and not doing anything to this service.Comment #42
acbramley commentedAdded #3533299: Deprecate node access rebuild functions and updated #2473041: Restructure node access grant behavior into the node access handler
I think node_access_grants could live on the service that this provides, maybe with a new method name as per the IS in that issue to more accurately describe what it does (and so it's not so confusing with hook_node_grants)
What do you think @alexpott?
Comment #43
alexpott@acbramley yes I think this issue could create a service for both of these methods in node.module. I've been trying to think if any of the existing node access services could be locations and I think I agree with the earlier posts - a separate service is a good idea. I considered node.grant_storage but I think this is not about storage and the new service needs to be injected into that one. I also considered cache_context.user.node_grants - or maybe making a new service that is also a cache context but that felt overly complex to. Therefore a new service with two public methods for each function we're replacing and marked @internal because it is not meant to be extended - the extension points are the node grant hooks.
Comment #44
acbramley commentedHow's that?
The other method should be moved in the other issue
Comment #45
alexpott@acbramley I think we should widen the scope to include the other function here. Doing it piecemeal results in a less complete API for no real gain.
Comment #46
acbramley commentedComment #47
acbramley commentedComment #48
acbramley commentedDeprecated node_access_grants as well and added the note to the @internal tag.
I think a good next step would be to flesh out #2473041: Restructure node access grant behavior into the node access handler. The first step should probably be to remove all/most of the grants functions from NodeAccessControlHandler, especially the ones that just proxy to the grant storage service. Like there's no reason
hasViewAllNodesGrantorNodeRequirements::runtimeneeds to call a function on the access control handler...I also found some interesting stuff like NodeHooks1::nodeAccess which implements hook_ENTITY_TYPE_access for its own entity type 🤷♂️ There's no wonder why barely anyone understands this system fully (including myself)
Comment #50
alexpottSo after refactoring
node_access_view_all_nodes()into\Drupal\node\NodeGrantDatabaseStorage::checkAll()- see https://git.drupalcode.org/project/drupal/-/merge_requests/12586 - I think this issue can return to it's original intent - because there is no real API change. And then we can use #2473041: Restructure node access grant behavior into the node access handler to decide how to deal with node_access_grants() as part of an issue that is completely API focussed.@acbramley sorry it is taken a while to see through the API trees here but I think that the new MR points to a better place :)
Comment #51
alexpottOne thing that is "interesting" is that
node_access_view_all_nodes()is documented to return a bool. ATM in 11.x it only does this if there are nohook_node_grantsimplementations. Otherwise it returns a 0 or 1 integer because that's whatDrupal::entityTypeManager()->getAccessControlHandler('node')->checkAllGrants($account)returns. With the new MR it will always return a 0 or 1. Boo to us and our lax return types. I think we should do a separate issue and CR to change\Drupal\node\NodeAccessControlHandlerInterface::checkAllGrants()and\Drupal\node\NodeGrantDatabaseStorageInterface::checkAll()to return a bool as this is a TRUE / FALSE access check and an integer is confusing.Comment #52
acbramley commentedAdded some notes on both MRs, I don't really think I like either now lol
Comment #53
alexpott@acbramley I've responded to your points on the new MR.
Comment #54
acbramley commentedI guess we need someone else to weigh in, I don't feel this is much cleaner than my MR but it's hard when this whole system is a bowl of spaghetti in the first place.
I'd appreciate if you could add any notes to #2473041: Restructure node access grant behavior into the node access handler on what you'd like to achieve there too since we've flip flopped a couple of times.
Comment #55
xjmNode access subsystem maintainer here.
I haven't had a chance to review the MR in detail yet (will try to do so soon) but I strongly, strongly advise against making any API or behavior changes in this issue. The functionality of this and all the procedural functions in the node access system has a lot of edgecase behaviors that are fiddly and changing them even slightly can break access control behavior on sites with complicated implementations. We don't only have to worry about individual contrib modules; we have to worry about sites with multiple access control modules, or custom code that implements custom access control and/or integrates multiple access control modules, which is very common.
The refactoring and eventual deprecation of the whole API is much more feasible now that D7 is EOL, but for scope management's sake and for the sake of not having surprise behavior changes or access bypasses on some weird edgecase sites, none of it should happen in this issue. This issue should only deprecate and move the code so we can get it out of the
.modulefile. We have an opportunity for many followups!Thanks!
Comment #56
xjmComment #57
xjmComment #58
acbramley commentedThis is back to just
node_access_view_all_nodesComment #59
catchAdding #2199001: Statically cache node access grants as related issue, don't think it's relevant to this issue but it would be relevant to further refactoring to try to get rid of the circular/semi-circular dependencies.
Comment #60
xjmFollowups followups ➡️ 😇
Comment #62
alexpottUpdated issue summary reflect the approach.
Comment #63
alexpott@xjm I think we have all the follow-ups in place already. I found an existing issue for the return types - #2863737: Change the return type of NodeGrantDatabaseStorageInterface::checkAll() and NodeAccessControlHandler::checkAllGrants() to a bool and the deprecation / moving about of node.module code has plenty of issues #2473041: Restructure node access grant behavior into the node access handler and #3532197: [meta] Deprecate node.module functions for example. Is there something else we need to put in place?
Comment #64
alexpottComment #65
acbramley commentedRebased, fixed a minor issue in the deprecation message and updated the CR a bit. I think this is good to go now. Agree that the follow ups we have in #63 cover plenty.
The main API change is going from returning TRUE when there are no grant hook implementations to returning 1 (to match the return signature of checkAll). That will then change in 2863737 so I think that's fine for now. The deprecated function still returns what it used to.
Leaving in NR since this is tagged for subsystem maintainer review which is not me.
Comment #66
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #67
acbramley commentedRebased again.
Comment #69
xjmRe:
If it's blocked on subsystem maintainers for an extended period in general it can also be escalated to framework managers, although in this case since a subsytem maintainer is also a release manager someone RTBCing it with the tag on is fine as well. Meanwhile though I'm also going to ping the other active maintainer for the subsystem since I still don't have time to look at this this week.
Comment #70
agentrickardFrom the node_access subsystem perspective, this seems fine.
From a module developer perspective, it's also fine, as I consider node_access_view_all_nodes() to be an internal function and don't call it directly. Even if I did, there is an OO replacement I can use, and this code directs me to that.
Comment #71
xjmUntagging from #70; thanks Ken!
Note for committers, as I mentioned in Slack: The one thing here that needs very careful attention from a reviewer is the test coverage, to ensure the coverage is exactly identical with the new API. The fact that the test passes is not sufficient by itself.
Comment #72
xjmOh, belatedly confirming #63 -- @alexpott and I already discussed that in Slack last week but it looks like our consensus that the followups are covered did not make it back onto the issue. So we are all good. Thanks!
Comment #73
xjmAnd updated credits.
Comment #74
acbramley commentedGreat, this is RTBC then
Comment #76
catchThis looks good to me. Committed/pushed to 11.x, thanks!