Hi,
Blazor is production ready & stable. I didn't understand why you thought like that. We will work on the .net 5 when it close to release, so we publish a .net 5 compatible version short time after its final release (we need to prepare for it).
We are not making Blazor only for the free side. We will do it in parallel with the commercial one.
ABP Commercial features are already much more than the free framework, because all the free features are also available to you and ABP commercial already has many more modules/themes/tooling etc.
If creating a microsservice example is not trivial work...
I suppose there is a misunderstanding. I've written "microservice template", not "microservice example". Example is already available (see it) and documented, so you can develop your ms solution by inspiring from it. If you think that it is for free side, no, there is no diference, you can make the same with the ABP Commercial.
But it is an example, nota startup template. Once you can understand this example and the ABP Framework in overall, you can build your own empty microservice solution in a few days or less (create empty microservices, arrange all the environment, gateways, caching, event bus... etc).
Creating a template is something different, on the other hand. We document templates, we develop tooling (CLI/Suite), we prepare CI and other internal environment and do a lot more stuff to create a new solution using the template, generate source code on this new template structure, add modules to the template.
In addition, microservice is a different thing.. We want to add CLI/Suite features to "add a new microservice to the solution" that auto configures all the clients, gateways... to make this ms work. There are a lot more.
So, creating your solution for your own is much more simpler than our work.
I know, every one see his own requirement is the most important one. But we get feedback from thousands of developers. And Blazor is far more most wanted feature than others. Just see the attraction: https://github.com/abpframework/abp/issues/394 Can you show a similar demand about the microservice template?
I don't say microservice template is not important. I've written "This is one of the high priority items in our road map". However, even if we start it today with full energy, you can't expect it to be production ready before ~2 months. So, 3-5 months should be reasonable.
Hi,
This is one of the high priority items in our road map. However, there are some other important items too (like Blazor UI and .NET 5 upgrade). Creating a microservice template is not a trival work. I can't write an exact date, but you can think it like end of 2020 or beginning of 2021 (so, in 3-5 months range).
Closing. Please reopen if you need.
Hi guys,
I didn't read the whole conversation. But, to add a note: We will implement "account linking" feature in the next versions which allows you to have multiple account in the same or different tenant and relate these accounts, so you can switch between account with a single click.
Hi,
Host admin can not see tenant related data. You must login as a tenant user/admin to see the tenant data.
There is a feature in our road map to allow host admins to login as admins of a tenant. The feature is called "user/tenant impersonation" and will be implemented in the next versions (probably in v3.2 or 3.3, because it has a high priority in the list)
Documented: https://docs.abp.io/en/abp/latest/Emailing
Thanks @vrajasekaran for your suggestion. We will create a module development tutorial soon, that will be much better.
what is a best practice for this use case in DDD
If you want to truely implement DDD, you can see my presentation: https://www.youtube.com/watch?v=Yx3Y3-GC9EE It also covers your question.
I don't think creating and maintaining multiple user entities is very practical.
Never do that. Just add "Guid UserId" (a reference) instead of "AppUser User" (navigation property). You then need to make join LINQ if you want to access a user related to a ticket.
However, it is still possible to add a navigation property, but you should understand the migration system that we've created. Unfortunately it is not easy to create such a modolar systems with EF Core, so it has some little difficulties to use. See this document as a reference: https://docs.abp.io/en/abp/latest/Entity-Framework-Core-Migrations
I suggest to not define navigation properties to the AppUser (in DDD, this is not a good practice). However, if you really want it, the explanation mentioned by @alper can be implemented.
If AppUser has ExtraProperties property and AppUserDto doesn't have this property, then AutoMapper throws such a validation error. So, this is an expected case. You can ignore it or create ExtraProperties in your DTO, based on your business requirement.