To customize the navigation header/sidebar in your ABP Angular application as shown in your image, and to control dark mode/light mode for custom components, follow these steps:
Custom Sidebar/Nav Header Layout
SideNavComponent) and design the HTML to match your desired layout, including section headers (like "GOVERNANCE", "AUTOMATION") and menu items with icons.<ul class="custom-sidenav">
<li>
<span class="sidenav-section">GOVERNANCE</span>
</li>
<li routerLink="/applications" routerLinkActive="active">
<i class="icon-applications"></i> Applications
</li>
<li routerLink="/entitlements">
<i class="icon-entitlements"></i> Entitlements
</li>
<!-- ...other items... -->
<li>
<span class="sidenav-section">AUTOMATION</span>
</li>
<li routerLink="/lifecycle-workflow">
<i class="icon-lifecycle"></i> Lifecycle Workflow
</li>
<!-- ... -->
</ul>
Replace the Default Sidebar
Dark Mode / Light Mode Control for Custom Components
import { ThemeService, StyleNames, lightTheme, darkTheme } from '@volosoft/ngx-lepton-x';
export class AppComponent {
constructor(private themeService: ThemeService) {}
setLightMode() {
this.themeService.setTheme(lightTheme);
}
setDarkMode() {
this.themeService.setTheme(darkTheme);
}
}
Force a Default Theme (e.g., Always Light)
AppComponent or provide it in your app.module.ts as shown in the official support answer:
import { LPX_THEMES, LPX_THEME_STYLES_DEFAULTS } from "@volosoft/ngx-lepton-x";
const defaultThemes = [...LPX_THEME_STYLES_DEFAULTS].map((theme) => {
const defaultTheme = theme.styleName === "light";
return { ...theme, defaultTheme };
});
{
provide: LPX_THEMES,
useValue: defaultThemes
}
For More Details
You can now fully control both the layout and the theme (dark/light) for your custom components in ABP Angular.
Sources:
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.
The error The AuthorizationPolicy named: 'CustomerService.Customers' was not found. indicates that you are using ASP.NET Core's policy-based authorization, but you have not registered a policy named CustomerService.Customers in your application's authorization configuration.
In ABP Blazor applications, permissions are typically checked using the ABP permission system, not by defining custom ASP.NET Core authorization policies for each permission. The correct way to check for a permission in a Blazor component is to use the @attribute [Authorize] without a policy name, or to use the AbpAuthorizeView component for permission checks.
To check for a specific permission, use the ABP permission name in the AbpAuthorizeView component, like this:
@page "/"
@using Volo.Abp.AspNetCore.Components.Authorization
@attribute [Authorize] <!-- This just requires authentication -->
<AbpAuthorizeView Permission="CustomerService.Customers.Create">
<p>You can only see this if you have the 'CustomerService.Customers.Create' permission.</p>
</AbpAuthorizeView>
AuthorizeView, you must define the policy in your Startup.cs or Program.cs:services.AddAuthorization(options =>
{
options.AddPolicy("CustomerService.Customers", policy =>
policy.RequireClaim("Permission", "CustomerService.Customers"));
});
But this is not the recommended ABP way.
Sources:
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.
To customize the LeptonX Theme in your ABP Blazor application to support Blazorise RouterTabs in the main content area (while keeping the sidebar, menu, and toolbar unchanged), follow these steps:
Create a Custom Layout Component
/Themes/Custom/).Replace the Content Area with RouterTabs
In your custom layout, locate the section where the main content is rendered (usually with @Body or a similar placeholder).
Replace this with the Blazorise <RouterTabs> component, and configure it to manage your routes as tabs.
Example:
@using Blazorise
@using Blazorise.Router
<RouterTabs>
<TabPanel Title="Home" Url="/">
<!-- Home content or component -->
</TabPanel>
<TabPanel Title="Privacy Policy" Url="/privacy-policy">
<!-- Privacy Policy content or component -->
</TabPanel>
<!-- Add more TabPanels as needed -->
</RouterTabs>
Register and Use Your Custom Layout
_Imports.razor or relevant routing configuration to use your custom layout for the pages you want to support tabbed navigation.@layout CustomLeptonXLayout
Keep the Rest of the Layout Intact
Optional: Make the Layout Replaceable
Tips:
This approach allows you to introduce tabbed navigation in the content area while keeping the rest of the LeptonX theme unchanged.
Sources:
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.
this.uppy.close() in ngOnDestroy() without checking if this.uppy is defined. This results in a TypeError when this.uppy is undefined, which can happen on a page reload.ngOnDestroy() method in your UploadService as follows:
ngOnDestroy() {
this.uppy?.close();
this.subscriptionService.closeAll();
}
?.) to ensure close() is only called if this.uppy is defined, preventing the crash.This is a valid bug report and your suggested fix is correct. Please consider submitting this as an issue or pull request to the ABP Framework team if you have not already done so.
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.
To run the AuthServer locally without requiring a certificate, you can disable the HTTPS metadata requirement in your configuration. This allows the server to accept HTTP requests and operate without a certificate for development purposes.
In your appsettings.json (AuthServer project), set:
"AuthServer": {
"Authority": "http://localhost:PORT",
"RequireHttpsMetadata": "false"
}
In your AuthServer's ConfigureServices method, add:
if (!Convert.ToBoolean(configuration["AuthServer:RequireHttpsMetadata"]))
{
Configure<OpenIddictServerAspNetCoreOptions>(options =>
{
options.DisableTransportSecurityRequirement = true;
});
}
This configuration disables the HTTPS requirement, allowing you to run AuthServer locally without a certificate.
Sources:
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.
Yes, you can run the AuthServer locally with a hard-coded certificate so that certificates do not need to be regenerated every time. Instead of using the development certificate generation method, you can provide a persistent PFX certificate file (e.g., openiddict.pfx) and its password directly in your configuration. This approach works for both local development and production scenarios.
Here’s how you can configure your AuthServer to use a specific certificate file:
public override void PreConfigureServices(ServiceConfigurationContext context)
{
var hostingEnvironment = context.Services.GetHostingEnvironment();
PreConfigure<AbpOpenIddictAspNetCoreOptions>(options =>
{
options.AddDevelopmentEncryptionAndSigningCertificate = false;
});
PreConfigure<OpenIddictServerBuilder>(serverBuilder =>
{
serverBuilder.AddProductionEncryptionAndSigningCertificate(
"openiddict.pfx", // Path to your persistent certificate
"YourCertificatePassword" // Certificate password
);
});
}
This method is supported and recommended for scenarios where you want consistent credentials across restarts or deployments.
Sources:
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.
To resolve this, follow these steps:
Expose Integration Services in the Provider Microservice
public override void ConfigureServices(ServiceConfigurationContext context)
{
Configure<AbpAspNetCoreMvcOptions>(options =>
{
options.ExposeIntegrationServices = true;
});
}
Reference the HttpApi.Client Package in the Consumer Microservice
HttpApi.Client project of the provider microservice.Configure the Remote Service URL
appsettings.json, set the base URL for the remote service:
"RemoteServices": {
"AbcEmployeeService": {
"BaseUrl": "https://localhost:PORT"
}
}
AbcEmployeeService) should match the remote service name used in your proxy registration.Register the Client Proxy
context.Services.AddStaticHttpClientProxies(
typeof(Abc.EmployeeService.Application.Contracts.EmployeeServiceApplicationContractsModule).Assembly,
"AbcEmployeeService"
);
Use the Integration Service Interface
IEmployeeIntegrationService in your consumer microservice as needed.Restart All Services
If you follow these steps, the error should be resolved and the integration service proxy will be available for HTTP calls between your microservices.
Sources:
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.
In ABP microservice solutions, feature values are cached for performance. When you update a feature value (e.g., via the Features modal for a tenant), the cache in the relevant microservice is not immediately invalidated. This means your custom microservice may continue to use the old value until the cache expires or is refreshed.
By default, the cache duration is set internally and may not be short enough for immediate reflection of changes. Logging out/in or waiting may not help if the cache is still valid.
To ensure the feature value is updated immediately after a change, you need to manually clear or refresh the feature value cache in your microservice. This is a common scenario in distributed/microservice setups.
You can clear the feature cache by injecting and using the IFeatureValueStore or the distributed cache service for features, and removing the relevant cache entry when a feature is changed. Alternatively, you can reduce the cache duration in your configuration, but this may impact performance.
For more details and the official approach, see the documentation below.
Sources:
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.
The issue you are experiencing is a common one when using custom URI schemes (like portalsystem://) for OAuth redirect URIs in ABP with React Native/Expo, especially when moving from Expo Go (development) to a built APK (production). In Expo Go, deep linking is handled differently than in a standalone build, which can cause redirect issues.
Here are the steps to resolve the problem:
Check Redirect URI Registration in ABP/IdentityServer:
portalsystem://AndroidManifest Configuration:
scheme property in app.json (which you have set to portalsystem).AndroidManifest.xml, but for managed workflow, Expo handles this if the scheme is set.App.json/Build Configuration:
app.json looks correct with "scheme": "portalsystem".Expo AuthSession/Redirect URI:
AuthSession.makeRedirectUri({ useProxy: false }) to generate the redirect URI. This should match portalsystem://.const redirectUri = AuthSession.makeRedirectUri({ useProxy: false });
// Should output: portalsystem://
Production Build Differences:
Check for Typos and Consistency:
Testing:
adb logcat (for Android) to check if the intent is being received by your app.ABP/IdentityServer Logs:
Expo Documentation:
If you follow these steps and ensure all redirect URIs and schemes are consistent, the OAuth flow should work in your built APK as it does in Expo Go.
Sources:
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.
To ensure that the admin role does not regain permissions after running the migrator multiple times, you need to override the default ABP behavior that grants all permissions to the admin role during data seeding. By default, ABP's PermissionDataSeedContributor grants all permissions to the admin role every time seeding runs, which is why your manual removals are overwritten on each migration.
Solution:
You should replace the default PermissionDataSeedContributor with your own implementation that only grants the permissions you want. Here’s how to do it:
Create a Custom PermissionDataSeedContributor:
Replace the default contributor by using the Dependency(ReplaceServices = true) attribute and implement your own logic for seeding admin permissions.
[Dependency(ReplaceServices = true)]
[ExposeServices(typeof(PermissionDataSeedContributor), typeof(IDataSeedContributor))]
public class MyPermissionDataSeedContributor : PermissionDataSeedContributor
{
public MyPermissionDataSeedContributor(
IPermissionDefinitionManager permissionDefinitionManager,
IPermissionDataSeeder permissionDataSeeder,
ICurrentTenant currentTenant)
: base(permissionDefinitionManager, permissionDataSeeder, currentTenant)
{
}
public override Task SeedAsync(DataSeedContext context)
{
var multiTenancySide = CurrentTenant.GetMultiTenancySide();
var permissionNames = PermissionDefinitionManager
.GetPermissions()
.Where(p => p.MultiTenancySide.HasFlag(multiTenancySide))
.Where(p => !p.Providers.Any() || p.Providers.Contains(RolePermissionValueProvider.ProviderName))
.Select(p => p.Name)
.Where(x => /* filter only the permissions you want admin to have */)
.ToArray();
return PermissionDataSeeder.SeedAsync(
RolePermissionValueProvider.ProviderName,
"admin",
permissionNames,
context?.TenantId
);
}
}
.Where(x => ...) with your logic to select only the permissions you want the admin role to have.Register Your Contributor: Make sure your custom contributor is registered and the default one is replaced. This is handled by the attributes above.
Remove Manual Permission Removal: You no longer need to manually remove permissions from the admin role in your seeder, as the admin will only be granted the permissions you specify.
Why this works:
ABP’s default seeding always grants all permissions to the admin role. By replacing the default contributor, you control exactly which permissions are seeded for admin, and your changes will persist across migrations and application restarts.
References:
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.
