TheArchive/zitadel
1
0
Fork 0
mirror of https://github.com/zitadel/zitadel.git synced 2025-07-18 04:28:35 +00:00
Code Issues Packages Projects Releases Wiki Activity
zitadel/internal/api/grpc/admin/integration_test/import_test.go

516 lines
14 KiB
Go
Raw Permalink Normal View History

perf(import): do not check for existing grant ID (#8164) # Which Problems Are Solved Improve the performance of the `admin/v1/import` API endpoint. Specifaclly the import of large amount of project grants. # How the Problems Are Solved `AddProjectGrantWithID` and `AddProjectGrantMember` methods of `Commands` used to get the current state of the Writemodel to check if the current GrantID or the combination of GrantID & UserID wasn't already used. However, the Added events already have protection against duplication by the `UniqueConstaint` methods. The queries become very slow when there is a great amount of project grants. Because all the events are pushed to the aggregate ID of the project, we had to obtain all related project events, including events of grantIDs we do not care about. This O(n) duration for bached import jobs adding many organization granted to a single project. This change removes the unnecesary state query to improve performance. # Additional Changes - Add integration tests for import # Additional Context - reported internally
2024-06-20 16:31:58 +03:00
//go:build integration
package admin_test
import (
"testing"
"time"
"github.com/brianvoe/gofakeit/v6"
"github.com/google/uuid"
"github.com/stretchr/testify/require"
"github.com/zitadel/zitadel/internal/integration"
"github.com/zitadel/zitadel/pkg/grpc/admin"
"github.com/zitadel/zitadel/pkg/grpc/management"
v1 "github.com/zitadel/zitadel/pkg/grpc/v1"
)
func TestServer_ImportData(t *testing.T) {
orgIDs := generateIDs(10)
projectIDs := generateIDs(10)
userIDs := generateIDs(10)
grantIDs := generateIDs(10)
tests := []struct {
name string
req *admin.ImportDataRequest
want *admin.ImportDataResponse
wantErr bool
}{
{
name: "success",
req: &admin.ImportDataRequest{
Data: &admin.ImportDataRequest_DataOrgs{
DataOrgs: &admin.ImportDataOrg{
Orgs: []*admin.DataOrg{
{
OrgId: orgIDs[0],
Org: &management.AddOrgRequest{
Name: gofakeit.ProductName(),
},
Projects: []*v1.DataProject{
{
ProjectId: projectIDs[0],
Project: &management.AddProjectRequest{
Name: gofakeit.AppName(),
ProjectRoleAssertion: true,
},
},
{
ProjectId: projectIDs[1],
Project: &management.AddProjectRequest{
Name: gofakeit.AppName(),
ProjectRoleAssertion: false,
},
},
},
ProjectRoles: []*management.AddProjectRoleRequest{
{
ProjectId: projectIDs[0],
RoleKey: "role1",
DisplayName: "role1",
},
{
ProjectId: projectIDs[0],
RoleKey: "role2",
DisplayName: "role2",
},
{
ProjectId: projectIDs[1],
RoleKey: "role3",
DisplayName: "role3",
},
{
ProjectId: projectIDs[1],
RoleKey: "role4",
DisplayName: "role4",
},
},
HumanUsers: []*v1.DataHumanUser{
{
UserId: userIDs[0],
User: &management.ImportHumanUserRequest{
UserName: gofakeit.Username(),
Profile: &management.ImportHumanUserRequest_Profile{
FirstName: gofakeit.FirstName(),
LastName: gofakeit.LastName(),
DisplayName: gofakeit.Username(),
PreferredLanguage: gofakeit.LanguageBCP(),
},
Email: &management.ImportHumanUserRequest_Email{
Email: gofakeit.Email(),
IsEmailVerified: true,
},
},
},
{
UserId: userIDs[1],
User: &management.ImportHumanUserRequest{
UserName: gofakeit.Username(),
Profile: &management.ImportHumanUserRequest_Profile{
FirstName: gofakeit.FirstName(),
LastName: gofakeit.LastName(),
DisplayName: gofakeit.Username(),
PreferredLanguage: gofakeit.LanguageBCP(),
},
Email: &management.ImportHumanUserRequest_Email{
Email: gofakeit.Email(),
IsEmailVerified: true,
},
},
},
},
ProjectGrants: []*v1.DataProjectGrant{
{
GrantId: grantIDs[0],
ProjectGrant: &management.AddProjectGrantRequest{
ProjectId: projectIDs[0],
GrantedOrgId: orgIDs[1],
RoleKeys: []string{"role1", "role2"},
},
},
{
GrantId: grantIDs[1],
ProjectGrant: &management.AddProjectGrantRequest{
ProjectId: projectIDs[1],
GrantedOrgId: orgIDs[1],
RoleKeys: []string{"role3", "role4"},
},
},
{
GrantId: grantIDs[2],
ProjectGrant: &management.AddProjectGrantRequest{
ProjectId: projectIDs[0],
GrantedOrgId: orgIDs[2],
RoleKeys: []string{"role1", "role2"},
},
},
{
GrantId: grantIDs[3],
ProjectGrant: &management.AddProjectGrantRequest{
ProjectId: projectIDs[1],
GrantedOrgId: orgIDs[2],
RoleKeys: []string{"role3", "role4"},
},
},
},
},
{
OrgId: orgIDs[1],
Org: &management.AddOrgRequest{
Name: gofakeit.ProductName(),
},
UserGrants: []*management.AddUserGrantRequest{
{
UserId: userIDs[0],
ProjectId: projectIDs[0],
ProjectGrantId: grantIDs[0],
},
{
UserId: userIDs[0],
ProjectId: projectIDs[1],
ProjectGrantId: grantIDs[1],
},
},
},
{
OrgId: orgIDs[2],
Org: &management.AddOrgRequest{
Name: gofakeit.ProductName(),
},
UserGrants: []*management.AddUserGrantRequest{
{
UserId: userIDs[1],
ProjectId: projectIDs[0],
ProjectGrantId: grantIDs[2],
},
{
UserId: userIDs[1],
ProjectId: projectIDs[1],
ProjectGrantId: grantIDs[3],
},
},
},
},
},
},
Timeout: time.Minute.String(),
},
want: &admin.ImportDataResponse{
Success: &admin.ImportDataSuccess{
Orgs: []*admin.ImportDataSuccessOrg{
{
OrgId: orgIDs[0],
ProjectIds: projectIDs[0:2],
ProjectRoles: []string{
projectIDs[0] + "_role1",
projectIDs[0] + "_role2",
projectIDs[1] + "_role3",
projectIDs[1] + "_role4",
},
HumanUserIds: userIDs[0:2],
ProjectGrants: []*admin.ImportDataSuccessProjectGrant{
{
GrantId: grantIDs[0],
ProjectId: projectIDs[0],
OrgId: orgIDs[1],
},
{
GrantId: grantIDs[1],
ProjectId: projectIDs[1],
OrgId: orgIDs[1],
},
{
GrantId: grantIDs[2],
ProjectId: projectIDs[0],
OrgId: orgIDs[2],
},
{
GrantId: grantIDs[3],
ProjectId: projectIDs[1],
OrgId: orgIDs[2],
},
},
},
{
OrgId: orgIDs[1],
UserGrants: []*admin.ImportDataSuccessUserGrant{
{
ProjectId: projectIDs[0],
UserId: userIDs[0],
},
{
UserId: userIDs[0],
ProjectId: projectIDs[1],
},
},
},
{
OrgId: orgIDs[2],
UserGrants: []*admin.ImportDataSuccessUserGrant{
{
ProjectId: projectIDs[0],
UserId: userIDs[1],
},
{
UserId: userIDs[1],
ProjectId: projectIDs[1],
},
},
},
},
},
},
},
{
name: "duplicate project grant error",
req: &admin.ImportDataRequest{
Data: &admin.ImportDataRequest_DataOrgs{
DataOrgs: &admin.ImportDataOrg{
Orgs: []*admin.DataOrg{
feat: project v2beta resource API (#9742) # Which Problems Are Solved Resource management of projects and sub-resources was before limited by the context provided by the management API, which would mean you could only manage resources belonging to a specific organization. # How the Problems Are Solved With the addition of a resource-based API, it is now possible to manage projects and sub-resources on the basis of the resources themselves, which means that as long as you have the permission for the resource, you can create, read, update and delete it. - CreateProject to create a project under an organization - UpdateProject to update an existing project - DeleteProject to delete an existing project - DeactivateProject and ActivateProject to change the status of a project - GetProject to query for a specific project with an identifier - ListProject to query for projects and granted projects - CreateProjectGrant to create a project grant with project and granted organization - UpdateProjectGrant to update the roles of a project grant - DeactivateProjectGrant and ActivateProjectGrant to change the status of a project grant - DeleteProjectGrant to delete an existing project grant - ListProjectGrants to query for project grants - AddProjectRole to add a role to an existing project - UpdateProjectRole to change texts of an existing role - RemoveProjectRole to remove an existing role - ListProjectRoles to query for project roles # Additional Changes - Changes to ListProjects, which now contains granted projects as well - Changes to messages as defined in the [API_DESIGN](https://github.com/zitadel/zitadel/blob/main/API_DESIGN.md) - Permission checks for project functionality on query and command side - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - ListProjects now also correctly lists `granted projects` - Permission checks for project grant and project role functionality on query and command side - Change existing pre checks so that they also work resource specific without resourceowner - Added the resourceowner to the grant and role if no resourceowner is provided - Corrected import tests with project grants and roles - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - Corrected some naming in the proto files to adhere to the API_DESIGN # Additional Context Closes #9177 --------- Co-authored-by: Livio Spring <livio.a@gmail.com>
2025-05-21 14:40:47 +02:00
{
OrgId: orgIDs[4],
Org: &management.AddOrgRequest{
Name: gofakeit.ProductName(),
},
},
perf(import): do not check for existing grant ID (#8164) # Which Problems Are Solved Improve the performance of the `admin/v1/import` API endpoint. Specifaclly the import of large amount of project grants. # How the Problems Are Solved `AddProjectGrantWithID` and `AddProjectGrantMember` methods of `Commands` used to get the current state of the Writemodel to check if the current GrantID or the combination of GrantID & UserID wasn't already used. However, the Added events already have protection against duplication by the `UniqueConstaint` methods. The queries become very slow when there is a great amount of project grants. Because all the events are pushed to the aggregate ID of the project, we had to obtain all related project events, including events of grantIDs we do not care about. This O(n) duration for bached import jobs adding many organization granted to a single project. This change removes the unnecesary state query to improve performance. # Additional Changes - Add integration tests for import # Additional Context - reported internally
2024-06-20 16:31:58 +03:00
{
OrgId: orgIDs[3],
Org: &management.AddOrgRequest{
Name: gofakeit.ProductName(),
},
Projects: []*v1.DataProject{
{
ProjectId: projectIDs[2],
Project: &management.AddProjectRequest{
Name: gofakeit.AppName(),
ProjectRoleAssertion: true,
},
},
{
ProjectId: projectIDs[3],
Project: &management.AddProjectRequest{
Name: gofakeit.AppName(),
ProjectRoleAssertion: false,
},
},
},
ProjectRoles: []*management.AddProjectRoleRequest{
{
ProjectId: projectIDs[2],
RoleKey: "role1",
DisplayName: "role1",
},
{
ProjectId: projectIDs[2],
RoleKey: "role2",
DisplayName: "role2",
},
{
ProjectId: projectIDs[3],
RoleKey: "role3",
DisplayName: "role3",
},
{
ProjectId: projectIDs[3],
RoleKey: "role4",
DisplayName: "role4",
},
},
ProjectGrants: []*v1.DataProjectGrant{
{
GrantId: grantIDs[4],
ProjectGrant: &management.AddProjectGrantRequest{
ProjectId: projectIDs[2],
GrantedOrgId: orgIDs[4],
RoleKeys: []string{"role1", "role2"},
},
},
{
GrantId: grantIDs[4],
ProjectGrant: &management.AddProjectGrantRequest{
ProjectId: projectIDs[2],
GrantedOrgId: orgIDs[4],
RoleKeys: []string{"role1", "role2"},
},
},
},
},
},
},
},
Timeout: time.Minute.String(),
},
want: &admin.ImportDataResponse{
Errors: []*admin.ImportDataError{
{
Type: "project_grant",
Id: orgIDs[3] + "_" + projectIDs[2] + "_" + orgIDs[4],
Message: "ID=V3-DKcYh Message=Errors.Project.Grant.AlreadyExists Parent=(ERROR: duplicate key value violates unique constraint \"unique_constraints_pkey\" (SQLSTATE 23505))",
},
},
Success: &admin.ImportDataSuccess{
Orgs: []*admin.ImportDataSuccessOrg{
feat: project v2beta resource API (#9742) # Which Problems Are Solved Resource management of projects and sub-resources was before limited by the context provided by the management API, which would mean you could only manage resources belonging to a specific organization. # How the Problems Are Solved With the addition of a resource-based API, it is now possible to manage projects and sub-resources on the basis of the resources themselves, which means that as long as you have the permission for the resource, you can create, read, update and delete it. - CreateProject to create a project under an organization - UpdateProject to update an existing project - DeleteProject to delete an existing project - DeactivateProject and ActivateProject to change the status of a project - GetProject to query for a specific project with an identifier - ListProject to query for projects and granted projects - CreateProjectGrant to create a project grant with project and granted organization - UpdateProjectGrant to update the roles of a project grant - DeactivateProjectGrant and ActivateProjectGrant to change the status of a project grant - DeleteProjectGrant to delete an existing project grant - ListProjectGrants to query for project grants - AddProjectRole to add a role to an existing project - UpdateProjectRole to change texts of an existing role - RemoveProjectRole to remove an existing role - ListProjectRoles to query for project roles # Additional Changes - Changes to ListProjects, which now contains granted projects as well - Changes to messages as defined in the [API_DESIGN](https://github.com/zitadel/zitadel/blob/main/API_DESIGN.md) - Permission checks for project functionality on query and command side - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - ListProjects now also correctly lists `granted projects` - Permission checks for project grant and project role functionality on query and command side - Change existing pre checks so that they also work resource specific without resourceowner - Added the resourceowner to the grant and role if no resourceowner is provided - Corrected import tests with project grants and roles - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - Corrected some naming in the proto files to adhere to the API_DESIGN # Additional Context Closes #9177 --------- Co-authored-by: Livio Spring <livio.a@gmail.com>
2025-05-21 14:40:47 +02:00
{
OrgId: orgIDs[4],
},
perf(import): do not check for existing grant ID (#8164) # Which Problems Are Solved Improve the performance of the `admin/v1/import` API endpoint. Specifaclly the import of large amount of project grants. # How the Problems Are Solved `AddProjectGrantWithID` and `AddProjectGrantMember` methods of `Commands` used to get the current state of the Writemodel to check if the current GrantID or the combination of GrantID & UserID wasn't already used. However, the Added events already have protection against duplication by the `UniqueConstaint` methods. The queries become very slow when there is a great amount of project grants. Because all the events are pushed to the aggregate ID of the project, we had to obtain all related project events, including events of grantIDs we do not care about. This O(n) duration for bached import jobs adding many organization granted to a single project. This change removes the unnecesary state query to improve performance. # Additional Changes - Add integration tests for import # Additional Context - reported internally
2024-06-20 16:31:58 +03:00
{
OrgId: orgIDs[3],
ProjectIds: projectIDs[2:4],
ProjectRoles: []string{
projectIDs[2] + "_role1",
projectIDs[2] + "_role2",
projectIDs[3] + "_role3",
projectIDs[3] + "_role4",
},
ProjectGrants: []*admin.ImportDataSuccessProjectGrant{
{
GrantId: grantIDs[4],
ProjectId: projectIDs[2],
OrgId: orgIDs[4],
},
},
},
},
},
},
},
{
name: "duplicate project grant member error",
req: &admin.ImportDataRequest{
Data: &admin.ImportDataRequest_DataOrgs{
DataOrgs: &admin.ImportDataOrg{
Orgs: []*admin.DataOrg{
feat: project v2beta resource API (#9742) # Which Problems Are Solved Resource management of projects and sub-resources was before limited by the context provided by the management API, which would mean you could only manage resources belonging to a specific organization. # How the Problems Are Solved With the addition of a resource-based API, it is now possible to manage projects and sub-resources on the basis of the resources themselves, which means that as long as you have the permission for the resource, you can create, read, update and delete it. - CreateProject to create a project under an organization - UpdateProject to update an existing project - DeleteProject to delete an existing project - DeactivateProject and ActivateProject to change the status of a project - GetProject to query for a specific project with an identifier - ListProject to query for projects and granted projects - CreateProjectGrant to create a project grant with project and granted organization - UpdateProjectGrant to update the roles of a project grant - DeactivateProjectGrant and ActivateProjectGrant to change the status of a project grant - DeleteProjectGrant to delete an existing project grant - ListProjectGrants to query for project grants - AddProjectRole to add a role to an existing project - UpdateProjectRole to change texts of an existing role - RemoveProjectRole to remove an existing role - ListProjectRoles to query for project roles # Additional Changes - Changes to ListProjects, which now contains granted projects as well - Changes to messages as defined in the [API_DESIGN](https://github.com/zitadel/zitadel/blob/main/API_DESIGN.md) - Permission checks for project functionality on query and command side - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - ListProjects now also correctly lists `granted projects` - Permission checks for project grant and project role functionality on query and command side - Change existing pre checks so that they also work resource specific without resourceowner - Added the resourceowner to the grant and role if no resourceowner is provided - Corrected import tests with project grants and roles - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - Corrected some naming in the proto files to adhere to the API_DESIGN # Additional Context Closes #9177 --------- Co-authored-by: Livio Spring <livio.a@gmail.com>
2025-05-21 14:40:47 +02:00
{
OrgId: orgIDs[6],
Org: &management.AddOrgRequest{
Name: gofakeit.ProductName(),
},
},
perf(import): do not check for existing grant ID (#8164) # Which Problems Are Solved Improve the performance of the `admin/v1/import` API endpoint. Specifaclly the import of large amount of project grants. # How the Problems Are Solved `AddProjectGrantWithID` and `AddProjectGrantMember` methods of `Commands` used to get the current state of the Writemodel to check if the current GrantID or the combination of GrantID & UserID wasn't already used. However, the Added events already have protection against duplication by the `UniqueConstaint` methods. The queries become very slow when there is a great amount of project grants. Because all the events are pushed to the aggregate ID of the project, we had to obtain all related project events, including events of grantIDs we do not care about. This O(n) duration for bached import jobs adding many organization granted to a single project. This change removes the unnecesary state query to improve performance. # Additional Changes - Add integration tests for import # Additional Context - reported internally
2024-06-20 16:31:58 +03:00
{
OrgId: orgIDs[5],
Org: &management.AddOrgRequest{
Name: gofakeit.ProductName(),
},
Projects: []*v1.DataProject{
{
ProjectId: projectIDs[4],
Project: &management.AddProjectRequest{
Name: gofakeit.AppName(),
ProjectRoleAssertion: true,
},
},
},
ProjectRoles: []*management.AddProjectRoleRequest{
{
ProjectId: projectIDs[4],
RoleKey: "role1",
DisplayName: "role1",
},
feat: project v2beta resource API (#9742) # Which Problems Are Solved Resource management of projects and sub-resources was before limited by the context provided by the management API, which would mean you could only manage resources belonging to a specific organization. # How the Problems Are Solved With the addition of a resource-based API, it is now possible to manage projects and sub-resources on the basis of the resources themselves, which means that as long as you have the permission for the resource, you can create, read, update and delete it. - CreateProject to create a project under an organization - UpdateProject to update an existing project - DeleteProject to delete an existing project - DeactivateProject and ActivateProject to change the status of a project - GetProject to query for a specific project with an identifier - ListProject to query for projects and granted projects - CreateProjectGrant to create a project grant with project and granted organization - UpdateProjectGrant to update the roles of a project grant - DeactivateProjectGrant and ActivateProjectGrant to change the status of a project grant - DeleteProjectGrant to delete an existing project grant - ListProjectGrants to query for project grants - AddProjectRole to add a role to an existing project - UpdateProjectRole to change texts of an existing role - RemoveProjectRole to remove an existing role - ListProjectRoles to query for project roles # Additional Changes - Changes to ListProjects, which now contains granted projects as well - Changes to messages as defined in the [API_DESIGN](https://github.com/zitadel/zitadel/blob/main/API_DESIGN.md) - Permission checks for project functionality on query and command side - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - ListProjects now also correctly lists `granted projects` - Permission checks for project grant and project role functionality on query and command side - Change existing pre checks so that they also work resource specific without resourceowner - Added the resourceowner to the grant and role if no resourceowner is provided - Corrected import tests with project grants and roles - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - Corrected some naming in the proto files to adhere to the API_DESIGN # Additional Context Closes #9177 --------- Co-authored-by: Livio Spring <livio.a@gmail.com>
2025-05-21 14:40:47 +02:00
{
ProjectId: projectIDs[4],
RoleKey: "role2",
DisplayName: "role2",
},
perf(import): do not check for existing grant ID (#8164) # Which Problems Are Solved Improve the performance of the `admin/v1/import` API endpoint. Specifaclly the import of large amount of project grants. # How the Problems Are Solved `AddProjectGrantWithID` and `AddProjectGrantMember` methods of `Commands` used to get the current state of the Writemodel to check if the current GrantID or the combination of GrantID & UserID wasn't already used. However, the Added events already have protection against duplication by the `UniqueConstaint` methods. The queries become very slow when there is a great amount of project grants. Because all the events are pushed to the aggregate ID of the project, we had to obtain all related project events, including events of grantIDs we do not care about. This O(n) duration for bached import jobs adding many organization granted to a single project. This change removes the unnecesary state query to improve performance. # Additional Changes - Add integration tests for import # Additional Context - reported internally
2024-06-20 16:31:58 +03:00
},
HumanUsers: []*v1.DataHumanUser{
{
UserId: userIDs[2],
User: &management.ImportHumanUserRequest{
UserName: gofakeit.Username(),
Profile: &management.ImportHumanUserRequest_Profile{
FirstName: gofakeit.FirstName(),
LastName: gofakeit.LastName(),
DisplayName: gofakeit.Username(),
PreferredLanguage: gofakeit.LanguageBCP(),
},
Email: &management.ImportHumanUserRequest_Email{
Email: gofakeit.Email(),
IsEmailVerified: true,
},
},
},
},
ProjectGrants: []*v1.DataProjectGrant{
{
GrantId: grantIDs[5],
ProjectGrant: &management.AddProjectGrantRequest{
ProjectId: projectIDs[4],
GrantedOrgId: orgIDs[6],
RoleKeys: []string{"role1", "role2"},
},
},
},
ProjectGrantMembers: []*management.AddProjectGrantMemberRequest{
{
ProjectId: projectIDs[4],
GrantId: grantIDs[5],
UserId: userIDs[2],
Roles: []string{"PROJECT_GRANT_OWNER"},
},
{
ProjectId: projectIDs[4],
GrantId: grantIDs[5],
UserId: userIDs[2],
Roles: []string{"PROJECT_GRANT_OWNER"},
},
},
},
},
},
},
Timeout: time.Minute.String(),
},
want: &admin.ImportDataResponse{
Errors: []*admin.ImportDataError{
{
Type: "project_grant_member",
Id: orgIDs[5] + "_" + projectIDs[4] + "_" + grantIDs[5] + "_" + userIDs[2],
feat: user profile requests in resource APIs (#10151) # Which Problems Are Solved The commands for the resource based v2beta AuthorizationService API are added. Authorizations, previously knows as user grants, give a user in a specific organization and project context roles. The project can be owned or granted. The given roles can be used to restrict access within the projects applications. The commands for the resource based v2beta InteralPermissionService API are added. Administrators, previously knows as memberships, give a user in a specific organization and project context roles. The project can be owned or granted. The give roles give the user permissions to manage different resources in Zitadel. API definitions from https://github.com/zitadel/zitadel/issues/9165 are implemented. Contains endpoints for user metadata. # How the Problems Are Solved ### New Methods - CreateAuthorization - UpdateAuthorization - DeleteAuthorization - ActivateAuthorization - DeactivateAuthorization - ListAuthorizations - CreateAdministrator - UpdateAdministrator - DeleteAdministrator - ListAdministrators - SetUserMetadata to set metadata on a user - DeleteUserMetadata to delete metadata on a user - ListUserMetadata to query for metadata of a user ## Deprecated Methods ### v1.ManagementService - GetUserGrantByID - ListUserGrants - AddUserGrant - UpdateUserGrant - DeactivateUserGrant - ReactivateUserGrant - RemoveUserGrant - BulkRemoveUserGrant ### v1.AuthService - ListMyUserGrants - ListMyProjectPermissions # Additional Changes - Permission checks for metadata functionality on query and command side - correct existence checks for resources, for example you can only be an administrator on an existing project - combined all member tables to singular query for the administrators - add permission checks for command an query side functionality - combined functions on command side where necessary for easier maintainability # Additional Context Closes #9165 --------- Co-authored-by: Elio Bischof <elio@zitadel.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Livio Spring <livio.a@gmail.com>
2025-07-04 18:12:59 +02:00
Message: "ID=PROJECT-37fug Message=Errors.AlreadyExists",
perf(import): do not check for existing grant ID (#8164) # Which Problems Are Solved Improve the performance of the `admin/v1/import` API endpoint. Specifaclly the import of large amount of project grants. # How the Problems Are Solved `AddProjectGrantWithID` and `AddProjectGrantMember` methods of `Commands` used to get the current state of the Writemodel to check if the current GrantID or the combination of GrantID & UserID wasn't already used. However, the Added events already have protection against duplication by the `UniqueConstaint` methods. The queries become very slow when there is a great amount of project grants. Because all the events are pushed to the aggregate ID of the project, we had to obtain all related project events, including events of grantIDs we do not care about. This O(n) duration for bached import jobs adding many organization granted to a single project. This change removes the unnecesary state query to improve performance. # Additional Changes - Add integration tests for import # Additional Context - reported internally
2024-06-20 16:31:58 +03:00
},
},
Success: &admin.ImportDataSuccess{
Orgs: []*admin.ImportDataSuccessOrg{
feat: project v2beta resource API (#9742) # Which Problems Are Solved Resource management of projects and sub-resources was before limited by the context provided by the management API, which would mean you could only manage resources belonging to a specific organization. # How the Problems Are Solved With the addition of a resource-based API, it is now possible to manage projects and sub-resources on the basis of the resources themselves, which means that as long as you have the permission for the resource, you can create, read, update and delete it. - CreateProject to create a project under an organization - UpdateProject to update an existing project - DeleteProject to delete an existing project - DeactivateProject and ActivateProject to change the status of a project - GetProject to query for a specific project with an identifier - ListProject to query for projects and granted projects - CreateProjectGrant to create a project grant with project and granted organization - UpdateProjectGrant to update the roles of a project grant - DeactivateProjectGrant and ActivateProjectGrant to change the status of a project grant - DeleteProjectGrant to delete an existing project grant - ListProjectGrants to query for project grants - AddProjectRole to add a role to an existing project - UpdateProjectRole to change texts of an existing role - RemoveProjectRole to remove an existing role - ListProjectRoles to query for project roles # Additional Changes - Changes to ListProjects, which now contains granted projects as well - Changes to messages as defined in the [API_DESIGN](https://github.com/zitadel/zitadel/blob/main/API_DESIGN.md) - Permission checks for project functionality on query and command side - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - ListProjects now also correctly lists `granted projects` - Permission checks for project grant and project role functionality on query and command side - Change existing pre checks so that they also work resource specific without resourceowner - Added the resourceowner to the grant and role if no resourceowner is provided - Corrected import tests with project grants and roles - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - Corrected some naming in the proto files to adhere to the API_DESIGN # Additional Context Closes #9177 --------- Co-authored-by: Livio Spring <livio.a@gmail.com>
2025-05-21 14:40:47 +02:00
{
OrgId: orgIDs[6],
},
perf(import): do not check for existing grant ID (#8164) # Which Problems Are Solved Improve the performance of the `admin/v1/import` API endpoint. Specifaclly the import of large amount of project grants. # How the Problems Are Solved `AddProjectGrantWithID` and `AddProjectGrantMember` methods of `Commands` used to get the current state of the Writemodel to check if the current GrantID or the combination of GrantID & UserID wasn't already used. However, the Added events already have protection against duplication by the `UniqueConstaint` methods. The queries become very slow when there is a great amount of project grants. Because all the events are pushed to the aggregate ID of the project, we had to obtain all related project events, including events of grantIDs we do not care about. This O(n) duration for bached import jobs adding many organization granted to a single project. This change removes the unnecesary state query to improve performance. # Additional Changes - Add integration tests for import # Additional Context - reported internally
2024-06-20 16:31:58 +03:00
{
OrgId: orgIDs[5],
ProjectIds: projectIDs[4:5],
ProjectRoles: []string{
projectIDs[4] + "_role1",
feat: project v2beta resource API (#9742) # Which Problems Are Solved Resource management of projects and sub-resources was before limited by the context provided by the management API, which would mean you could only manage resources belonging to a specific organization. # How the Problems Are Solved With the addition of a resource-based API, it is now possible to manage projects and sub-resources on the basis of the resources themselves, which means that as long as you have the permission for the resource, you can create, read, update and delete it. - CreateProject to create a project under an organization - UpdateProject to update an existing project - DeleteProject to delete an existing project - DeactivateProject and ActivateProject to change the status of a project - GetProject to query for a specific project with an identifier - ListProject to query for projects and granted projects - CreateProjectGrant to create a project grant with project and granted organization - UpdateProjectGrant to update the roles of a project grant - DeactivateProjectGrant and ActivateProjectGrant to change the status of a project grant - DeleteProjectGrant to delete an existing project grant - ListProjectGrants to query for project grants - AddProjectRole to add a role to an existing project - UpdateProjectRole to change texts of an existing role - RemoveProjectRole to remove an existing role - ListProjectRoles to query for project roles # Additional Changes - Changes to ListProjects, which now contains granted projects as well - Changes to messages as defined in the [API_DESIGN](https://github.com/zitadel/zitadel/blob/main/API_DESIGN.md) - Permission checks for project functionality on query and command side - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - ListProjects now also correctly lists `granted projects` - Permission checks for project grant and project role functionality on query and command side - Change existing pre checks so that they also work resource specific without resourceowner - Added the resourceowner to the grant and role if no resourceowner is provided - Corrected import tests with project grants and roles - Added testing to unit tests on command side - Change update endpoints to no error returns if nothing changes in the resource - Changed all integration test utility to the new service - Corrected some naming in the proto files to adhere to the API_DESIGN # Additional Context Closes #9177 --------- Co-authored-by: Livio Spring <livio.a@gmail.com>
2025-05-21 14:40:47 +02:00
projectIDs[4] + "_role2",
perf(import): do not check for existing grant ID (#8164) # Which Problems Are Solved Improve the performance of the `admin/v1/import` API endpoint. Specifaclly the import of large amount of project grants. # How the Problems Are Solved `AddProjectGrantWithID` and `AddProjectGrantMember` methods of `Commands` used to get the current state of the Writemodel to check if the current GrantID or the combination of GrantID & UserID wasn't already used. However, the Added events already have protection against duplication by the `UniqueConstaint` methods. The queries become very slow when there is a great amount of project grants. Because all the events are pushed to the aggregate ID of the project, we had to obtain all related project events, including events of grantIDs we do not care about. This O(n) duration for bached import jobs adding many organization granted to a single project. This change removes the unnecesary state query to improve performance. # Additional Changes - Add integration tests for import # Additional Context - reported internally
2024-06-20 16:31:58 +03:00
},
HumanUserIds: userIDs[2:3],
ProjectGrants: []*admin.ImportDataSuccessProjectGrant{
{
GrantId: grantIDs[5],
ProjectId: projectIDs[4],
OrgId: orgIDs[6],
},
},
ProjectGrantMembers: []*admin.ImportDataSuccessProjectGrantMember{
{
ProjectId: projectIDs[4],
GrantId: grantIDs[5],
UserId: userIDs[2],
},
},
},
},
},
},
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
got, err := Client.ImportData(AdminCTX, tt.req)
if tt.wantErr {
chore: improve integration tests (#8727) Improve integration tests: - spliting the tests in TokenExchange to isolated instances and in parallel - corrected some test structure so that the check for Details is no done anymore if the test already failed - replace required-calls with assert-calls to not stop the testing - add gofakeit for application, project and usernames(emails) - add eventually checks for testing in actions v2, so the request only get called when the execution is defined - check for length of results in list/search endpoints to avoid index errors
2024-10-17 23:20:57 +02:00
require.Error(t, err)
perf(import): do not check for existing grant ID (#8164) # Which Problems Are Solved Improve the performance of the `admin/v1/import` API endpoint. Specifaclly the import of large amount of project grants. # How the Problems Are Solved `AddProjectGrantWithID` and `AddProjectGrantMember` methods of `Commands` used to get the current state of the Writemodel to check if the current GrantID or the combination of GrantID & UserID wasn't already used. However, the Added events already have protection against duplication by the `UniqueConstaint` methods. The queries become very slow when there is a great amount of project grants. Because all the events are pushed to the aggregate ID of the project, we had to obtain all related project events, including events of grantIDs we do not care about. This O(n) duration for bached import jobs adding many organization granted to a single project. This change removes the unnecesary state query to improve performance. # Additional Changes - Add integration tests for import # Additional Context - reported internally
2024-06-20 16:31:58 +03:00
return
}
require.NoError(t, err)
integration.EqualProto(t, tt.want, got)
})
}
}
func generateIDs(n int) []string {
ids := make([]string, n)
for i := range ids {
ids[i] = uuid.NewString()
}
return ids
}
Reference in New Issue Copy Permalink