### The Issue
Every PR is currently failing the REST API breaking changes check with
errors like:
```
Could not find /components/schemas/ViewForResponse
Could not find /components/schemas/View
Could not find /components/schemas/ViewForUpdate
...
```
This is happening because the View REST endpoints were added to main `(/rest/metadata/views, /rest/metadata/viewFields, etc.)` but the corresponding OpenAPI schema definitions were missing from components.utils.ts.
### The Fix
Added the missing schema definitions for all View-related entities:
- view, viewField, viewFilter, viewSort, viewGroup, viewFilterGroup
- Each entity includes 3 schema variants: base, ForUpdate, and ForResponse
This ensures the OpenAPI spec properly documents what's already exposed.
### Note about CI
This PR will still show the error in CI since it's comparing against the current main branch. Once merged, this should
resolve the issue for future PRs.
### Open Question
Should the View REST endpoints be gated behind the IS_CORE_VIEW_ENABLED feature flag? Currently they're always exposed
while the GraphQL resolvers do check this flag. Happy to add that in a follow-up if needed.
It was painful to be redirected to an external site if you don't needed
to (no credit card needed)
---------
Co-authored-by: etiennejouan <jouan.etienne@gmail.com>
- Move dev-only types to devDependencies
- Move frontend-only deps from root to twenty-front
- Add website-only deps to twenty-website
- Fix react-phone-number-input patch path
CI should validate.
Created:
- Services
- Resolvers
- Controllers
- Tests for services
- Integration tests for GraphQL and Rest
Updated the Rest API playground
Added new feature flag `IS_CORE_VIEW_ENABLED`
Updated `viewFilter` `operand` and `view` `type` to be enums rather than
strings and generated migration file.
Closes https://github.com/twentyhq/core-team-issues/issues/1259
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
As per title, I believe calling i18n is bad because it's a singleton.
This singleton is being set back and force by users in
i18n.middleware.ts
Strategy:
we need to load the translations dynamically! Should be straight
forward:
- singleton (i18nService) containing all translationMessages
- singleton also containing a map of i18n instances loaded for each
locale => I've checked it's not heavy on RAM at all
- some methods to get the translation for a messageId x locale or the
whole i18n instance
==> use it everywhere, this PR only takes care of data model translation
## Context
This PR fixes a REST API metadata schema mismatch that occurred after
the webhook and apiKey migration from workspace entities to metadata
level.
## The Issue
After PR #13576 deleted the webhook and apiKey workspace entities, the
metadata OpenAPI specification ended up in a broken state:
- The `/metadata` endpoints still had paths for `/webhooks` and
`/apiKeys`
- But the schema definitions were missing (they were previously pulled
from workspace entities)
- This created dangling references in the OpenAPI document
## The Fix
Added proper schema definitions for webhook and apiKey directly in
`computeMetadataSchemaComponents`:
- `Webhook`, `WebhookForUpdate`, `WebhookForResponse`
- `ApiKey`, `ApiKeyForUpdate`, `ApiKeyForResponse`
## Why the CI is Failing
The CI breaking changes detection is comparing:
- **Main branch**: Has a broken OpenAPI document with endpoints that
reference non-existent schemas
- **This branch**: Has the fixed OpenAPI document with proper schemas
The OpenAPI diff tool can't even parse the main branch's document due to
the missing schema references, hence the error -- tested locally
In this PR:
- fix race condition while getting token and redirecting to workspace
domain (missing await)
- add userFriendlyMessage when user does not have password and we try to
log in using password
- refactor computePartialUserFromUserPayload to remove side effect
- add isEmailAlreadyVerified in userPayload that will set
user.isEmailVerified to true
Health status queries are failing at the moment - regression was
introduced in 01f25519f6
health status ids are not uuids, we use params to fetch them on the
frontend.
But maybe @FelixMalfait and @abdulrahmancodes have more context on this
one?
nitin