mirror of https://github.com/abpframework/abp.git
Enis Necipoglu
3 years ago
committed by
GitHub
GitHub
325 changed files with 5428 additions and 1616 deletions
@ -1,5 +1,6 @@ |
|||
{ |
|||
"culture": "zh-Hans", |
|||
"texts": { |
|||
"Buy": "购买" |
|||
} |
|||
} |
|||
@ -0,0 +1,37 @@ |
|||
# Migrating from MS-SQL to Postgresql |
|||
|
|||
 |
|||
|
|||
## Introduction |
|||
|
|||
Database migration is a common practice for organizations that want to move from one database system to another. This can be for a variety of reasons, including cost, performance, and features. In this article, we will discuss the process of migrating a database from MS-SQL to PostgreSQL, the challenges that may arise during the migration, and how to overcome them. And we recently moved the main database of https://abp.io platform from MS-SQL to PostgreSQL. |
|||
|
|||
In our case, we decided to switch our database from Microsoft SQL Server (MS-SQL) to PostgreSQL because we wanted to move our on-premise platform to Azure. We’ve also found out that the cost of the license for MS-SQL on Azure was significantly higher than PostgreSQL. After conducting a cost-benefit analysis, we decided to migrate our database to PostgreSQL to save costs. |
|||
|
|||
Before migrating to Azure, we decided to switch our database from MS-SQL to PostgreSQL on-premise first. This gave us the opportunity to test and fine-tune the migration process before making the final switch to Azure. |
|||
|
|||
## Challenges |
|||
|
|||
Despite using a third-party tool(DBConvert for MySQL & PostgreSQL) for the migration, we faced three main problems when exporting data to PostgreSQL. Firstly, some tables with plain text had utf-8 encoding problems. We overcame this problem by dump-restoring these tables. |
|||
|
|||
 |
|||
|
|||
|
|||
Secondly, our database had to be case-insensitive, but PostgreSQL does not have this as a default configuration. We handled it using `citext` with the ABP migration service. |
|||
|
|||
 |
|||
 |
|||
 |
|||
|
|||
|
|||
While everything was proceeding very smooth, we faced one last problem: importing binary data, such as the content of the NuGet packages. It was hard to understand that the binaries of the NuGet packages were different. Our paid commercial NuGet packages are being stored as binary data in the database. Therefore, it was the most compelling part of this migration to transfer the NuGet packages. Fortunately, we overcame the binary error. And we decided to write a custom .NET tool to move only the binary data from MS-SQL to PostgreSQL, thanks to the ABP Core team! |
|||
|
|||
|
|||
## Conclusion |
|||
|
|||
One of the benefits of using PostgreSQL is the low license costs of the Azure platform. As the main contributors of ABP, we also use ABP Framework under the hood of our abp.io websites, we could easily switch to PostgreSQL. For those who want to switch their ABP project to PostgreSQL, check out [docs.abp.io/en/abp/latest/Entity-Framework-Core-PostgreSQL](https://docs.abp.io/en/abp/latest/Entity-Framework-Core-PostgreSQL). We had not used any MS-SQL specific function, therefore there was no need to make any changes in the repository classes. This means that the applications that were previously using MS-SQL can seamlessly switch to PostgreSQL without any modifications. |
|||
|
|||
Thanks to the flexibility of ABP, it has [PostgreSQL package](https://www.nuget.org/packages/Volo.Abp.EntityFrameworkCore.PostgreSql) which is 100% compatible with PostgreSQL. This helped us to make this migration very smooth and seamless. |
|||
|
|||
In conclusion, migrating a database from MS-SQL to PostgreSQL can be challenging, but it can bring significant cost savings in the long run. By testing and fine-tuning the migration process before making the final switch, we were able to overcome the challenges we’d faced during the migration process. Thanks to the flexibility of ABP, we were able to make the transition with minimal code changes. Also we didn't see any big performance differences between MS-SQL and PostgreSQL. |
|||
|
|||
|
After Width: | Height: | Size: 63 KiB |
|
After Width: | Height: | Size: 73 KiB |
|
After Width: | Height: | Size: 39 KiB |
|
After Width: | Height: | Size: 410 KiB |
|
After Width: | Height: | Size: 5.7 KiB |
|
After Width: | Height: | Size: 4.5 KiB |
|
After Width: | Height: | Size: 32 KiB |
@ -0,0 +1,49 @@ |
|||
|
|||
# On-Prem to Azure: Migration of abp.io Platform to Azure |
|||
|
|||
|
|||
 |
|||
|
|||
Migrating a Kubernetes platform with a database from our own dedicated servers to Azure can be a compelling task, but it can be a necessary one to take advantage of the benefits that the cloud service offers. In this post, we will discuss the reasons for migrating from a on-premise platform to Azure, the steps taken to create and configure the [abp.io platform](https://abp.io) on Azure, and the benefits gained from the migration. |
|||
|
|||
### On-Premise Server: The old platform |
|||
|
|||
There were several reasons for migrating from the old on-premise platform to Azure. First, the Kubernetes cluster and the database were on the same Windows server. Additionally, the Linux virtual machines in Kubernetes were on the Windows server and had limited resources. Furthermore, the Kubernetes maintenance was quite challenging, which was another reason for the migration. |
|||
|
|||
### Reasons for Moving to Azure: The new platform |
|||
|
|||
The decision to move to the cloud was made to eliminate the disadvantages of the old platform. The migration to Azure meant that the resources would be independent of each other but faster in terms of communicating with each other. The platform would also take advantage of cloud security and availability. The managed Kubernetes service that Azure offers comes with autoscaling and loadbalancing, which makes the platform more reliable. Finally, the migration to Azure would provide a better quality service to global customers and the community. |
|||
|
|||
### Before Moving to Azure |
|||
|
|||
Before migrating to Azure, we decided to switch our database from MS-SQL to PostgreSQL on-premise first. This gave us the opportunity to test and fine-tune the migration process before making the final switch to Azure.You can check the details of database migration from this article [Migrating from MS-SQL to Postgresql](https://community.abp.io/posts/migrating-from-mssql-to-postgresql-lbi5anlv). |
|||
|
|||
The platform was tested in a staging environment created on Azure with the same resources as the production environment. The staging environment was used to test and optimize the migration process, including the migration of data from the old platform to Azure, which was tested multiple times to ensure success. |
|||
|
|||
### Creating and Configuring the abp.io Platform on Azure |
|||
|
|||
Several steps were taken to create and configure the abp.io platform on Azure. [Terraform](https://www.terraform.io/) was used to create the infrastructure (VM, Private Network, AKS, Postgresql Flexible Server...), while [Ansible](https://www.ansible.com/) was used to configure the Azure resources like Terraform, Helm, Kubectl, Docker, VPN, Redis, Prometheus, Grafana, ElasticSearch, Kibana and so on.... Azure DevOps pipelines and release were used for AKS deployment. The most time-consuming part in this process was to prepare, test and optimize the terraform and ansible settings files. |
|||
|
|||
To access our platform, which is configured on a private network in Azure, we require a VPN connection. To enable this, we have installed [Wireguard](https://www.wireguard.com/) - an open source VPN service - by creating a virtual machine using Terraform and configuring it with Ansible in Azure. This approach has made the process efficient and streamlined. |
|||
|
|||
 |
|||
|
|||
The most important step was to transfer the data in both the database and Kubernetes of the volumes. rsync (remote sync commands) were used to transfer the data from Kubernetes volumes to Azure NFS through the VPN machine. Additionally, `pg_dump` and `pg_restore` were used to transfer the PostgreSQL database through the machine with VPN. |
|||
|
|||
Before the production environment, the data migration was tested many times for the staging environment. We estimated this migration to take max 1.5 hours. The ABP community was informed that there may be interruptions during the hours designated for the transition to Azure. To inform our customers and community, we created a status page before this migration. The new status page is [status.abp.io](https://status.abp.io). From now on we wil make all the infrastructural announcements on [status.abp.io](https://status.abp.io). We used [Upptime](https://upptime.js.org) which is an open-source uptime monitor and status page provider. During the migration of the production environment, the websites and databases were still up and running. After the data transfer, the only remaining step was to direct the traffic of the already standing abp.io sites to the Azure Kubernetes service via Cloudflare. |
|||
|
|||
We would like to happily state that **we were offline for only 4 minutes** during this transition. |
|||
|
|||
 |
|||
|
|||
|
|||
### Benefits of Moving to Azure |
|||
|
|||
The migration to Azure resulted in several benefits. The platform is now more reliable, scalable, secure, solid with built-in one-click backup and recovery capabilities for abp.io. Additionally, the critical resources are in a private network, making them more secure than the old environment. When we initially compared the speed of our abp.io sites before and after migrating to Azure, we were pleasantly surprised by the significant improvement in performance. To be honest, we did not expect such a speed increase. |
|||
|
|||
 |
|||
|
|||
In conclusion, migrating a Kubernetes platform with a database from on-premise to Azure is a complex process that requires careful planning and execution. However, the benefits gained from the migration make the process worthwhile. By moving to Azure, the abp.io platform now has a more reliable and available infrastructure that is more secure than the old environment. The migration also resulted in significant improvements in connection speeds, which ultimately provides a better service to global customers and the community. |
|||
|
|||
|
|||
|
|||
|
After Width: | Height: | Size: 136 KiB |
|
After Width: | Height: | Size: 142 KiB |
|
After Width: | Height: | Size: 336 KiB |
|
After Width: | Height: | Size: 142 KiB |
@ -0,0 +1,44 @@ |
|||
## Streamline Localization in Your ABP Project |
|||
|
|||
Making localization changes to an ABP project can be a daunting task, especially if you're dealing with multiple languages and translations. During development, it's easy to overlook some changes and that leads to inconsistencies across different languages. Fortunately, I have developed a tool that can help streamline the localization process and ensure consistency across different languages. |
|||
|
|||
The tool is a console application that uses JSON files to manage localization keys and their translations. It addresses three common scenarios that can arise during localization: |
|||
|
|||
|
|||
1. When the argument count of a key changes, it can be difficult to update the translations for all languages. My tool solves this problem by scanning all JSON files in the project folder and identifying any keys that have mismatched argument counts. It then offers two options to the user: delete the mismatched translations or export them as a JSON file for manual editing. |
|||
|
|||
2. When a new key is added to the project, forgetting to add its translations to all the other languages is easy. My tool helps to avoid this issue by scanning the default language's JSON file and identifying any keys that don't have translations in other languages. It then exports these keys as a JSON file that can be used to add missing translations. |
|||
|
|||
3. When a key's name is changed, it's important to update its translations in all the other languages. My tool makes this task simple by scanning all the JSON files in the project folder and updating any translations of the old key name with the new one. |
|||
|
|||
The tool also includes an export feature that allows users to modify translations outside of the application and import them back into the JSON files. |
|||
|
|||
## How it Helps |
|||
|
|||
With my Localization Key Synchronizer tool, you can perform complex localization changes more quickly and easily than by manually sifting through files and making changes one-by-one. This can save you significant time and effort, especially if you're working with a large number of languages or translations. |
|||
|
|||
## How it Works |
|||
|
|||
When you run the Localization Key Synchronizer tool, it presents you with three options: |
|||
|
|||
1. Find Asynchronous Keys |
|||
2. Apply Changes in the Exported File |
|||
3. Replace Keys |
|||
|
|||
If you select "Find Asynchronous Keys," the tool prompts you to enter the default language path. Once you've entered the path, the tool displays all of the JSON files in the same folder as a multi-select list. After selecting one or more files, you are asked whether you want to find keys that do not match the number of arguments, missing keys, or both. If you select "Missing Keys," the tool prompts you to enter the absolute path to export the missing keys. After you've entered the path, the export process starts, and the tool closes. |
|||
|
|||
 |
|||
|
|||
If you select "Apply Changes in the Exported File" at the main menu, the tool prompts you to enter the path to the exported file. After you've entered the path, the import process starts, and the tool closes. |
|||
|
|||
 |
|||
|
|||
If you select "Replace Keys," the tool prompts you to enter the localization folder path, the old key, the new key, and the JSON files to apply the changes to. Once you've entered all the required information and made your selections, the tool performs the replacements and closes. |
|||
|
|||
 |
|||
|
|||
## Conclusion |
|||
|
|||
If you're struggling to manage localization changes in an ABP project, give my Localization Key Synchronizer tool a try. It can help streamline your workflow and make the process much more manageable. You can find the tool on [GitHub](https://github.com/abpframework/abp/tree/dev/tools/localization-key-synchronizer). |
|||
|
|||
To use the tool, simply run the console application and follow the prompts. It's a user-friendly solution that helps to ensure localization consistency in your ABP project. Give it a try and let me know what you think! |
|||
|
After Width: | Height: | Size: 3.1 MiB |
|
After Width: | Height: | Size: 3.0 MiB |
|
After Width: | Height: | Size: 2.7 MiB |
@ -0,0 +1,37 @@ |
|||
# Migrating from MS-SQL to Postgresql |
|||
|
|||
 |
|||
|
|||
## Introduction |
|||
|
|||
Database migration is a common practice for organizations that want to move from one database system to another. This can be for a variety of reasons, including cost, performance, and features. In this article, we will discuss the process of migrating a database from MS-SQL to PostgreSQL, the challenges that may arise during the migration, and how to overcome them. And we recently moved the main database of https://abp.io platform from MS-SQL to PostgreSQL. |
|||
|
|||
In our case, we decided to switch our database from Microsoft SQL Server (MS-SQL) to PostgreSQL because we wanted to move our on-premise platform to Azure. We’ve also found out that the cost of the license for MS-SQL on Azure was significantly higher than PostgreSQL. After conducting a cost-benefit analysis, we decided to migrate our database to PostgreSQL to save costs. |
|||
|
|||
Before migrating to Azure, we decided to switch our database from MS-SQL to PostgreSQL on-premise first. This gave us the opportunity to test and fine-tune the migration process before making the final switch to Azure. |
|||
|
|||
## Challenges |
|||
|
|||
Despite using a third-party tool(DBConvert for MySQL & PostgreSQL) for the migration, we faced three main problems when exporting data to PostgreSQL. Firstly, some tables with plain text had utf-8 encoding problems. We overcame this problem by dump-restoring these tables. |
|||
|
|||
 |
|||
|
|||
|
|||
Secondly, our database had to be case-insensitive, but PostgreSQL does not have this as a default configuration. We handled it using `citext` with the ABP migration service. |
|||
|
|||
 |
|||
 |
|||
 |
|||
|
|||
|
|||
While everything was proceeding very smooth, we faced one last problem: importing binary data, such as the content of the NuGet packages. It was hard to understand that the binaries of the NuGet packages were different. Our paid commercial NuGet packages are being stored as binary data in the database. Therefore, it was the most compelling part of this migration to transfer the NuGet packages. Fortunately, we overcame the binary error. And we decided to write a custom .NET tool to move only the binary data from MS-SQL to PostgreSQL, thanks to the ABP Core team! |
|||
|
|||
|
|||
## Conclusion |
|||
|
|||
One of the benefits of using PostgreSQL is the low license costs of the Azure platform. As the main contributors of ABP, we also use ABP Framework under the hood of our abp.io websites, we could easily switch to PostgreSQL. For those who want to switch their ABP project to PostgreSQL, check out [docs.abp.io/en/abp/latest/Entity-Framework-Core-PostgreSQL](https://docs.abp.io/en/abp/latest/Entity-Framework-Core-PostgreSQL). We had not used any MS-SQL specific function, therefore there was no need to make any changes in the repository classes. This means that the applications that were previously using MS-SQL can seamlessly switch to PostgreSQL without any modifications. |
|||
|
|||
Thanks to the flexibility of ABP, it has [PostgreSQL package](https://www.nuget.org/packages/Volo.Abp.EntityFrameworkCore.PostgreSql) which is 100% compatible with PostgreSQL. This helped us to make this migration very smooth and seamless. |
|||
|
|||
In conclusion, migrating a database from MS-SQL to PostgreSQL can be challenging, but it can bring significant cost savings in the long run. By testing and fine-tuning the migration process before making the final switch, we were able to overcome the challenges we’d faced during the migration process. Thanks to the flexibility of ABP, we were able to make the transition with minimal code changes. Also we didn't see any big performance differences between MS-SQL and PostgreSQL. |
|||
|
|||
|
After Width: | Height: | Size: 63 KiB |
|
After Width: | Height: | Size: 73 KiB |
|
After Width: | Height: | Size: 39 KiB |
|
After Width: | Height: | Size: 410 KiB |
|
After Width: | Height: | Size: 32 KiB |
@ -0,0 +1,309 @@ |
|||
## Introduction |
|||
In this article, I will talk about the relationships of IdentityUser in every web application that can be created with the ABP framework. When you read this article, you will learn how to extend the user entity in the applications you develop using the ABP framework with a primitive type, extending the user by associating the user with another entity (User-many-to-one-X). |
|||
|
|||
|
|||
## Creating the Solution |
|||
>For the source code of the application: https://github.com/onurpicakci/Abp-Identity-Relationship |
|||
|
|||
In this article we will use EF Core as the database provider and MVC as the user interface framework. But Angular, Blazor Server and Blazor WebAssembly also work. ABP Framework offers starter templates to get started faster. We can create a new starter template using the ABP CLI: |
|||
|
|||
```bash |
|||
abp new IdentityRelationship |
|||
``` |
|||
|
|||
After the project is created, you can run the `IdentityRelationship.DbMigrator` project to create the database and seed the initial data. You can then run the `IdentityRelationship.Web` project to see our application run. |
|||
|
|||
> The default admin username is **admin** and the password is **1q2w3E\*** |
|||
|
|||
 |
|||
|
|||
## Module Entity Extensions |
|||
|
|||
The module entity extension system is a high level extension system that allows you to define new properties for existing entities of the depended modules. It automatically adds properties to the entity, database, HTTP API and the user interface in a single point. |
|||
|
|||
### Extending the User Entity With a Primitive Type |
|||
|
|||
Open the `IdentityRelationshipModuleExtensionConfigurator` class inside the `Domain.Shared` project of your solution and change the `ConfigureExtraProperties` method as shown below to add an `IdentificationNumber` property to the `IdentityUser` entity of the [Identity Module](https://docs.abp.io/en/abp/latest/Modules/Identity). |
|||
|
|||
```csharp |
|||
public static void ConfigureExtraProperties() |
|||
{ |
|||
OneTimeRunner.Run(() => |
|||
{ |
|||
ObjectExtensionManager.Instance.Modules() |
|||
.ConfigureIdentity(identity => |
|||
{ |
|||
identity.ConfigureUser(user => |
|||
{ |
|||
user.AddOrUpdateProperty<string>( //property type: string |
|||
"IdentificationNumber", //property name |
|||
property => |
|||
{ |
|||
//validation rules |
|||
property.Attributes.Add(string.Empty); |
|||
property.Attributes.Add( |
|||
new StringLengthAttribute(64) { |
|||
MinimumLength = 4 |
|||
} |
|||
); |
|||
|
|||
//...other configurations for this property |
|||
} |
|||
); |
|||
}); |
|||
}); |
|||
}); |
|||
} |
|||
``` |
|||
> This method is called inside the IdentityRelationshipDomainSharedModule at the beginning of the application. OneTimeRunner is a utility class that guarantees to execute this code only one time per application, since multiple calls are unnecessary. |
|||
|
|||
If you want to localize, open the `IdentityRelationship.Domain.Shared` project and create a new localization in your `/Localization/IdentityRelationship/en.json` file. |
|||
|
|||
```json |
|||
"IdentificationNumber": "Identification Number" |
|||
``` |
|||
Once you define a property, it appears in the create and update forms of the related entity: |
|||
|
|||
 |
|||
|
|||
New properties also appear in the data table of the related page: |
|||
|
|||
 |
|||
|
|||
|
|||
## Navigation Properties / Foreign Keys |
|||
|
|||
It is supported to add an extension property to an entity that is the Id of another entity (foreign key). |
|||
|
|||
### Example: Let's associate a department in the database with a user |
|||
|
|||
First, create a `Departments` folder in the `IdentityRelationship.Domain` project and add the `Department` class inside: |
|||
```csharp |
|||
using System; |
|||
using Volo.Abp.Domain.Entities; |
|||
|
|||
namespace IdentityRelationship.Departments; |
|||
|
|||
public class Department : AggregateRoot<Guid> |
|||
{ |
|||
public string Name { get; set; } |
|||
} |
|||
``` |
|||
|
|||
EF Core requires that you relate the entities with your `DbContext`. The easiest way to do so is adding a DbSet property to the `IdentityRelationshipDbContext` class in the `IdentityRelationship.EntityFrameworkCore` project, as shown below: |
|||
|
|||
```csharp |
|||
public DbSet<Department> Departments { get; set; } |
|||
``` |
|||
|
|||
Then in the `IdentityRelationship.EntityFrameworkCore` project of your solution, open the `/EntityFrameworkCore/IdentityRelationshipEfCoreEntityExtensionMappings` class and update your code: |
|||
|
|||
```csharp |
|||
public static class IdentityRelationshipEfCoreEntityExtensionMappings |
|||
{ |
|||
private static readonly OneTimeRunner OneTimeRunner = new OneTimeRunner(); |
|||
|
|||
public static void Configure() |
|||
{ |
|||
IdentityRelationshipGlobalFeatureConfigurator.Configure(); |
|||
IdentityRelationshipModuleExtensionConfigurator.Configure(); |
|||
|
|||
OneTimeRunner.Run(() => |
|||
{ |
|||
ObjectExtensionManager.Instance |
|||
.MapEfCoreProperty<IdentityUser, Guid>( |
|||
"DepartmentId", |
|||
(entityBuilder, propertyBuilder) => { propertyBuilder.HasMaxLength(128); } |
|||
); |
|||
|
|||
}); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
This class can be used to map these extra properties to table fields in the database. Please read [this](https://docs.abp.io/en/abp/latest/Customizing-Application-Modules-Extending-Entities?_ga=2.21022651.140118448.1679289046-1173891759.1672473062) document to improve your understanding of what we are doing. |
|||
|
|||
We need to create a new migration to see the changes in the database. Open your `EntityFrameworkCore` project in the terminal and run the following command (this depends on the IDE you are using). |
|||
|
|||
 |
|||
|
|||
```bash |
|||
dotnet ef migrations add Create_Department_Entity |
|||
``` |
|||
|
|||
Finally, run the `IdentityRelationship.DbMigrator` project to update the database. |
|||
|
|||
When you look at your database, you can see that the `Department` table has been added and `DepartmentId` has been added to your `AbpUsers` table. |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
> It's good to have some initial data in the database before running the application. This section introduces the [Data Seeding](https://docs.abp.io/en/abp/latest/Data-Seeding) system of the ABP framework. You can skip this section if you don't want to create the data seeding, but it is suggested to follow along and learn this useful ABP Framework feature. |
|||
|
|||
Create a class deriving from the `IDataSeedContributor` in the `IdentityRelationship.Domain` project by copying the following code: |
|||
|
|||
```csharp |
|||
using System; |
|||
using System.Threading.Tasks; |
|||
using IdentityRelationship.Departments; |
|||
using Volo.Abp.Data; |
|||
using Volo.Abp.DependencyInjection; |
|||
using Volo.Abp.Domain.Repositories; |
|||
|
|||
namespace IdentityRelationship; |
|||
|
|||
public class IdentityRelationshipDataSeederContributor |
|||
: IDataSeedContributor, ITransientDependency |
|||
{ |
|||
private readonly IRepository<Department, Guid> _departmentRepository; |
|||
|
|||
public IdentityRelationshipDataSeederContributor(IRepository<Department, Guid> departmentRepository) |
|||
{ |
|||
_departmentRepository = departmentRepository; |
|||
} |
|||
|
|||
public async Task SeedAsync(DataSeedContext context) |
|||
{ |
|||
if (await _departmentRepository.GetCountAsync() <= 0) |
|||
{ |
|||
await _departmentRepository.InsertAsync( |
|||
new Department |
|||
{ |
|||
Name = "Human Resources" |
|||
}, |
|||
autoSave: true |
|||
); |
|||
|
|||
await _departmentRepository.InsertAsync( |
|||
new Department |
|||
{ |
|||
Name = "Production" |
|||
}, |
|||
autoSave: true |
|||
); |
|||
} |
|||
} |
|||
} |
|||
``` |
|||
- This code simply uses the `IRepository<Department, Guid>` (the default [repository](https://docs.abp.io/en/abp/latest/Repositories)) to insert two books to the database in case there weren't any books in it. |
|||
|
|||
Run the `IdentityRelationship.DbMigrator` application to update the database: |
|||
|
|||
 |
|||
|
|||
Again, open the `IdentityRelationshipModuleExtensionConfigurator` class in the Domain.Shared project and add the following code: |
|||
|
|||
```csharp |
|||
|
|||
user.AddOrUpdateProperty<Guid>( |
|||
"DepartmentId", |
|||
property => |
|||
{ |
|||
property.UI.Lookup.Url = "/api/app/department"; |
|||
property.UI.Lookup.DisplayPropertyName = "name"; |
|||
} |
|||
); |
|||
``` |
|||
|
|||
The `UI.Lookup.Url` option takes a URL to get the list of departments to select on the edit/create forms. This endpoint can be a typical controller, an auto API controller or any type of endpoint that returns a proper JSON response. |
|||
|
|||
To localize, open the `IdentityRelationship.Domain.Shared` project and add it to your `/Localization/IdentityRelationship/en.json` file: |
|||
|
|||
```json |
|||
"DepartmentId": "Department" |
|||
``` |
|||
|
|||
Create a `Departments` folder in the `IdentityRelationship.Application.Contracts` project of your solution and add the `DepartmentDto` class in it |
|||
|
|||
```csharp |
|||
using System; |
|||
using Volo.Abp.Application.Dtos; |
|||
namespace IdentityRelationship.Departments; |
|||
|
|||
public class DepartmentDto : EntityDto<Guid> |
|||
|
|||
{ |
|||
public string Name { get; set; } |
|||
} |
|||
``` |
|||
Now let's create an `IDepartmentAppService` interface in the `Departments` folder |
|||
|
|||
```csharp |
|||
using System.Threading.Tasks; |
|||
using Volo.Abp.Application.Dtos; |
|||
using Volo.Abp.Application.Services; |
|||
|
|||
namespace IdentityRelationship.Departments; |
|||
|
|||
public interface IDepartmentAppService : IApplicationService |
|||
{ |
|||
public Task<PagedResultDto<DepartmentDto>> GetAsync(); |
|||
} |
|||
``` |
|||
|
|||
Time to implement the `IDepartmentAppService` interface. Create a `Departments` folder in your `IdentityRelationship.Application` project and add the `DepartmentAppService` class inside. |
|||
|
|||
```csharp |
|||
using System; |
|||
using System.Collections.Generic; |
|||
using System.Threading.Tasks; |
|||
using IdentityRelationship.Departments; |
|||
using Volo.Abp.Application.Dtos; |
|||
using Volo.Abp.Domain.Repositories; |
|||
|
|||
namespace IdentityRelationship.Department; |
|||
|
|||
public class DepartmentAppService : IdentityRelationshipAppService, IDepartmentAppService |
|||
{ |
|||
private readonly IRepository<Departments.Department, Guid> _departmentRepository; |
|||
|
|||
public DepartmentAppService(IRepository<Departments.Department, Guid> departmentRepository) |
|||
{ |
|||
_departmentRepository = departmentRepository; |
|||
} |
|||
|
|||
public async Task<PagedResultDto<DepartmentDto>> GetAsync() |
|||
{ |
|||
var departments = await _departmentRepository.GetListAsync(); |
|||
var totalCount = await _departmentRepository.GetCountAsync(); |
|||
|
|||
return new PagedResultDto<DepartmentDto>(totalCount, |
|||
ObjectMapper.Map<List<Departments.Department>, List<DepartmentDto>>(departments)); |
|||
} |
|||
} |
|||
``` |
|||
`DepartmentAppService `is using the `ObjectMapper` to convert the `Department` objects to `DepartmentDto` objects. So, we need to define this mapping in the AutoMapper configuration. |
|||
|
|||
Open the `IdentityRelationshipApplicationAutoMapperProfile` class inside the `IdentityRelationship.Application` project and add the following line to the constructor: |
|||
|
|||
```csharp |
|||
using AutoMapper; |
|||
using IdentityRelationship.Departments; |
|||
|
|||
namespace IdentityRelationship; |
|||
|
|||
public class IdentityRelationshipApplicationAutoMapperProfile : Profile |
|||
{ |
|||
public IdentityRelationshipApplicationAutoMapperProfile() |
|||
{ |
|||
CreateMap<Departments.Department, DepartmentDto>(); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
Run your `IdentityRelationship.Web` project and add a department to one of your users. |
|||
|
|||
 |
|||
|
|||
And it shows the department name on the data table: |
|||
|
|||
 |
|||
|
|||
## Conclusion |
|||
In this article I talked about the use of the IdentityUser relationship and how to extend it. Thank you for reading the article, I hope it was useful. See you soon! |
|||
|
|||
## References |
|||
- https://docs.abp.io/en/abp/latest/Module-Entity-Extensions |
|||
- https://learn.microsoft.com/en-us/ef/core/modeling/relationships |
|||
- https://community.abp.io/posts/how-to-add-custom-properties-to-the-user-entity-rixchoha |
|||
|
After Width: | Height: | Size: 217 KiB |
|
After Width: | Height: | Size: 50 KiB |
|
After Width: | Height: | Size: 273 KiB |
|
After Width: | Height: | Size: 92 KiB |
|
After Width: | Height: | Size: 70 KiB |
|
After Width: | Height: | Size: 51 KiB |
|
After Width: | Height: | Size: 160 KiB |
|
After Width: | Height: | Size: 65 KiB |
|
After Width: | Height: | Size: 278 KiB |
@ -0,0 +1,52 @@ |
|||
# Card Component |
|||
|
|||
The ABP Card Component is a wrapper component for the Bootstrap card class. |
|||
|
|||
## Usage |
|||
|
|||
ABP Card Component is a part of the `ThemeSharedModule` module. If you've imported that module into your module, you don't need to import it again. If not, first import it as shown below: |
|||
|
|||
```ts |
|||
// my-feature.module.ts |
|||
|
|||
import { ThemeSharedModule } from '@abp/ng.theme.shared'; |
|||
import { CardDemoComponent } from './chart-demo.component'; |
|||
|
|||
@NgModule({ |
|||
imports: [ |
|||
ThemeSharedModule , |
|||
// ... |
|||
], |
|||
declarations: [CardDemoComponent], |
|||
// ... |
|||
}) |
|||
export class MyFeatureModule {} |
|||
|
|||
``` |
|||
|
|||
Then, the `abp-card` component can be used. See the example below: |
|||
```ts |
|||
|
|||
// card-demo.component.ts |
|||
|
|||
import { Component } from '@angular/core'; |
|||
|
|||
@Component({ |
|||
selector: 'app-card-demo', |
|||
template: ` |
|||
<abp-card [cardStyle]="{width: '18rem'}"> |
|||
<abp-card-body> |
|||
<abp-card-title>Lorem Ipsum</abp-card-title> |
|||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla commodo condimentum ligula, sed varius nibh eleifend sit amet. Maecenas facilisis vel arcu nec maximus. |
|||
</abp-card-body> |
|||
</abp-card> |
|||
`, |
|||
}) |
|||
export class CardDemoComponent { } |
|||
``` |
|||
|
|||
See the result below: |
|||
|
|||
 |
|||
|
|||
As you can see in the example above, you can customize your card component's style with the `cardStyle` input. You can also add your custom classes with the `cardClass` input. |
|||
|
After Width: | Height: | Size: 26 KiB |
@ -0,0 +1,56 @@ |
|||
using System; |
|||
using IdentityModel.Client; |
|||
using Microsoft.AspNetCore.Authentication.OpenIdConnect; |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.Options; |
|||
|
|||
namespace Microsoft.AspNetCore.Authentication.Cookies; |
|||
|
|||
public static class CookieAuthenticationOptionsExtensions |
|||
{ |
|||
/// <summary>
|
|||
/// Introspect access token on validating the principal.
|
|||
/// </summary>
|
|||
/// <param name="options"></param>
|
|||
/// <param name="oidcAuthenticationScheme"></param>
|
|||
/// <returns></returns>
|
|||
public static CookieAuthenticationOptions IntrospectAccessToken(this CookieAuthenticationOptions options, string oidcAuthenticationScheme = "oidc") |
|||
{ |
|||
var originalHandler = options.Events.OnValidatePrincipal; |
|||
options.Events.OnValidatePrincipal = async principalContext => |
|||
{ |
|||
originalHandler?.Invoke(principalContext); |
|||
|
|||
if (principalContext.Principal != null && principalContext.Principal.Identity != null && principalContext.Principal.Identity.IsAuthenticated) |
|||
{ |
|||
var accessToken = principalContext.Properties.GetTokenValue("access_token"); |
|||
if (!accessToken.IsNullOrWhiteSpace()) |
|||
{ |
|||
var openIdConnectOptions = principalContext.HttpContext.RequestServices.GetRequiredService<IOptionsMonitor<OpenIdConnectOptions>>().Get(oidcAuthenticationScheme); |
|||
if (openIdConnectOptions.Configuration == null && openIdConnectOptions.ConfigurationManager != null) |
|||
{ |
|||
openIdConnectOptions.Configuration = await openIdConnectOptions.ConfigurationManager.GetConfigurationAsync(principalContext.HttpContext.RequestAborted); |
|||
} |
|||
|
|||
var response = await openIdConnectOptions.Backchannel.IntrospectTokenAsync(new TokenIntrospectionRequest |
|||
{ |
|||
Address = openIdConnectOptions.Configuration?.IntrospectionEndpoint ?? openIdConnectOptions.Authority.EnsureEndsWith('/') + "connect/introspect", |
|||
ClientId = openIdConnectOptions.ClientId, |
|||
ClientSecret = openIdConnectOptions.ClientSecret, |
|||
Token = accessToken |
|||
}); |
|||
|
|||
if (response.IsActive) |
|||
{ |
|||
return; |
|||
} |
|||
} |
|||
|
|||
principalContext.RejectPrincipal(); |
|||
await principalContext.HttpContext.SignOutAsync(principalContext.Scheme.Name); |
|||
} |
|||
}; |
|||
|
|||
return options; |
|||
} |
|||
} |
|||
@ -0,0 +1,23 @@ |
|||
using System.Threading.Tasks; |
|||
using Volo.Abp.AspNetCore.Components.Web.Configuration; |
|||
using Volo.Abp.DependencyInjection; |
|||
|
|||
namespace Volo.Abp.AspNetCore.Components.WebAssembly.Configuration; |
|||
|
|||
[Dependency(ReplaceServices = true)] |
|||
public class BlazorWebAssemblyCurrentApplicationConfigurationCacheResetService : |
|||
ICurrentApplicationConfigurationCacheResetService, |
|||
ITransientDependency |
|||
{ |
|||
private readonly WebAssemblyCachedApplicationConfigurationClient _webAssemblyCachedApplicationConfigurationClient; |
|||
|
|||
public BlazorWebAssemblyCurrentApplicationConfigurationCacheResetService(WebAssemblyCachedApplicationConfigurationClient webAssemblyCachedApplicationConfigurationClient) |
|||
{ |
|||
_webAssemblyCachedApplicationConfigurationClient = webAssemblyCachedApplicationConfigurationClient; |
|||
} |
|||
|
|||
public async Task ResetAsync() |
|||
{ |
|||
await _webAssemblyCachedApplicationConfigurationClient.InitializeAsync(); |
|||
} |
|||
} |
|||
@ -1,16 +1,28 @@ |
|||
using System.Collections.Generic; |
|||
using Microsoft.Extensions.Options; |
|||
using Volo.Abp.AspNetCore.Mvc.UI.Bundling; |
|||
using Volo.Abp.AspNetCore.Mvc.UI.Packages.Core; |
|||
using Volo.Abp.Modularity; |
|||
using Volo.Abp.Localization; |
|||
|
|||
namespace Volo.Abp.AspNetCore.Mvc.UI.Packages.Select2; |
|||
|
|||
[DependsOn(typeof(CoreScriptContributor))] |
|||
public class Select2ScriptContributor : BundleContributor |
|||
{ |
|||
public const string PackageName = "select2"; |
|||
public override void ConfigureBundle(BundleConfigurationContext context) |
|||
{ |
|||
//TODO: Add select2.full.min.js or localize!
|
|||
//TODO: Add select2.full.min.js
|
|||
context.Files.AddIfNotContains("/libs/select2/js/select2.min.js"); |
|||
} |
|||
public override void ConfigureDynamicResources(BundleConfigurationContext context) |
|||
{ |
|||
var fileName = context.LazyServiceProvider.LazyGetRequiredService<IOptions<AbpLocalizationOptions>>().Value.GetCurrentUICultureLanguageFilesMap(PackageName); |
|||
var filePath = $"/libs/select2/js/i18n/{fileName}.js"; |
|||
if (context.FileProvider.GetFileInfo(filePath).Exists) |
|||
{ |
|||
context.Files.AddIfNotContains(filePath); |
|||
} |
|||
} |
|||
} |
|||
|
|||
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue