How to Implement Dynamic Entity History Tracking for Runtime-Created Entities? #12682

2 Answer(s)

• 

  0

  [email protected] created one month ago

  Hi @ismcagdas,

  any update?

  Markdown is supported

  Copy & paste or drag & drop images (max 30 MB per image)

  Save Cancel
• 

  0

  oguzhanagir created one month ago

  Support Team

  Hi @[email protected]

  Short answer up front: you don't need to hard code anything. ABP evaluates entity-history selectors at runtime the predicate you register is invoked on every SaveChanges, for every changed entity type.

  So instead of registering N static types, you register one selector whose predicate asks your own runtime store. EntityHistoryHelper.TrackedTypes is ASP.NET Zero template code, not ABP API you are free to replace it.

  Can selectors be registered dynamically at runtime?

  The selector list is built once in PreInitialize, but the decision is dynamic. Register a single dynamic selector:

  // *.EntityFrameworkCore/EntityFrameworkCore/AbpZeroTemplateEntityFrameworkCoreModule.cs -> PreInitialize()
  Configuration.EntityHistory.IsEnabled = true; // master switch, keep it true
  
  IDynamicEntityHistoryConfiguration dynamicConfig = null;
  Configuration.EntityHistory.Selectors.Add(new NamedTypeSelector(
      "DynamicEntityHistorySelector",
      type =>
      {
          // resolved lazily: components are not registered yet during PreInitialize
          dynamicConfig ??= IocManager.Resolve<IDynamicEntityHistoryConfiguration>();
          return dynamicConfig.IsTracked(type);
      }));
  
  Configuration.CustomConfigProviders.Add(new DynamicEntityHistoryConfigProvider());
  

  Configuration.EntityHistory.Selectors is an IEntityHistorySelectorList (a live List<NamedTypeSelector> with RemoveByName), so you can technically mutate it at runtime but we don't recommend it: it's a singleton startup object, it isn't thread-safe, changes are lost on restart and they never reach the other nodes in a web farm. The single predicate approach has none of these problems.

  Is EntityHistoryHelper.TrackedTypes meant to be static?

  It is a convenience array that lives in your solution (*.Core/EntityHistory/EntityHistoryHelper.cs); ABP never reads it. It's referenced in exactly three places, and all three must be replaced for a dynamic setup:

  1. AbpZeroTemplateEntityFrameworkCoreModule.PreInitialize → the selector registration (above)
  2. EntityHistoryConfigProvider → the list sent to the UI (below)
  3. AuditLogAppService.GetEntityHistoryObjectTypes() → this one is easy to miss. It intersects the enabled entities with the static HostSideTrackedTypes / TenantSideTrackedTypes arrays, so if you skip it the Object filter on Audit Logs → Entity Changes will stay empty for your dynamic entities.

  Which API should hold the dynamic list?

  There is no built in entity history manager you own the store. We would suggest an ABP setting (ISettingManager, scope Application | Tenant): you get per tenant configuration, built-in caching and an editable value with no migration and no redeploy. A dedicated entity works equally well if you need auditing of the toggles themselves.

  // *.Core/EntityHistory/DynamicEntityHistoryConfiguration.cs
  public interface IDynamicEntityHistoryConfiguration
  {
      bool IsTracked(Type entityType);
      List<string> GetEnabledEntityTypeNames();
      Task SetEnabledEntityTypeNamesAsync(List<string> entityTypeFullNames);
  }
  
  public class DynamicEntityHistoryConfiguration : IDynamicEntityHistoryConfiguration, ISingletonDependency
  {
      public const string SettingName = "App.EntityHistory.EnabledEntities"; // comma separated full names
      private const string CacheName = "DynamicEntityHistoryCache";
  
      private readonly ISettingManager _settingManager;
      private readonly IAbpSession _abpSession;      // ClaimsAbpSession is ISingletonDependency -> safe here
      private readonly ICacheManager _cacheManager;
  
      public DynamicEntityHistoryConfiguration(
          ISettingManager settingManager, IAbpSession abpSession, ICacheManager cacheManager)
      {
          _settingManager = settingManager;
          _abpSession = abpSession;
          _cacheManager = cacheManager;
      }
  
      public bool IsTracked(Type entityType)
      {
          return GetEnabledEntityTypeNames().Contains(entityType.FullName);
      }
  
      public List<string> GetEnabledEntityTypeNames()
      {
          var tenantId = _abpSession.TenantId;
          return _cacheManager.GetCache<string, List<string>>(CacheName)
              .Get(tenantId?.ToString() ?? "host", () => ReadFromSettings(tenantId));
      }
  
      public async Task SetEnabledEntityTypeNamesAsync(List<string> entityTypeFullNames)
      {
          var value = entityTypeFullNames.JoinAsString(",");
          var tenantId = _abpSession.TenantId;
  
          if (tenantId.HasValue)
          {
              await _settingManager.ChangeSettingForTenantAsync(tenantId.Value, SettingName, value);
          }
          else
          {
              await _settingManager.ChangeSettingForApplicationAsync(SettingName, value);
          }
  
          await _cacheManager.GetCache<string, List<string>>(CacheName)
              .RemoveAsync(tenantId?.ToString() ?? "host");
      }
  
      private List<string> ReadFromSettings(int? tenantId)
      {
          var value = tenantId.HasValue
              ? _settingManager.GetSettingValueForTenant(SettingName, tenantId.Value)
              : _settingManager.GetSettingValueForApplication(SettingName);
  
          return value.IsNullOrWhiteSpace()
              ? new List<string>()
              : value.Split(',', StringSplitOptions.RemoveEmptyEntries).Select(x => x.Trim()).ToList();
      }
  }
  

  Define the setting in your AppSettingProvider with SettingScopes.Application | SettingScopes.Tenant, then expose a small [AbpAuthorize(...)] app service (GetAvailableEntities / GetEnabledEntities / SetEnabledEntities) for the admin screen.

  Two rules for the predicate: it runs inside the SaveChanges pipeline for every changed entry, so (a) keep it O(1) and cached, and (b) never open a unit of work / hit a repository there. Use a distributed cache (Redis) or a short TTL if you run multiple instances, since a toggle on node A must invalidate node B.

  How should EntityHistoryConfigProvider be implemented?

  ICustomConfigProvider.GetConfig is executed per request (on /AbpUserConfiguration/GetAll, and on every IAbpStartupConfiguration.GetCustomConfig() call), so simply returning the current dynamic list is enough no restart, no redeploy:

  public class DynamicEntityHistoryConfigProvider : ICustomConfigProvider
  {
      public Dictionary<string, object> GetConfig(CustomConfigProviderContext context)
      {
          var startupConfiguration = context.IocResolver.Resolve<IAbpStartupConfiguration>();
  
          if (!startupConfiguration.EntityHistory.IsEnabled)
          {
              return new Dictionary<string, object>
              {
                  { EntityHistoryHelper.EntityHistoryConfigurationName, new EntityHistoryUiSetting { IsEnabled = false } }
              };
          }
  
          var dynamicConfiguration = context.IocResolver.Resolve<IDynamicEntityHistoryConfiguration>();
  
          return new Dictionary<string, object>
          {
              {
                  EntityHistoryHelper.EntityHistoryConfigurationName,
                  new EntityHistoryUiSetting
                  {
                      IsEnabled = true,
                      EnabledEntities = dynamicConfiguration.GetEnabledEntityTypeNames()
                  }
              }
          };
      }
  }
  

  And update AuditLogAppService.GetEntityHistoryObjectTypes() to build its list from the same source instead of intersecting with HostSideTrackedTypes / TenantSideTrackedTypes.

  For the admin screen's "available entities" list, enumerate the EF Core model inside the EntityFrameworkCore project (interface in .Core, implementation in .EntityFrameworkCore):

  var candidates = dbContext.Model.GetEntityTypes()
      .Select(t => t.ClrType)
      .Where(t => t != null && t.IsPublic && EntityHelper.IsEntity(t))
      .Select(t => t.FullName)
      .Distinct()
      .ToList();
  

  Keeping abp.custom.EntityHistory correct in Angular

  abp.custom is populated once at bootstrap: AppPreBootstrap.getUserConfiguration() calls /AbpUserConfiguration/GetAll and merges the result into abp. Because the provider above is now dynamic, every fresh page load / login gets the current list automatically. After an admin toggles an entity, the running SPA still holds the old snapshot either reload the page (window.location.reload()) after saving, or read the list from your own app-service endpoint into a root Angular service.

  Note the casing difference: Angular receives camelCase (abp.custom.EntityHistory.isEnabled, .enabledEntities) while MVC views use PascalCase see roles.component.ts:129.

  Instead of repeating the check in every component, generalize it:

  @Injectable({ providedIn: 'root' })
  export class EntityHistoryService {
      isEnabled(entityTypeFullName: string): boolean {
          const config = (abp as any).custom?.EntityHistory;
          return !!config?.isEnabled && (config.enabledEntities ?? []).indexOf(entityTypeFullName) >= 0;
      }
  }
  

  The good news is that nothing else on the Angular side is entity-specific: the route app/admin/entity-changes/:entityId/:entityTypeFullName, EntityChangesComponent, EntityChangeDetailModalComponent and EntityChangeAppService.GetEntityChangesByEntity all work off the entity type full name, so any dynamically enabled entity gets the History / All changes page for free once your action menu shows the item.

  Things to watch out for

  • The type must be a public CLR class that is part of the EF Core model and an ABP entity. [DisableAuditing] and Configuration.EntityHistory.IgnoredTypes still win over your selector; [Audited] still forces tracking on.
  • Configuration.EntityHistory.IsEnabled is a global master switch evaluated at startup leave it true and do all per-entity decisions in the predicate.
  • Multi-tenancy: the predicate only receives a Type, so per tenant behaviour must come from IAbpSession.TenantId inside your configuration service (as above). ClaimsAbpSession is registered as a singleton in ABP, so injecting IAbpSession into your singleton is safe.
  • Anonymous changes require Configuration.EntityHistory.IsEnabledForAnonymousUsers = true.
  • EntityChange.EntityId is stored JSON serialized that's why AZ's GetEntityChangesByEntity compares both the raw and the quoted id. Keep that in mind if you write your own queries.
  • Storage growth: enabling history on many entities fills AbpEntityChanges / AbpEntityPropertyChanges quickly. Plan a retention/cleanup job.
  • Important caveat: if "dynamically created entities" means schema created at runtime with no CLR type (EAV-style / generated tables), ABP entity history cannot track them it works off the EF Core change tracker. In that case either (a) map them to a generic CLR entity (e.g. DynamicEntityRecord with a JSON payload column changes are then recorded as changes of that column), (b) use ABP's Dynamic Entity Properties, or (c) implement your own IEntityHistoryStore write path. If your types exist at compile time and only the selection is dynamic (which is what your description sounds like), everything above applies directly.

  So no custom audit mechanism needed you keep ABP's EntityChangeSet / EntityChange / EntityPropertyChange tables and the standard Audit Logs → Entity Changes UI, and only swap the static type array for a runtime-backed predicate.

  If you share how your dynamic entities are defined (CLR types vs. runtime schema), we can be more specific.

  Thank you

  Markdown is supported

  Copy & paste or drag & drop images (max 30 MB per image)

  Save Cancel