The "user" items of a source, its authors, written as the Blog's bloggers (MishkaBlog.Blogger), each the profile of a user of the run's site, through the :create and :update an admin's own blogger form runs, on the run's site and as the admin who pressed Import: the admin needs the Blog's admin:dashboard:blog:post, and the Blog's own rules decide the rest, such as one slug and one profile per user on a site, and that a profile names a user of its own site.

An item's title is the blogger's display name (its "username" when it has none), its "slug" the blogger's slug, its "description" the bio (an empty one is none) and the largest of its "avatar_urls" the avatar. Its email is never the blogger's public contact address, and its roles give nothing: a source's administrator becomes a blogger like any other author.

Whose profile

The user is the one whose email is the item's "email" among the users of the run's site, read as the admin (existing/2), so the admin needs the core's admin:dashboard:user to find any. Only the site's own users are read: a master, or a user of another site, with that address is never matched. Then, by the run's authors choice (MishkaCmsMigration.MigrationRun's options):

• a user who has a blogger profile on the site — the item is connected to it: the profile is kept as it is, now and on every later run, and the report says "connected";
• a user who has none — a blogger is created for them;
• no user, under "connect" (the default) — skipped as "no_user", and nothing is created;
• no user, under "create" — a user of the site is created first, inside the blogger's transaction, through the core's :tenant_create (the action an admin's own New user form runs) as the admin, who needs the core's admin:dashboard:user: with no permission, and a password of 32 random bytes that is neither kept nor shown, so nobody can sign in with it: WordPress's password hashes cannot be carried over, so the person uses Forgot password or a social sign-in. The core's "Confirm your email address" mail is not sent (the changeset carries mishka_install: true, which its sender skips). By the run's confirm_users choice the user is then confirmed through the core's :confirm_pending (the default), or left unconfirmed for an admin to confirm from the Users table's bulk Confirm email. An address the installation already has, such as a master's or another site's user's, is refused by the core and the item fails with its reason.

The import's report says "user_created" for a blogger whose user it made (note/2), which MishkaCmsMigrationWeb.Live.Admin.Dashboard.PasswordNotice warns about on the run and on the item.

A re-run writes the profile over a blogger it created, as any target does, and never changes whose profile it is: the user is named on create only.

Defined only where Mishka Blog is loaded, and supervised by MishkaCmsMigration.Application only then; on a node without the Blog its items wait for it ("blog_missing").