5 Commits

Include renames

Author	SHA1	Message	Date
3 people	f04d873270	feat(domain): Organization APIs with relational tables (#10704) ... # Which Problems Are Solved This PR implements the endpoints listed in #10445 using relational tables. - [x] UpdateOrganization - [x] ListOrganizations - [x] DeleteOrganization - [x] DeactivateOrganization - [x] ActivateOrganization # How the Problems Are Solved - **UpdateOrganization:** Implemented logic for `Validate()`, `Execute()` and `Events()`. On CQRS side, updating an organization emits events related to the organization and its domains. Separate commanders have been made for the domain events so that their logic is run accordingly and we keep separation of concerns. Implementation of the domains is left to its own ticket. Because some domain-related data is changed during the organization update, its original values are saved as pointers inside [UpdateOrgCommand](https://github.com/zitadel/zitadel/blob/4f87cd8d0cfd75f290aa13c342e4939cecebef73/backend/v3/domain/org_update.go#L20). These variables will be then used as input for the domain commanders (that will run after the update organization one). - **ListOrganizations:** Implemented logic for `Validate()`, `Execute()`. Utility methods have been made to parse the input queries. This commander is used both by the v2 and v2beta endpoint, so a translation layer has been put in place to translate all v2beta requests into v2. The commander strictly handles v2 request only. The translation layer between v2beta and v2 APIs was made so to make it simple to remove it once the v2beta APIs will be removed (a simple deletion should suffice). A `converter` package [is shipped](https://github.com/zitadel/zitadel/blob/4f87cd8d0cfd75f290aa13c342e4939cecebef73/backend/v3/api/org/v2/convert/README.md#L5) as well with instruction for removal. TODOs have been put in place all over the code to indicate that the related piece of code needs to be removed once v2beta -> v2 transition is complete. - **DeleteOrganization:** Implemented logic for `Validate()`, `Execute()` and `Events()`. The `Events()` method is mostly incomplete as it requires a lot of data that is currently not retrievable due to the lack of their relational tables. - **DeactivateOrganization** and **ActivateOrganization**: Implemented logic for `Validate()`, `Execute()` and `Events()`. No notable remarks. 👉 All endpoints return matching errors to the CQRS counterpart: this way allows re-using the integration tests and 👉 All endpoints have been unit-tested through DB mocking 👉 A bunch of TODOs have been put in place for future reworks that are needed (e.g. `Update()` method on repository should also return a timestamp) # Additional Changes - A test utility method to allow mocking query options have been made. This was necessary because `database.QueryOption` is a function and the only comparison possible with functions is `nil` check. So, to mock this, `database.QueryOption` is converted first to `database.QueryOpts`. See 2276742adaef1998ea4844e1f0dca2079e45ccfb - A `BaseCommand` has been created with the idea to collect methods that are going to be needed by other commands. For the moment, it only offers a method to convert query text operations from gRPC to `domain` model. See bb85456dd101282fa76d2e2ad165eed4c8ef61b9 - SQL operations have been reworked to allow for queries using `ContainsIgnoreCase`, `EndsWithIgnoreCase` and other `IgnoreCase` operations. This change is pending approval and might be reworked. See https://github.com/zitadel/zitadel/pull/10704#discussion_r2392886177 # Additional Context `UpdateOrganization` is partially working because the logic for handling domain updates is not done (there is only a draft of the commanders to showcase the call chain). See https://github.com/zitadel/zitadel/pull/10704#discussion_r2356143178 Permissions are not implemented as they are missing. See https://github.com/zitadel/zitadel/pull/10771 - Closes: #10445 --------- Co-authored-by: Silvan <[email protected]>	2025-10-21 15:27:38 +02:00
SilvanandGitHub	6686c3b16b	feat(relational): org metadata (#10761) ... This pull request introduces a new feature that allows adding, updating, and querying metadata for organizations. The changes are primarily in the backend and include new database tables, repositories, and domain logic to support organization metadata. ## Changes * New `org_metadata` table: A new table `zitadel.org_metadata` is introduced to store metadata for organizations. It includes columns for `instance_id`, `org_id`, `key`, and `value`. The `value` is stored as a `BYTEA` type to allow for flexible data storage. * New `OrganizationMetadataRepository`: A new repository `OrganizationMetadataRepository` is created to handle all database operations for organization metadata. It provides methods to `Get`, `List`, `Set`, and `Remove` metadata. * New `org_metadata_relational_projection`: A new projection `org_metadata_relational_projection` is added to update the `zitadel.org_metadata` table based on events. It handles `MetadataSet`, `MetadataRemoved`, and `MetadataRemovedAll` events. * Updated `OrganizationRepository`: The `OrganizationRepository` is updated to support loading organization metadata. A new method `LoadMetadata` is added to enable joining the `org_metadata` table when querying for organizations. * Updated Organization domain: The Organization domain model is updated to include a new field `Metadata` of type `[]*OrganizationMetadata`. ## Additional Info * Extensible Design: The new metadata feature is designed to be extensible, allowing for future enhancements such as indexing on specific JSON fields within the `value` column. * closes https://github.com/zitadel/zitadel/issues/10206 * closes https://github.com/zitadel/zitadel/issues/10214	2025-10-14 10:15:16 +01:00
IraqandGitHub	08f41e034e	feat(idp_table_relational): adding inital idp tables for relational repository (#10334)	2025-09-24 13:19:09 +00:00
SilvanandGitHub	cccfc816f6	refactor: database interaction and error handling (#10762) ... This pull request introduces a significant refactoring of the database interaction layer, focusing on improving explicitness, transactional control, and error handling. The core change is the removal of the stateful `QueryExecutor` from repository instances. Instead, it is now passed as an argument to each method that interacts with the database. This change makes transaction management more explicit and flexible, as the same repository instance can be used with a database pool or a specific transaction without needing to be re-instantiated. ### Key Changes - **Explicit `QueryExecutor` Passing:** - All repository methods (`Get`, `List`, `Create`, `Update`, `Delete`, etc.) in `InstanceRepository`, `OrganizationRepository`, `UserRepository`, and their sub-repositories now require a `database.QueryExecutor` (e.g., a `*pgxpool.Pool` or `pgx.Tx`) as the first argument. - Repository constructors no longer accept a `QueryExecutor`. For example, `repository.InstanceRepository(pool)` is now `repository.InstanceRepository()`. - **Enhanced Error Handling:** - A new `database.MissingConditionError` is introduced to enforce required query conditions, such as ensuring an `instance_id` is always present in `UPDATE` and `DELETE` operations. - The database error wrapper in the `postgres` package now correctly identifies and wraps `pgx.ErrTooManyRows` and similar errors from the `scany` library into a `database.MultipleRowsFoundError`. - **Improved Database Conditions:** - The `database.Condition` interface now includes a `ContainsColumn(Column) bool` method. This allows for runtime checks to ensure that critical filters (like `instance_id`) are included in a query, preventing accidental cross-tenant data modification. - A new `database.Exists()` condition has been added to support `EXISTS` subqueries, enabling more complex filtering logic, such as finding an organization that has a specific domain. - **Repository and Interface Refactoring:** - The method for loading related entities (e.g., domains for an organization) has been changed from a boolean flag (`Domains(true)`) to a more explicit, chainable method (`LoadDomains()`). This returns a new repository instance configured to load the sub-resource, promoting immutability. - The custom `OrgIdentifierCondition` has been removed in favor of using the standard `database.Condition` interface, simplifying the API. - **Code Cleanup and Test Updates:** - Unnecessary struct embeddings and metadata have been removed. - All integration and repository tests have been updated to reflect the new method signatures, passing the database pool or transaction object explicitly. - New tests have been added to cover the new `ExistsDomain` functionality and other enhancements. These changes make the data access layer more robust, predictable, and easier to work with, especially in the context of database transactions.	2025-09-24 10:12:31 +00:00
6 people	61cab8878e	feat(backend): state persisted objects (#9870) ... This PR initiates the rework of Zitadel's backend to state-persisted objects. This change is a step towards a more scalable and maintainable architecture. ## Changes * **New `/backend/v3` package**: A new package structure has been introduced to house the reworked backend logic. This includes: * `domain`: Contains the core business logic, commands, and repository interfaces. * `storage`: Implements the repository interfaces for database interactions with new transactional tables. * `telemetry`: Provides logging and tracing capabilities. * **Transactional Tables**: New database tables have been defined for `instances`, `instance_domains`, `organizations`, and `org_domains`. * **Projections**: New projections have been created to populate the new relational tables from the existing event store, ensuring data consistency during the migration. * **Repositories**: New repositories provide an abstraction layer for accessing and manipulating the data in the new tables. * **Setup**: A new setup step for `TransactionalTables` has been added to manage the database migrations for the new tables. This PR lays the foundation for future work to fully transition to state-persisted objects for these components, which will improve performance and simplify data access patterns. This PR initiates the rework of ZITADEL's backend to state-persisted objects. This is a foundational step towards a new architecture that will improve performance and maintainability. The following objects are migrated from event-sourced aggregates to state-persisted objects: * Instances * incl. Domains * Orgs * incl. Domains The structure of the new backend implementation follows the software architecture defined in this [wiki page](https://github.com/zitadel/zitadel/wiki/Software-Architecturel). This PR includes: * The initial implementation of the new transactional repositories for the objects listed above. * Projections to populate the new relational tables from the existing event store. * Adjustments to the build and test process to accommodate the new backend structure. This is a work in progress and further changes will be made to complete the migration. --------- Co-authored-by: Copilot <[email protected]> Co-authored-by: Iraq Jaber <[email protected]> Co-authored-by: Iraq <[email protected]> Co-authored-by: Tim Möhlmann <[email protected]>	2025-09-05 09:54:34 +01:00