Deleting paragraphs causes the entity usage tab to display confusing information

Here's what you'll see on the usage tab if you follow the instructions in the issue summary:

I think the problem here is the it is quite confusing what each column is referring to.

• Entity column links to the node
• Type column says it is a paragraph
• Status column says published which refers to the node

If you don't delete the paragraph but instead just remove or change media reference you'll see

And here you get a used in column which refers to the fact the media item is used in old revisions of the paragraph entity.

I'm not sure what the fix is but I think we need to be more clear about what each column is referring to as from user testing this completely confused people QAing a site I'm working on.

Published is actually the paragraph I think and not the node, unless there's custom code for that too.,

There is custom code for. this - see \Drupal\entity_usage\Controller\ListUsageController::getSourceEntityStatus() where it does:

    // Treat paragraph entities in a special manner. Paragraph entities
    // should get their host (parent) entity's status.
    if ($source_entity->getEntityTypeId() == 'paragraph') {
      assert($source_entity instanceof ParagraphInterface);
      $parent = $source_entity->getParentEntity();
      if (!empty($parent)) {
        return $this->getSourceEntityStatus($parent);
      }
    }

Discussed this with @daniel.bosen. Here's what I think we should do for paragraphs...
1. The entity title column should be the host entity title unless the paragraph is orphaned.
2. The status column should be removed.
3. The type column should be paragraph type on host type (unless orphaned)
4. The usage column should always be present and we should list where the entity is used in which revisions of the host entity via the paragraph.
5. If the paragraph is on the default revision and references the entity and the host is published then then the used in text will contain "Published revision"

For non paragraph usages we:
1. Remove the status column
2. Always are the used in column and if the entity reference is used on the default revision and the default revision is published then the text will contain "Published revision".

This issue could not be tackled without determining the target revision ID at entity usage save time. Well it could for paragraphs because we can go back and do a query to work this out. But it could not be done for non-reusable blocks placed using layout builder. This is because that information is embedded in a mass of serialized PHP. So I had to change tack at that point and when we are registering usage for paragraphs and content blocks embedded in layouts we record the revision ID in the entity usage table. We can then use this information to pair paragraph or content block with the correct revision of the thing (usually a node) that contains them.

I've also implemented what will probably turn out to be quite a big performance improvement on the entity usage tab in that once we work out that an entit is used in old revisions we stop processing once we will not display any further information. We can do this because we don't display any information about with older revisions the entity is used on.

In order to add the column to the entity usage table we need to rebuild it. Therefore the update path just drops and recreates the table with the new schema. For this reason I think this improvement belongs in a new major version of the module. What do you think @berdir and @marcoscano.

Here's where I'm currently at. To test this:

1. Create a paragraph type that has a media field
2. Create a paragraph type that has a paragraph field
3. Create a node type that has a paragraph field.
4. Create a media entity and enable entity usage tab on media entities.
5. Create a node with three paragraphs - one that directly links to the media, one that links to the media via another paragraph, and another that directly links to the media.
6. Edit the node and delete the last paragraph that directly links to the media entity.

On HEAD this is what you see:

With the MR:

So the one bit of information that you no longer get on the MR version is the paragraph type. But also the paragraph type information is incomplete even in HEAD because you don't know what the paragraph type is that has the paragraph field. Also the MR version is telling you the node type which I think is probably more useful in this context than the paragraph type.

@berdir what do you think?

Summarising a conversation between myself, @marcoscano and @berdir from a while back. We were discussing how to generalise the approach so the we can do the same for inline content entity blocks as the current MR is doing for paragraphs.

1. What is the best name for these plugins that allow an entity usage to determined by the host entity rather than itself? The best options were HostEntityUsageInterface or InlineEntityUsageInteraface

2. At the moment I’m stopping the user from being able to select paragraphs in the entity usage setting screen. Does this make sense? Should we ignore the case where a user has added a regular entity reference to paragraphs. If you create such a field in the UI you see a message saying Note: Regular paragraph fields should use the revision based reference fields, entity reference fields should only be used for cases when an existing paragraph is referenced from somewhere else. Should we allow the user to track that use-case? If so should we allow paragraphs to be selected on the UI but not track the case where a paragraph is referenced from an ERR field?

3. At the moment the UI allows you to enable and disable plugins but I think plugins that implement this new interface should not be able to be enabled or disabled by the user. They should be able to decide themselves - for example the ERR plugin should be enabled if the entity_reference_revisions module is installed.

4. How should we handle ERR fields to something other than a paragraph? Berder pointed out ERR itself doesn't hardcode paragraphs. it relies on the additional entity type definition keys for parent type/id to treat it accordingly, as does tmgmt. entity_usage could do the same, but maybe there are paragraph specific bits in the current language. the methods on paragraph entity at least aren't on an shared interface.

5. We already have hook_entity_usage_block_tracking for custom modules to implment complex requirements for when not to track. But I think we should replace that API with hooks from \Drupal\entity_usage\EntityUpdateManager::allowSourceEntityTracking() and \Drupal\entity_usage\EntityUpdateManager::allowTargetEntityTracking() as this would allow you to bail before doing the work. Imo this is a separate issue.

Given the discussion I'm going to try to abstract out the current approach to paragraphs and implement for inline content blocks so we can prove the new API can do this. Should have the side effect of fixing #3181406: Wrong text when entity is layout builder revision here.

After discussions with @daniel.bosen and trying to fix the generic case I've gone back to making this issue only deal with the paragraph case. Doing the inline block case meant we'd have to load some target entities to check if they were inline and this feels wrong / something that will be easier to explore in follow-ups. This change now fixes things for entity types that paragraphs which really are a special field on another entity type and never should be considered as an entity from the perspective of the user.

@daniel.bosen and I also had a good discussion about the the used in and status column. The "Status" column was removed. Its information is now part of the "Used in" column on the entity usage list page.

Each cell in the "Used in" column contains one or more of:

• "Published revision" — the source's default revision is published.
• "Draft revision" — applies in two cases: the source's default revision is unpublished, or a pending revision exists that is newer than the default. Only the latest pending revision per translation is shown.
• "1 old revision" or " N old revisions" — references exist in earlier revisions only. Pluralised based on the count of distinct prior revisions.
• "Current revision" — the source entity does not have a published status.

When a row contains more than one of these, they render as a bulleted list.