# Data migration actions

Some migration steps can contain a special `actions` property. You can find which migration steps support actions in the table below:

|                | `create` | `update` | `delete` |
| -------------- | -------- | -------- | -------- |
| `content`      | ✔        | ✔        | ✔        |
| `content_type` | ✔        | ✔        | ✔        |
| `role`         | ✔        | ✔        |          |
| `user`         | ✔        | ✔        |          |
| `user_group`   | ✔        | ✔        |          |
| `company`      | ✔        |          |          |

Actions are optional operations that can be run after the main "body" of a migration has been executed (for example, content has been created / updated, object state has been added). Their purpose is to allow additional operations to be performed as part of this particular migration. They're executed inside the same transaction, so in the event of failure they cause database rollback to occur.

For example, when updating a content type object, some fields might be removed:

```
-
    type: content_type
    mode: update
    match:
        field: content_type_identifier
        value: article
    actions:
        - { action: assign_content_type_group, value: 'Media' }
        - { action: unassign_content_type_group, value: 'Content' }
        - { action: remove_field_by_identifier, value: 'short_title' }
        - { action: remove_drafts, value: null }
```

When executed, this migration:

- Finds content type using its identifier (`article`)
- Assigns content type group "Media"
- Removes it from content type group "Content"
- Removes the `short_title` field
- Removes its existing drafts, if any.

## Available migration actions

The following migration actions are available out of the box:

- `assign_object_state` (Content Create)
- `assign_parent_location` (Content Create / Update)
- `assign_section` (Content Update)
- `hide` (Content Create / Update)
- `reveal` (Content Create / Update)
- `assign_content_type_group` (Content type Create / Update)
- `remove_drafts` (Content type Update)
- `remove_field_by_identifier` (Content type Update)
- `unassign_content_type_group` (Content type Update)
- `add_block_to_available_blocks` (Content type Update)
- `assign_role_to_user` (Role Create / Update)
- `assign_role_to_user_group` (Role Create / Update)
- `assign_user_to_role` (User Create / Update)
- `assign_user_group_to_role` (User group Create / Update)
- `unassign_role_user_group` (User group Update)

In contrast with Kaliop migrations, actions provide you with ability to perform additional operations and extend the migration functionality. For more information, see [creating your own Actions](https://doc.ibexa.co/en/latest/content_management/data_migration/create_data_migration_action/index.md).

## Action usage examples

### Content

mode: Create

```
    actions:
        - { action: assign_object_state, identifier: locked, groupIdentifier: ibexa_lock }
        - { action: assign_parent_location, value: 2 }
        - { action: hide }
```

mode: Update

```
    actions:
        - { action: assign_parent_location, value: 2 }
        - { action: assign_section, id: 4 }
        - { action: assign_section, identifier: 'media' }
```

### Content types

mode: Create

```
    actions:
        - { action: assign_content_type_group, value: 'Media' }
```

mode: Update

```
    actions:
        - { action: assign_content_type_group, value: 'Media' }
        - { action: unassign_content_type_group, value: 'Content' }
        - { action: remove_field_by_identifier, value: 'short_title' }
        - { action: remove_drafts, value: null }
        - { action: add_block_to_available_blocks, fieldDefinitionIdentifier: 'page', blocks: ['event'] }
```

### Roles

mode: Create and Update

```
    actions:
        -
            action: assign_role_to_user_group
            remote_id: 'remote_id_152454854'
        -
            action: assign_role_to_user_group
            id: 42
        -
            action: assign_role_to_user
            id: 42
        -
            action: assign_role_to_user
            email: 'mail@invalid.c'
        -
            action: assign_role_to_user
            login: foo
```

### Users

mode: Create and Update

```
    actions:
        -
            action: assign_user_to_role
            identifier: foo
        -
            action: assign_user_to_role
            id: 2
        -
            action: assign_user_to_role
            id: 2
            limitation:
                type: Section
                values:
                    - 1
```

### User groups

mode: Create and Update

```
    actions:
        -
            action: assign_user_group_to_role
            identifier: Editor
        -
            action: assign_user_group_to_role
            id: 2
        -
            action: assign_user_group_to_role
            id: 1
            limitation:
                type: Section
                values:
                    - 1
```

Note

In the `assign_user_group_to_role` action, limitation type section can only use section ID.

mode: Update

```
    actions:
        -
            action: unassign_role_user_group
            id: 1
```

Note

In the `unassign_role_user_group` action, the ID is role assignment ID from the `ibexa_user_role` table.