Permission "administer entity_sync_operation_type" is not defined

Created on 20 April 2023, almost 2 years ago
Updated 31 May 2023, almost 2 years ago

Problem/Motivation

Permission "administer entity_sync_operation_type" is not defined, therefore path "/admin/sync/config/operation-types/add" displays "Access denied"

Steps to reproduce

Access path "/admin/sync/config/operation-types/add"

Proposed resolution

Add permission "administer entity_sync_operation_type" to "entity_sync.permissions.yml"

💬 Support request
Status

Closed: works as designed

Version

4.0

Component

Documentation

Created by

🇪🇸Spain mrjey Sevilla

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @mrjey
  • 🇵🇪Peru krystalcode

    Hello, thanks for the question and giving me the opportunity to document the module a bit more.

    This page is not accessible not due to permissions, but because of lack of configurator plugins. To create an operation type you need to create a configurator plugin that determines certain aspects of the behavior for operations of the given type. For example, you can create a generic configurator plugin that determines the behavior of object imports of different types from a remote system that have similar APIs and models. Then you can create multiple operation types using the same configurator plugin for different entity types.

    Basic examples are fairly simple, have a look at the Acumatica integration and Entity Synchronization CSV modules.

    What you need to do is:

    - Create a configurator plugin
    - Rebuild caches
    - Then add an operation type - you shouldn't get this error anymore
    - Export as configuration
    - The UI does not allow you to determine all details, partly because it does not know the exact requirements, and partly because of missing features that may be added in the future.
    - You can expose more options to make things configurable via the configurator plugin form.
    - If you want to allow triggering operations manually via the UI, you should define a runner, but it is not necessary.

    The module supports two types of synchronizations:
    - Synchronization configuration entities (`entity_sync.sync.*`)
    - Operation type configuration entities (`entity_sync.operation_type.*`)

    The synchronization interface defines the interface of the configuration that you need to pass to the import/export managers in order to perform an operation. You could create you own class if it suits you, even though it is not recommended because I am only able to develop and test with the configuration entities officially provided by the module. You may come across issues if you work with something else.

    Operation types is the main way moving forward because it supports more features. The main differences are the following:

    Synchronizations can define multiple connected operations on the same entity in a single configuration file. For example:
    - Import a list of recently created or updated remote entities regularly
    - Export local entities from Drupal to a remote system individually as they are created or updated in Drupal

    This feature i.e. to connect different operation types is important at the moment in that particular case because the module has certain features that prevent import/export loops from happening i.e.:
    - An remote entity is imported
    - A local entity is updated as a result
    - Drupal sends the update back to the remote system
    - The remote system imports the updates
    - It then makes the updates available back to Drupal causing an endless loop

    This feature will be better supported at some point with operation types, but currently it is only tested with synchronizations.

    If you don't need the above feature and you only import entities, go with operation types. Operation types:
    - Can be managed via the UI (not fully yet, more could be added).
    - Operation content entities can be created and listed under `Sync/Operations` - the `Sync/Entities` is deprecated and might be removed, won't display anything out of the box.
    - Individual operations can be easily created and run via the UI by site managers, for example, just once please fetch the updates for a particular local entity etc.
    - Custom fields can be added on operation as need.
    - Operation content entities can keep track of the user that created the operation (import/export), the time it was created/changed, it follows a workflow which can be customized.
    - Runner services can be provided for operation types that make
    - More features will be built on top of it such as auditing i.e. all log messages will be stored against specific operations and specific entities so that developers can troubleshoot and site managers audit. Right now errors are logged as unstructure log messages in whatever central logging system the application uses.

  • Status changed to Postponed: needs info almost 2 years ago
  • Status changed to Closed: works as designed almost 2 years ago
  • 🇵🇪Peru krystalcode

    Closing due to lack of further feedback.

Production build 0.71.5 2024