Activities of "mgurer"

Thanks.

I updated my base class properties as;

public string EntityName { get; protected set; }
public string ProviderName { get => AbpEfCoreConsts.ProviderName; }

  public virtual void SetEntityName(string entityName)
  {
      EntityName = entityName;
  }

This will work I guess.

Thanks.

• Steps to reproduce the issue: Hello,

I noticed that Abp’s IRepository interface has been updated and now includes two new properties: EntityName and ProviderName.

In my project, I have the following base repository class:

public abstract class ReadOnlyBasicRepositoryBase<TEntity>() : IReadOnlyBasicRepository<TEntity>, IRepository, IServiceProviderAccessor, IUnitOfWorkEnabled where TEntity : class, IEntity { ... }

After the interface change, I had to add the following properties to my implementation:

public string EntityName { get; set; } public string ProviderName { get; }

However, I’m unsure at which point in the repository lifecycle these properties are expected to be initialized. Since I couldn’t find documentation related to this update, I’m not certain how or where these new fields should be populated.

Could you please provide some guidance on the purpose of these properties and how they should be initialized?

Thank you.

• Exception message and full stack trace: Hello, i am getting so many support emails. Email ttile is "Reminder: Please select an answer for question #10132". I am getting emails on every 30 minutes. When I click the link in the content, i get 404. Can you please check the issue?
• Steps to reproduce the issue:

• Exception message and full stack trace: Hello, I am trying to upgrade my solution to 10.0.0. Volo.Abp.EntityFrameworkCore.PostgreSql package references to Npgsql.EntityFrameworkCore.PostgreSQL version 10.0.0-rc1. This leads to build warnings. I guess your internal package references needs to be updated.
• Steps to reproduce the issue:

Thanks.

Your initial implementation for claim destinations works correctly.

This approach increases the token size. In Blazor UI applications, larger authentication cookies can lead to network-level issues due to maximum cookie size limitations. To address this, we've implemented a workaround using IdentitySessionManager to store the auth cookie content in the session instead.

Hi,

I am using Blazor Server.

I will try your recommendation.

Thanks

Hello,

I'm working with the ABP Framework using the Blazor UI and microservice template with PostgreSQL. After making some modifications to the default startup templates, I've encountered an issue with user claims access.

Problem Description:

I have successfully inserted custom claims into the AbpUserClaims table. These claims are accessible and readable from the API projects. However, the Blazor UI project cannot access these database-stored claims. I have disabled the DynamicClaims feature in my project. Analysis: I suspect the Blazor UI project lacks direct access to the Identity database, which prevents it from retrieving the stored claims.

Current Workaround: I've created a dedicated API service method that returns the claims values to the UI project, which works but feels like a temporary solution.

Question: Is there a more integrated or "natural" approach within the ABP Framework to resolve this claims access issue between the Blazor UI and the Identity database?

Any guidance or suggestions would be greatly appreciated.

Best regards, Murat

Well my problem was about not being able to debug the validation process. But your suggestion gave me a hint. I added following line to my validator and problem solved.

public override string FormatErrorMessage(string name)
{
    return string.Format(PspResource.RequiredAttribute_ValidationError, name);
}    

Thanks.

Hello, I have created a custom data annotition attribute. Below is the code;

[AttributeUsage(AttributeTargets.Property | AttributeTargets.Field | AttributeTargets.Parameter,
    AllowMultiple = false)]
public class PspRequiredAttribute : RequiredAttribute
{
    public PspRequiredAttribute()
    {
        ErrorMessageResourceName = nameof(PspResource.RequiredAttribute_ValidationError);
        ErrorMessageResourceType = typeof(PspResource);
    }
}

Here is a sample create dto for testing;

public class ProductCreateDto
{
    [PspRequired]
    [PspStringLength(ProductConsts.NameMaxLength)]
    [Display(Name = "Product_Name", ResourceType = typeof(ProductServiceResource))]
    public string Name { get; set; }
}

On blazor pages, after applying new PspRequired attribute, blazor forms automatically gets localized for validation messages. Otherwise, using classic Required attribute, blazor ui localizations fails, and only english localizations are shown for models ui validation messages.

But when I send this dto to create method of service, I get an error of this type: System.InvalidOperationException, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e

When I use standard Required attribute, no error occcurs.

I placed breakpoints on conrollers create action but no breakpoint hits but error is returned. I can not figure out what is going on because no breakpoint hits.

How can I use my own anotation attributes as in the example.

Tnx Murat

• ABP Framework version: v9.0.0
• UI Type: Blazor Server
• Database System: EF Core (PostgreSQL, etc..)
• Tiered (for MVC) or Auth Server Separated (for Angular): yes/no
• Exception message and full stack trace:
• Steps to reproduce the issue:

Hello.

I have just updated my code base to use couchbase as distributed cache and lock provider.

Everything goes fine.

During my tests, I have noticed a behavior about distributed locks for BackgroundJobWorker.

The class implementation uses constant "AbpBackgroundJobWorker" string as lock key.

I have maybe 50 microservices and each microservice has their own database and each database has own "AbpBackgroundJobs" table.

Each microservice runs this BackgroundJobWorker periodically (a bit often) and on every call the lock is activated using same lock key ("AbpBackgroundJobWorker"). I use Volo.Abp.BackgroundJobs.EntityFrameworkCore library to store job queue on database.

Since microservices has their own separate databases, blocking microservices with same lock-key seems to me a little bit inefficient. This blockage goes up depending on the number of microservices.

I suggest appending the database name as a suffix to the lock key or add an option to set this key separately for each microservice so that microservices do not block each other.

I would like to alter this implementation according to my suggestion, but I like to ensure that I do not miss any logic that made you use same lock-key.

Do you have any comment about this issue?

Thanks. Murat