A similar approach can be found in the ABP Commercial project template.
See the *.EntityFrameworkCore.DbMigrations project
public class MyProjectMigrationsDbContext : AbpDbContext<MyProjectMigrationsDbContext>
{
}
asuming your modules are not connected via project references and those are remote services.
there are 2 approaches: 1- you can sync the users when it needs. 2- you can sync the users once the main user changes 3- you can keep the users identical all the time
option 1 if you don't need cumulative reports based on users. you sync a specific user when a transaction is done on the user.... in this approach you don't need to bulk sync the users. for example; you have a support module and support users are stored in its separate database. when you assign a user an issue, you can sync that user in the support website. to do this, you can make a look up service to retrieve users from your main application (via remote service calls) and once you make assignment, you create a user in support website. the disadvantage of this scenario is, the users will not be identical in both databases. only the users that have been in the transactions will be updated. but it's fast! technically you just need to write a service to retrieve users from your main app, and save it to the support database via repository. Take a look at this example -> https://github.com/abpframework/abp/blob/dev/modules/users/src/Volo.Abp.Users.Domain/Volo/Abp/Users/UserLookupService.cs#L35
option 2 if you want to keep the user information same on both databases all the time, you sync them once (via one time db query), and after that each user update/delete/create will be applied to the other microservice as well. for example, when you create a user in your main app, you raise a distributed event and your microservice subscribes to that event and makes the same operation on its database. The distributed event bus document explains how to create a pub/sub mechanicsm to notify other services about the entity changes. ABP Framework automatically publishes distributed events for create, update and delete operations for an entity once you configure it. This is an efficient way to sync user table. you can use RabbitMQ or Kafka to make this approach robust.
This is a publish event (used in Identity.Pro module) when creating an IdentityUser entity
await DistributedEventBus.PublishAsync(new IdentityUserCreatedEto()
{
Id = user.Id,
Properties =
{
{ "SendConfirmationEmail", input.SendConfirmationEmail.ToString().ToUpper() },
{ "AppName", "MVC" }
}
});
See how to subscribe User events https://docs.abp.io/en/abp/latest/Distributed-Event-Bus#subscribing-to-the-events
option 3 if you want to keep the user records identical all the time without any domain events, you can write a background worker that runs periodically and sync the user table in all your microservice databases. the disadvantage of this approach is, users will be identical when this bg worker runs, the advantage is no frequent HTTP requests and also you avoid HTTP request network failures.
I'm closing this issue as a new issue is reported. if you report this bug as a new question I can refund your question credit @abpVAndy
thank you
no this is not possible. this makes the solution very complex because n modules x n tenants you cannot manage this setup
is this issue enough what you need ? https://github.com/abpframework/abp/issues/9132
by the way if you rename the aspnet-core folder, Suite will probably not work.
revert back that folder name and try again.
on the other hand, if you rename a folder you need to update Suite settings as well. the settings are stored in
%UserProfile%\.abp\suite\appsettings.json
I still couldn't understand what do you mean by offline authentication?
any logs in browser?
skip trimming for now. until we figure out.
This doesn't seem to be implemented as documented. I'll check again and write to you