# `MishkaCmsMigration.Targets.BlogBlogger`
[🔗](https://github.com/mishka-group/mishka_cms_migration/blob/v0.0.1/lib/mishka_cms_migration/targets/blog_blogger.ex#L6)

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"`).

# `error_return`

```elixir
@type error_return() ::
  {:error, [%{action: atom(), field: atom(), message: String.t()}]}
```

# `okey_return`

```elixir
@type okey_return() :: {:ok, struct() | map() | module() | [any()]}
```

# `child_spec`

Returns a specification to start this module under a supervisor.

See `Supervisor`.

# `config`

```elixir
@spec config() :: keyword()
```

# `config`

```elixir
@spec config(atom()) :: any()
```

# `enable`

```elixir
@spec enable() :: okey_return() | error_return()
```

# `get`

```elixir
@spec get() :: keyword()
```

# `health_check`

```elixir
@spec health_check() :: :ok | {:degraded, term()} | {:error, term()}
```

Optional. See `c:MishkaInstaller.Event.Hook.health_check/0`. Override to report health.

# `on_dependency_error`

```elixir
@spec on_dependency_error(term()) :: term()
```

Optional. See `c:MishkaInstaller.Event.Hook.on_dependency_error/1`. Override to react.

# `register`

```elixir
@spec register() :: okey_return() | error_return()
```

# `restart`

```elixir
@spec restart() :: okey_return() | error_return()
```

# `start`

```elixir
@spec start() :: okey_return() | error_return()
```

# `start_link`

# `stop`

```elixir
@spec stop() :: okey_return() | error_return()
```

# `unregister`

```elixir
@spec unregister() :: okey_return() | error_return()
```

# `users`

```elixir
@spec users([String.t()], MishkaCmsMigration.Target.context()) :: %{
  required(String.t()) => struct()
}
```

The users of the run's site with these `emails`, by lowercase email, read as the admin running
the job (`MishkaCmsMigration.Targets.Helpers.Read`): none the admin may not see, and never a
master or a user of another site.

---

*Consult [api-reference.md](api-reference.md) for complete listing*