Score:1

Referencing disabled users during migration

in flag

I have migration that creates files. For file owners I'm trying to find existing user by email and if don't find I create one on fly. Problem is that those users I'm creating must be disabled (I don't want them to login to site). But if I disable them and I try to use them as file owner I get the message:

"This entity (user: 187) cannot be referenced."

I can disable validation for that migration file, but it will disable totally, not only for this user check.

I tried using Account Switcher (from event subscriber, reacting on pre_import and post_import events) to switch to user 1 before migration starts and switch back when ends, but didn't help.

Any idea how to reference disabled users during migration, but with keeping validation turned on?

Update:

Did some research and this checking is done at \Drupal\user\Plugin\EntityReferenceSelection\UserSelection::buildEntityQuery()

There's a code:

// Adding the permission check is sadly insufficient for users: core
// requires us to also know about the concept of 'blocked' and 'active'.
if (!$this->currentUser->hasPermission('administer users')) {
  $query->condition('status', 1);
}

And if I comment out those line, it's not checked if user is disabled or not and validation ends successfully.

Strange thing is that even I use Account Switcher to switch to user 1 and inside my process plugin user really is 1 when this code is executed user is not 1 any more, but the one I created and assigned to file (disabled one), so must be that import is also using Account Switcher? Any idea how to solve this? Can I force migration to be run as specific (admin) user?

usmanjutt84 avatar
in flag
Is your migration based on your own custom module?
usmanjutt84 avatar
in flag
As I migrate from D7 to D9, it works perfectly via programmatically on my end. `$d9Node->setOwnerId($d9Uid);`
in flag
Yes it is. I have custom process plugin which copies file S3 bucket to bucket and then I'm registering those files to drupal's file system with File::create() where I'm passing user id as one of the parameters. Those files are used by following migration to create media image entities by referencing created files.
in flag
But I would prefer some general solution - most of the migration won't use my custom plugin(s).
Alireza Tabatabaeian avatar
cn flag
you mean you want all site users being disabled? why don't you let them be enabled and them disable them all after migration is done?
in flag
@AlirezaTabatabaeian not all. Just those I'm creating. And I want then be able to reference them as file/entity owners, while validation is turned on for the migration file.
Alireza Tabatabaeian avatar
cn flag
In this case I would add a Boolean field, lets call it `field_should_disabled` and in case of creating those kind of user would give them the value of True and then I could continue migrating with these user being enabled and disable them when migration finished, even field can be removed after that
in flag
@AlirezaTabatabaeian sorry, I don't understand you. Even if I switch user to user 1 during migration it's at somoe point switched back to user I created, which is disabled and referencing fails. That is the problem.
Alireza Tabatabaeian avatar
cn flag
I suggest you that leave users be enabled so you can migrate with no problem, but you don't want them to be enabled on your site, so the solution could be post pone disabling these users, and to keep track of which users should be disabled and which users should not you can set a value on their account (using an extra field), was I more clear now? :)
in flag
Yes, clear now. Could probably be some kind of workaround. I would have to take care of all the users used in migration, not only those I create since existing ones can also be disabled, but doable.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.