Can't override EmailSettingProvider at Volo.Abp.Emailing package. #9565

7 Answer(s)

• 

  0

  AI-Bot created 4 months ago

  Support Team ABP Agent

  The EmailSettingProvider class in the ABP Framework is marked as internal, which means it is only accessible within the Volo.Abp.Emailing assembly and cannot be overridden or accessed directly from outside that package.

  This is a deliberate design choice by the ABP team to encapsulate the internal logic of how email settings are provided and managed. Instead of overriding EmailSettingProvider, ABP encourages developers to use the settings system (via ISettingProvider or ISettingManager) to customize or provide email settings. You can define your own settings providers or use the built-in mechanisms to set and retrieve email configuration values.

  If you need to customize email settings, the recommended approach is to use the ABP settings infrastructure, not by overriding EmailSettingProvider directly.

  Sources:

  • ABP Emailing Documentation
  • ABP Settings System

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Save Cancel
• 

  0

  raif created 4 months ago

  Why do we need to write extra code for this EmailSettingProvider when all other SettingProvider in the framework are public and can be overridable with [Dependency(ReplaceServices = true)] attribute?

  Save Cancel
• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  hi

  You can add your MySettingDefinitionProvider to get and change the EmailSettingProvider's SettingDefinition

  Example: Change the default password policy.

  public class ChangeIdentityPasswordPolicySettingDefinitionProvider : SettingDefinitionProvider
  {
      public override void Define(ISettingDefinitionContext context)
      {
          var requireNonAlphanumeric = context.GetOrNull(IdentitySettingNames.Password.RequireNonAlphanumeric);
          if (requireNonAlphanumeric != null)
          {
              requireNonAlphanumeric.DefaultValue = false.ToString();
          }
  
          var requireLowercase = context.GetOrNull(IdentitySettingNames.Password.RequireLowercase);
          if (requireLowercase != null)
          {
              requireLowercase.DefaultValue = false.ToString();
          }
  
          var requireUppercase = context.GetOrNull(IdentitySettingNames.Password.RequireUppercase);
          if (requireUppercase != null)
          {
              requireUppercase.DefaultValue = false.ToString();
          }
  
          var requireDigit = context.GetOrNull(IdentitySettingNames.Password.RequireDigit);
          if (requireDigit != null)
          {
              requireDigit.DefaultValue = false.ToString();
          }
      }
  }
  
  

  Save Cancel
• 

  0

  raif created 4 months ago

  We are already using the approach that you already shared above. But it is not possible to Remove any SettingDefinition in such a use. Isn't it ? If it is can you able to share an example ?

  Simply replacing service with [Dependency(ReplaceServices = true)] attribute we are able to easily make the changes that we want in any SettingProvider for advance scenarios across Framework and Application Modules . We are very grateful for this.

  Can we consider make set access level EmailSettingProvider class to public instead internal.

  We don't understand exactly why you felt the need to make it internal.

  Save Cancel
• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  hi

  But it is not possible to Remove any SettingDefinition in such a use.

  These settings will be used by the email service and the email settings UI page, you cannot remove them.

  They are setting definitions. If you want to replace, you can replace the Email send service.

  We can make this class public, but you generally don't need to replace it. It only defines, rather than implements.

  Thanks.

  Save Cancel
• 

  0

  raif created 4 months ago

  Yes, we are also aware that UI as well as some SettingsAppService may need to change/override. "Generally" we don't need to replace it. I agree

  As said before this is advance case scenario where now, we need to replace. But replace is not possible due to access level.

  If the Volo.Abp.Emaling package was previously used in any Application Modules, we would like to eliminate those settings.

  I created another custom module which get benefits from existing AbpEmailingModule meantime it should also make necessary changes for advance use case requirements.

  This new module including changes Email send service, Templates and etc.

  [DependsOn(
      typeof(AbpEmailingModule),
      typeof(AbpTextTemplatingRazorModule)
  )]
  public class AbpSiemensEmailingModule : AbpModule
  {
      public override void ConfigureServices(ServiceConfigurationContext context)
      {
          Configure<AbpVirtualFileSystemOptions>(options =>
          {
              options.FileSets.AddEmbedded<AbpSiemensEmailingModule>();
          });
  
          Configure<AbpLocalizationOptions>(options =>
          {
              options.Resources
                  .Get<EmailingResource>() // Directly extend an existing resource
                  .AddVirtualJson("/Siemens/Abp/Emailing/Localization");
          });
  
          Configure<AbpExceptionLocalizationOptions>(options =>
          {
              options.MapCodeNamespace("Emailing", typeof(EmailingResource));
          });
      }
  }
  

  Save Cancel
• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  hi

  I will make it public in the next version(9.2.2).

  https://github.com/abpframework/abp/pull/23244/files

  Thanks.

  Save Cancel