Steps to reproduce:
- create an entity reference field referencing a block on article
- create a block and set any condition (e.g. only visible on admin pages)
- create an article and reference this block and save
- go back to edit screen.
You'll see something like '- Restricted access - (block_id)' in the textfield.
Tricky one to fix right I suppose, maybe other (config) entities might have the same problem.
The quick fix I did for now was overriding the block access handler and adding following lines in the accessCheck method
// On queues, everything is fine for block contents.
$path = \Drupal::request()->getPathInfo();
$parts = explode('/', $path);
$settings = $entity->get('settings');
if ($operation == 'view' && isset($parts[3]) && $parts[3] == 'entityqueue' && $settings['provider'] == 'block_content') {
return AccessResult::allowed();
}
Note, custom project, so this works fine for me now, not sure what the proper solution would be here.
Comment | File | Size | Author |
---|---|---|---|
#8 | interdiff.txt | 1.08 KB | amateescu |
#8 | 2634158-8.patch | 3.88 KB | amateescu |
#5 | 2634158-5.patch | 2.8 KB | swentel |
Comments
Comment #2
amateescu CreditAttribution: amateescu commentedBoth myself and @swentel can not reproduce this with core alone, so it must be a site-specific problem.
Comment #3
swentel CreditAttribution: swentel commentedCould actually produce this now, it's a core problem.
Comment #4
swentel CreditAttribution: swentel commentedComment #5
swentel CreditAttribution: swentel commentedTest that demonstrates the bug.
(note been a bit lazy and went for standard profile for now)
Comment #7
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThis will be easy to fix once #2471154: Anonymous user label can't be viewed and auth user labels are only accessible with 'access user profiles' permission is done.
Comment #8
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThat patch was committed to 8.1.x and 8.2.x, so we can fix this now for those two branches.
Comment #9
BerdirJust wondering what you're doing with those kind of references.
We have an existing issue that shows that such a reference doesn't really make sense since you wouldn't be able to reliably show those blocks anyway (they are theme specific, might have any kind of visibility restruction and so on).
And that the better approach to reference "blocks" would be to reference to block plugins with inline configuration, based on Xano's plugin project for example.
Are we really sure about that? we're talking about admin labels.
Comment #10
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedOuch, that's right. Should we check the 'administer blocks' permission instead?
Comment #11
BerdirMaybe? I'm not really sure what entity reference does with such an all-or-nothing reference case, what happens exactly if you don't have that permission? you shouldn't be able to see them in the first place? We unfortunately don't have a list operation, if we'd have that, we could deny access to such a field completely.
Comment #12
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThen let's wait for @swentel to expand on his use case a bit, since I'm pretty sure he's aware of the shortcomings of referencing block entities.
Comment #14
jibranMoving to right component
Comment #15
BerdirPer #12
Comment #22
pameeela CreditAttribution: pameeela commented@swentel, as part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)".
There haven't been any updates on this since it was postponed in 2016 - do you think it can be closed now?
Comment #23
swentel CreditAttribution: swentel commented@pameela it's been ages since I encountered this and I don't really remember the use case anymore, so I'm totally fine with closing it :)
Comment #24
pameeela CreditAttribution: pameeela commented