### Definition of Ready
- [ ] I am happy with the code
- [ ] Short description of the feature/issue is added in the pr
description
- [ ] PR is linked to the corresponding user story
- [ ] Acceptance criteria are met
- [ ] All open todos and follow ups are defined in a new ticket and
justified
- [ ] Deviations from the acceptance criteria and design are agreed with
the PO and documented.
- [ ] No debug or dead code
- [ ] Critical parts are tested automatically
- [ ] Where possible E2E tests are implemented
- [ ] Documentation/examples are up-to-date
- [ ] All non-functional requirements are met
- [ ] Functionality of the acceptance criteria is checked manually on
the dev system.
* feat: add v2alpha policies service
* feat: add v2alpha policies service
* fix: rename of attributes and messages in v2alpha api
* fix: rename of attributes and messages in v2alpha api
* fix: linter corrections
* fix: review corrections
* fix: review corrections
* fix: review corrections
* fix: review corrections
* fix grpc
* refactor: rename to settings and more
* Apply suggestions from code review
Co-authored-by: Fabi <fabienne.gerschwiler@gmail.com>
* add service to docs and rename legal settings
* unit tests for converters
* go mod tidy
* ensure idp name and return list details
* fix: use correct resource owner for active idps
* change query to join
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
Co-authored-by: Fabi <fabienne.gerschwiler@gmail.com>
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
* fix: 404 for robots.txt and meta robots tags
* fix: add unit tests for robots txt and tag
* fix: add meta tag robots none for login pages
* fix: weird format issue in header.go
* fix: add x-robots-tag=none to grpcwebserver
* fix linting
---------
Co-authored-by: Silvan <silvan.reusser@gmail.com>
Co-authored-by: Livio Spring <livio.a@gmail.com>
Add integrations tests for the gRPC API, primarily targeted at `v2` but
can also be used for legacy. Provides a crude framework that runs a
server, prepares a client and exposes the underlying resources such as
`command` and `query` handlers to the tester. The code in
`internal/integration` is written just as a proof of concept and
probably needs to be split up in more reusable chunks when we need more
functionality, like multiple users, organisations, instances etc.
Integrations tests for `user/v2alpha` are also included.
See the added documentation for more details.
Related to #5598
* chore(proto): update versions
* change protoc plugin
* some cleanups
* define api for setting emails in new api
* implement user.SetEmail
* move SetEmail buisiness logic into command
* resuse newCryptoCode
* command: add ChangeEmail unit tests
Not complete, was not able to mock the generator.
* Revert "resuse newCryptoCode"
This reverts commit c89e90ae35ae924a3f706a0a7394f933910c2e65.
* undo change to crypto code generators
* command: use a generator so we can test properly
* command: reorganise ChangeEmail
improve test coverage
* implement VerifyEmail
including unit tests
* add URL template tests
* begin user creation
* change protos
* implement metadata and move context
* merge commands
* proto: change context to object
* remove old auth option
* remove old auth option
* fix linting errors
run gci on modified files
* add permission checks and fix some errors
* comments
* comments
* update email requests
* rename proto requests
* cleanup and docs
* simplify
* simplify
* fix setup
* remove unused proto messages / fields
---------
Co-authored-by: adlerhurst <silvan.reusser@gmail.com>
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
* feat: add otp name and make it configurable
* feat: use pre-existing otp env var
* feat: use requested domain if otp issuer is empty
* cleanup
---------
Co-authored-by: Sem den Broeder <semnelldenbroeder@gmail.com>
Co-authored-by: Elio Bischof <eliobischof@gmail.com>
Co-authored-by: Livio Spring <livio.a@gmail.com>
