# F. Doctrine aliases: Administrator/User

This section can be followed when overriding other aliases.
We are explaining for Administrator override example.

## How to setup doctrine entity aliasing

```yaml
# config/packages/doctrine.yaml
doctrine:
    # [...]
    orm:
        # [...]
        # add the admin
        resolve_target_entities:
            AutoAdmin\Bundle\Admin\Model\AdministratorInterface: App\Entity\User
```

Make sure to use the proper provider (only on old project, new projects should have the right config on creation).

```yaml
# config/packages/security.yaml
security:
    # [...]
    providers:
        # [...]
        database_admin:
            id: AutoAdmin\Bundle\Admin\Security\AdministratorProvider
```

Extend AdministratorModel

```php
# src/Entity/User.php

namespace App\Entity;

# [...]
use AutoAdmin\Bundle\Admin\Model\AdministratorModel;
# [...]

#[ORM\Entity(repositoryClass: UserRepository::class)]
class User extends AdministratorModel
{
# [...]
}
```

Do not forget to generate your migrations.

If administrator entity/table were already existing, you may have to first remap the administrator interface to the app
user in doctrine config, but generate migration before inheriting AdministratorModel to first un-map Administrator
entity and database table.
Once the migration removes the administrator table, you should be able to inherit AdministratorModel and generate a new
migration for new table update.

Finally, if you migrate your entities to AdministratorModel, you may inherit uniqueness constraints on string columns (username, email, etc...)
When doctrine generate migrations, these constraints cannot be accounted for, so you are responsible for the data integrity though migrations.
If nothing is done the migrations may fail, but it is often as simple as running a query for preserving uniqueness integrity (for example: "UPDATE user SET username = email").

