The problem
A user with only the Conversation → Messages permission cannot access the Chat page and is redirected to the Access Denied page.
However, granting the Conversation → Setting Management permission as well allows the page to work normally. This is unexpected, as managing settings should be independent of using Chat.
Steps to reproduce
- Create a permission profile with only Conversation → Messages enabled.
- Sign in with a user assigned to that profile and navigate to
/Chat. - Confirm that access is denied.
- Grant the profile the Setting Management permission as well and repeat the test.
- Confirm that the page now opens normally.
Analysis
During testing, we found that the Chat page retrieves the module's settings when it initializes, even when the user only needs to access their messages.
This request appears to be the cause of the issue. The OnInitializedAsync method in Index.razor.cs (in Volo.Chat.Blazor.MudBlazor) calls SettingsAppService.GetAsync, which requires the Chat.SettingManagement permission at class level. As a result, users without this permission cannot complete the page initialization.
2 Answer(s)
-
0
This behavior is caused by authorization on the Chat settings application service being enforced at class level (requires
Chat.SettingManagement). Since the Chat page initializes by callingSettingsAppService.GetAsync, the whole page fails to initialize for users who only haveChat.Messaging(Conversation → Messages) and they get redirected to Access Denied.In ABP/Blazor, the most practical workaround (without modifying the commercial module source) is to override/replace the Chat page component and avoid calling the settings endpoint unless the user has the Setting Management permission.
Recommended fix (UI-side override)
- Override the Chat page/component from
Volo.Chat.Blazor.MudBlazor(same technique used to override built-in module UI components). - In your overridden
OnInitializedAsync, check permission before callingSettingsAppService.GetAsync:- If user has
Chat.SettingManagement: load settings (admin UI behavior) - Else: skip settings load and proceed with messaging UI using defaults
- If user has
Example pattern (conceptual):
public override async Task OnInitializedAsync() { // ... other init if (await AuthorizationService.IsGrantedAsync("Chat.SettingManagement")) { Settings = await SettingsAppService.GetAsync(); } // continue loading conversations/messages }This keeps messaging access independent from settings management while preserving settings features for authorized users.
Alternative fix (service-side, if you own/extend backend)
If you have a customization point (e.g., you can replace the settings app service), provide a read-only settings endpoint that is authorized with
Chat.Messaging(or no permission if settings are not sensitive), and make the UI call that endpoint instead. However, this requires backend customization/replacement and is typically more invasive than the UI override.
Sources
- ABP Blazor UI overriding approach (used to replace module pages/components): https://docs.abp.io/en/abp/latest/UI/Blazor/Customization-Overriding-Components
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.
Markdown supported.Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post) -
0
Hi,
The chat page reads the chat settings when it loads, but that endpoint requires the
Chat.SettingManagementpermission.You can use this workaround for now. Add this class to your
Applicationproject. It allows users with either theChat.Messagingor theChat.SettingManagementpermission to read the settings. Updating the settings still requiresChat.SettingManagement.using System.Threading.Tasks; using Microsoft.AspNetCore.Authorization; using Volo.Abp.Authorization; using Volo.Abp.DependencyInjection; using Volo.Abp.SettingManagement; using Volo.Chat.Authorization; using Volo.Chat.Settings; namespace YourProjectName.Chat; [Dependency(ReplaceServices = true)] [ExposeServices(typeof(ISettingsAppService), typeof(SettingsAppService))] public class MyChatSettingsAppService : SettingsAppService, ISettingsAppService { public MyChatSettingsAppService(ISettingManager settingManager) : base(settingManager) { } [AllowAnonymous] public new async Task<ChatSettingsDto> GetAsync() { if (!await AuthorizationService.IsGrantedAnyAsync(ChatPermissions.Messaging, ChatPermissions.SettingManagement)) { throw new AbpAuthorizationException(); } return await base.GetAsync(); } }After that, users with only the Messaging permission can open the chat page.
We'll fix this in the next patch release. Your ticket has been refunded.
Thanks
Markdown supported.Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)