# Which Problems Are Solved
Adding ability to add a root CA to LDAP configs
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/7888
---------
Co-authored-by: Iraq Jaber <IraqJaber@gmail.com>
# Which Problems Are Solved
Due to other priorities we decided to push the implementation of user
schema back in the roadmap.
As the feature is not yet complete and can't be tested/used, the API
Docs V3 for user schema and user lead to confusion.
# How the Problems Are Solved
I removed the api docs for user schema and user v3 from the sidenav for
the moment
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Solves #8976
# Additional Changes
I have done some intensive refactorings and we are using the new
@zitadel/client package for GRPC access.
# Additional Context
- Closes#8976
---------
Co-authored-by: Max Peintner <peintnerm@gmail.com>
# Which Problems Are Solved
Performance issue for GRPC call `zitadel.user.v2.UserService.ListUsers`
due to lack of org filtering on `ListUsers`
# Additional Context
Replace this example with links to related issues, discussions, discord
threads, or other sources with more context.
Use the Closing #issue syntax for issues that are resolved with this PR.
- Closes https://github.com/zitadel/zitadel/issues/9191
---------
Co-authored-by: Iraq Jaber <IraqJaber@gmail.com>
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
# Which Problems Are Solved
SCIM 2.0 Server was not listed in the readme of Zitadel
New Login was not listed
# How the Problems Are Solved
Added scim 2.0 as a feature to the list
Added new login, including a gif to showcase
# Which Problems Are Solved
OIDC applications can configure the used login version, which is
currently not possible for SAML applications.
# How the Problems Are Solved
Add the same functionality dependent on the feature-flag for SAML
applications.
# Additional Changes
None
# Additional Context
Closes#9267
Follow up issue for frontend changes #9354
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
When specifying a `user_id` as a human admin in
`zitadel.org.v2.AddOrganizationRequest.AddOrganization()` the `user_id`
specified in the request should have been used, before it was being
ignored, this has been fixed with this PR
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/9308
---------
Co-authored-by: Iraq Jaber <IraqJaber@gmail.com>
# Which Problems Are Solved
To integrate river as a task queue we need to ensure the migrations of
river are executed.
# How the Problems Are Solved
- A new schema was added to the Zitadel database called "queue"
- Added a repeatable setup step to Zitadel which executes the
[migrations of
river](https://riverqueue.com/docs/migrations#go-migration-api).
# Additional Changes
- Added more hooks to the databases to properly set the schema for the
task queue
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/9280
# Which Problems Are Solved
Project creation always requires a user as project owner, in case of a
system user creating the project, there is no valid user existing at
that moment.
# How the Problems Are Solved
Remove the initially created project owner membership, as this is
something which was necessary in old versions, and all should work
perfectly without.
The call to add a project automatically designates the calling user as
the project owner, which is irrelevant currently, as this user always
already has higher permissions to be able to even create the project.
# Additional Changes
Cleanup of the existing checks for the project, which can be improved
through the usage of the fields table.
# Additional Context
Closes#9182
# Which Problems Are Solved
Systems running with PostgreSQL before Zitadel v2.39 are likely to have
a wrong type for the `in_tx_order` column in the `eventstore.event2`
table. The migration at the time used the `event_sequence` as default
value without typecast, which results in a `bigint` type for that
column. However, when creating the table from scratch, we explicitly
specify the type to be `integer`.
Starting from Zitadel v2.67 we use a Pl/PgSQL function to push events.
The function requires the types from `eventstore.events2` to the same as
the `select` destinations used in the function. In the function
`in_tx_order` is also expected to by of `integer` type.
CochroachDB systems are not affected because `bigint` is an alias to the
`int` type. In other words, CockroachDB uses `int8` when specifying type
`int`. Therefore the types already match.
# How the Problems Are Solved
Retrieve the actual column type currently in use. A template is used to
assign the type to the `ordinality` column returned as `in_tx_order`.
# Additional Changes
- Detailed logging on migration failure
# Additional Context
- Closes#9180
---------
Co-authored-by: Silvan <27845747+adlerhurst@users.noreply.github.com>
# Which Problems Are Solved
Ordering of sessions in v2beta is still relevant in the integration
tests.
# How the Problems Are Solved
Correct the integration tests on session service v2beta like in v2.
# Additional Changes
None
# Additional Context
Failing integration tests in pipeline.
# Which Problems Are Solved
Through configuration on projects, there can be additional permission
checks enabled through an OIDC or SAML flow, which were not included in
the OIDC and SAML services.
# How the Problems Are Solved
Add permission check through the query-side of Zitadel in a singular SQL
query, when an OIDC or SAML flow should be linked to a SSO session. That
way it is eventual consistent, but will not impact the performance on
the eventstore. The permission check is defined in the API, which
provides the necessary function to the command side.
# Additional Changes
Added integration tests for the permission check on OIDC and SAML
service for every combination.
Corrected session list integration test, to content checks without
ordering.
Corrected get auth and saml request integration tests, to check for
timestamp of creation, not start of test.
# Additional Context
Closes#9265
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
When implementing simple stateless event processor, `the
user.grant.changed` bears too little information: just grant id and list
of role keys. This makes it impossible to change a users permissions
solely based on available role keys and requires to either:
- Store a mapping grant id -> user id, making a service stateful
- Make an extra call to zitadel to resolve user id by grant id (And it
doesn't seem that such an endpoint exists)
Same with `user.grant.removed` events.
# How the Problems Are Solved
Added `userId` field to `user.grant.changed` and `user.grant.removed`
events
# Additional Changes
`user.grant.removed` now has `projectId` and `grantId` as well
# Additional Context
- Closes#9113
# Which Problems Are Solved
Currently it is not always obvious if a feature is in beta state, also I
don't know where I can add my feedback if I test the feature.
# How the Problems Are Solved
- Mark beta features with [beta] in sidenav
- Add note on feature description where to add feedback
