Problem/Motivation

I wrote some twig templates for rendering storage entities to stop myself from loading a bunch of fields and doing stupid rewrites in views of single entities that are related to ones of different types (here's A, the B's in it, and lists of Cs by status) (here's B and the A it belongs to, all the C's in it), (here's a C, then the A and B related to it), etc.

The entities weren't being rendered on a non-admin account, and had a "duh" moment - I needed to give them permission to "View published Storage entities". Doing so led to a long load time and the following error:

Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 20480 bytes) in /app/web/core/lib/Drupal/Core/Entity/EntityDisplayBase.php on line 377

I tried a role with intermediary permissions and it worked. Hmm.

Unticking permissions from that role one by one, I found that with only "Edit any Storage entity" and "View published Storage entities" checked would the view load normally. This was a dummy account, if necessary I could create an entity with it and then try "View own published Storage entities".

I definitely don't want that role to be able to edit those entities!

I recognize this module is built around data that isn't displayed directly, but there are permissions for it and I feel like this can't be a unique use case.

These are not editable fields or anything fancy like that, just default form mode.

Steps to reproduce

Load a storage entity type into a views field by adding a "Rendered entity Storage Renders an entity in a view mode" field.

Set the only storage permissions for the role on the account logged in to "Edit any Storage entity" and "View published Storage entities".

View the view.

Uncheck "Edit any Storage entity" so only "View published Storage entities" and check again.

Only having "Edit any Storage entity" leads to the page rendering normally, but the rendered entity fields being invisible.

Issue fork storage-3457737

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

erutan created an issue.

rishabjasrotia made their first commit to this issue’s fork.

erutan’s picture

erutan commented

I’m guessing this is based around how the display page gets routed to /edit/, so even in a view render it gets stuck in a loop going from render to edit to render or something.

erutan’s picture

erutan commented

I was able to work around this by using https://www.drupal.org/project/field_permissions to just make so the role I wanted to be able to see this entity type can't edit any of the fields. A little annoying, and it means being careful when adding new fields as they can hit them by manually figuring out where to go URL wise but it worked.

Interestingly this seems to be possibly related to https://www.drupal.org/project/storage/issues/3460699 - I only had to do this for two entity types that had file fields on them. An entity type that I wanted to render as a field in a view without a file field works without any permissions change. I didn't notice this before as all 3 views for a single entity used each other's related entities in a different format with their own views tucked in on the bottom via VFV.

The comment form glitched out - I reported the previous ones as spam and hopefully they'll get removed.