destination entity validation doesn't work for entity types that have no owner

I'm not sure what exactly we could do here, except carve out an exception in core for paragraphs. Two issues here, first, under the current code, the paragraph owner is the owner of the parent entity. Your issue isn't that the paragraph is owned by anonymous, it's that you haven't given it a parent yet at the time you are trying to validate it. Secondly, it seems that paragraphs has deprecated their use of EntityOwnerInterface, meaning in the near future, even if you did assign the parent during the migration (which is not something you would typically do) It's still going to not provide an owner to validate against though the normal entity api. You would have to know it was a paragraph and that paragraphs validate in the UI through the parent's owner, then go find that (possibly through nested paragraphs) specially for paragraphs, which we won't do in core.

Without paragraphs providing an owner to validate against, there isn't much we can do, since we can't really validate, because we don't know what permissions to validate against for things like text format of a body field.

I think this might have to be paragraph's problem. I don't see how we can support validation in this instance if paragraphs is going to do something funky outside the entity api in it's own validation.

I am open to suggestions though.

> Your issue isn't that the paragraph is owned by anonymous, it's that you haven't given it a parent yet at the time you are trying to validate it.

Yup. I'm migrating the paragraphs first -- which is the most logical way of doing it -- and then later on the nodes with the paragraph reference field using a lookup to the paragraph migration.

> Secondly, it seems that paragraphs has deprecated their use of EntityOwnerInterface

I don't see that in the latest code for paragraphs module:

> interface ParagraphInterface extends ContentEntityInterface, EntityOwnerInterface, EntityNeedsSaveInterface, EntityPublishedInterface {

I can see several ways to deal with this.

1. Dummy parent entity

Set an existing entity as the paragraph owner in the paragraph migration, as a dummy. The entity needs to be owned by a user with the same privileges as the eventual parent nodes in the migration (or stronger privileges, I suppose, but then you could get false negative validation, say a text format that the eventual owner doesn't have access to).

This requires the migration website to already have a node, say, owner by a user with sufficient permissions. It also means you have to hardcode the entity ID into your paragraph migration configuration, which isn't ideal.

When the node migration runs, EntityReferenceRevisionsItem will handle the change in parentage and re-save the paragraph with the migrated node as the new parent. (I think! This is based on reading the code.)

2. Migrate validation lets you choose a user

As well as using the entity owner to validate, add a property to the content entity migration destination to pick a user to validate as.

Again, this hardcodes a content entity ID into the migration configuration, the user in this case.

3. Migrate validation lets you choose roles

I looked into making a temporary, unsaved user entity with specific roles for checking access a while ago, though I can't remember where it was. There might be an issue about it?

At any rate, I got stuck at the point where code tries to determine whether the user is anonymous or not -- and it does that by getting the user ID.

But if there's a use case for it, this could be made to work with some changes in core.

I don't see that in the latest code for paragraphs module:

> interface ParagraphInterface extends ContentEntityInterface, EntityOwnerInterface, EntityNeedsSaveInterface, EntityPublishedInterface {

I just noticed that the actual methods of EntityOwnerInterface are deprecated on the Paragraph entity, but I don't know the whole story or for how long that's been the case.

https://git.drupalcode.org/project/paragraphs/-/blob/8.x-1.x/src/Entity/...

Oh yeah.

Well that's going to make it problematic for migrations when they eventually remove that :/