Activities of "VMPProgramador"

When a user is created through the admin UI with Send confirmation email enabled, the user is created successfully, but no confirmation email is sent.

However, clicking Verify on the "Confirm user" page sends the email successfully.

Error

When processing the user-created event through RabbitMQ, AccountIdentityUserCreatedEventHandler fails while generating the confirmation token, with the following exception:

A DbContext can only be created inside a unit of work!
   at Volo.Abp.Identity.AbpSingleActiveTokenProvider.GenerateAsync(...)
   at Volo.Abp.Account.Emailing.AccountIdentityUserCreatedEventHandler.HandleEventAsync(...)

The exception occurs before the email is sent, so no confirmation email is generated. RabbitMQ repeatedly retries the failed message.

Change tested

In a test environment, the AccountIdentityUserCreatedEventHandler.cs file in the Volo.Abp.Account.Pro.Public.Application project was modified as follows:

Before:

public async Task HandleEventAsync(IdentityUserCreatedEto eventData)

After:

[UnitOfWork]
public virtual async Task HandleEventAsync(IdentityUserCreatedEto eventData)

The following namespace must also be added:

using Volo.Abp.Uow;

No other changes were made to the method.

After this change, the confirmation email was sent successfully, and the unit of work errors no longer appeared in the logs.

Sources

• Distributed Event Bus – ABP documentation: explains how to use repositories and database operations within distributed event handlers.
• ABP Support: Question 3201: discusses a similar error in a distributed event handler and the missing virtual modifier.
• Unit of Work – ABP documentation: explains unit of work interception and the requirement for virtual methods.

During a normal sign-in, ABP checks whether the user's email has been confirmed and redirects them to the confirmation page if it hasn't. However, when a password change is required, the user is prompted to change their password first. After changing it, the user is signed in and can access the application without being asked to confirm their email. The confirmation check only takes place at the next sign-in.

Steps to reproduce

1. Enable Abp.Identity.SignIn.RequireConfirmedEmail.
2. Create a user with both Send confirmation email and Force password change enabled.
3. Sign in as that user and change the password when prompted.
4. Confirm that the user can access the application without having confirmed their email.
5. Sign out and sign in again. The user is then prompted to confirm their email.

A user without the Chat → Messaging → Searching permission can open a conversation with someone they have never interacted with. However, when they attempt to send the first message, an unhandled Blazor error occurs and the page must be reloaded.

The server rejects the request due to an authorization failure (Forbidden). However, the error is not handled by the client, causing the Chat page to stop working correctly.

Could you please clarify the expected behavior in this scenario?

Stack trace

Blazor (client)

2026-10-16 16:25:08.389 +01:00 [ERR] Unhandled exception in circuit 'CoCj56m3pNdJeVtR9zxKwq3Sm8mkn3TVGSpmr0FnQaA'.
Volo.Abp.Http.Client.AbpRemoteCallException: Forbidden
   at Volo.Abp.Http.Client.ClientProxying.ClientProxyBase`1.ThrowExceptionForResponseAsync(HttpResponseMessage response)
   ...
   at Volo.Chat.Conversations.ConversationClientProxy.SendMessageAsync(SendMessageInput input)
   at Volo.Chat.Blazor.MudBlazor.Pages.Chat.Index.WouAAVFdL()
   at Volo.Chat.Blazor.MudBlazor.Pages.Chat.Index.yMtunRrM39()
   at MudBlazor.MudBaseButton.OnClickHandler(MouseEventArgs ev)

HttpApi.Host (server)

2026-10-16 16:25:08.099 +01:00 [WRN] Exception of type 'Volo.Abp.Authorization.AbpAuthorizationException' was thrown.
Code: Volo.Authorization:010004
Message: Authorization failed! Given requirement has not granted for given resource: {ResourceName}
Volo.Abp.Authorization.AbpAuthorizationException: Exception of type 'Volo.Abp.Authorization.AbpAuthorizationException' was thrown.
   at Volo.Chat.Conversations.ConversationAppService.SendMessageAsync(SendMessageInput input)
   ...

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

1. Create a permission profile with only Conversation → Messages enabled.
2. Sign in with a user assigned to that profile and navigate to /Chat.
3. Confirm that access is denied.
4. Grant the profile the Setting Management permission as well and repeat the test.
5. 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.

When typing a message in ChatClientChat, pressing Shift+Enter does not insert a new line. The message field behaves as a single-line input instead of allowing multiple lines.

Cause

The AutoGrow property no longer exists as of MudBlazor 9.0.0, which replaced it with InputSizing.Auto.

Symptom

• AutoGrow is ignored as a parameter and ends up as a plain HTML attribute (autogrow="").
• The field renders as a single-line input, not as a textarea.

Steps to reproduce

1. Open any page in the application.
2. Use the side menu filter to search for a different menu item.
3. Click the filtered item to navigate to its page.

Expected behavior

The menu should continue to display only the items matching the active filter.

Actual behavior

After navigating to the selected page, the menu item for the page visited previously reappears, even though it does not match the filter. All other non-matching items remain hidden.

This happens consistently when navigating between different menu items.