# Introduction
It seems like that within the `twenty-server` `nx-project` there's no
entry for the `typecheck` command. It also seems to silently fail along
the `start` command even if it depends on it.
Looking at this
[run](https://github.com/twentyhq/twenty/actions/runs/12865329787/job/35865644811?pr=9736)
we can see that even when containing following diff it still does not
fail
```ts
// twenty-server/main.ts
// @ts-expected-error: Manually triggering TSC error should be deleted afterwards
const bootstrap = async () => {
```
By adding the `typecheck` entry in the project the same run will now
[fails](https://github.com/twentyhq/twenty/actions/runs/12865516249/job/35866224325)
# Notes
- There're no existing TSC errors even if wasn't guarded by the CI rn 😎
- The ci will take dozen of more seconds to run, should keep an eye on
// with nx implem checking if it works as expected
### Context
User (who has create a workspace and deleted it) can't create new
workspace because after deleting his previous workspace, user has not
been soft deleted.
There is several cases where user should be soft deleted :
1/ if user delete his account
2/ if a user's workspace is deleted + user has no other workspace
3/ If a workspaceMember is removed + user has no other workspace
### Solution
In `handleRemoveWorkspaceMember` method (logic used in the 3 cases),
soft delete user when removing the last userWorkspace
closes#9728
Co-authored-by: etiennejouan <jouan.etienne@gmail.com>
Replaced `validateInvitation` with `validatePersonalInvitation` across
services for consistent and specific validation handling. Removed
outdated public invitation validation and improved error handling for
workspace invitations. Updated tests to align with the refactored logic
and added checks for edge cases.
Added explicit typing for session storage options to improve type
safety. Enabled 'trust proxy' to ensure proper client IP and protocol
detection behind proxies. These changes improve security and reliability
in session handling.
- Clean Playwright's configuration:
- Remove artificial 500ms delay between each step
- Group all tests under a `chrome` project relying on a `setup` project
to get an authentication state which all tests can reuse
- Changes on the `Sign up with invite link via email` test:
- Generate a new email for each test trial, as previously it was failing
when run many times
- Make deleting the account part of the test; if we write other tests
for account sign-up, we'll prefer to delete the accounts with an HTTP
call to speed up things
- Added some assertions to ensure we reached steps when expected, as we
removed the 500ms delay between each step, and it made some assertions
fail
- Wrote new tests for workflows:
- Created `Create workflow`, a test asserting we can create a workflow
from the record table
- Created `Create simple workflow`, a test asserting we can create a
simple flow; I will add more assertions to this test and write other
tests once this first PR is approved
- I make HTTP calls to delete and destroy workflows after they run to
keep the database clean
- Added a data-testid to ensure we focus elements from the Cmd+K; our
selectors are not strong – see `getByRole('textbox')` – and I preferred
to scope them to a root element
- Added an `aria-label` to a button
---------
Co-authored-by: prastoin <paul@twenty.com>
This PR fixes a problem with how TypeORM handles date without time.
A date without time that is stored in PostgreSQL database as `date` type
gets returned as an ISO string date with a timezone that can shift its
date part in an unwanted way.
In short DB stores `2025-01-01`, TypeORM query builder returns
`2024-12-31T23:00:00Z` which gets parsed as `2024-12-31` on the front
end field.
We don't want to handle timezone here because we are manipulating a date
without its time part, so this PR adds a step that counteracts what
TypeORM does and returns `2025-01-01T00:00:00.000Z` so that the front
can parse it correctly.
@Weiko We might want to check other places of the backend where date
types are returned by TypeORM, we might have the same problem, this PR
only fixes it for updateOne resolver return.
- Fixed date persist on frontend which was shifting the date to a
different day due to timezone issue
- Fixed date returned by the backend update logic, which was shifting
the date by the timezone offset (so this PR adds back the offset so that
it stays at 00:00:00Z time)
Removed unnecessary workspace lookup in `findWorkspaceForSignInUp` when
using password-based auth. Updated tests to validate the refactored
behavior and ensure no regressions in workspace resolution for different
auth scenarios.
Adjust onboarding activation to trigger only for new users with
pictures. This prevents unnecessary activation steps for other user
types, streamlining the flow.
# Introduction
Running `storybook` with `configuration=pages` outputs a coverage that
is not replicated afterwards by the `storybook:coverage` command.
```sh
npx nx storybook:serve-and-test:static twenty-front --configuration=pages --shard=1/1 --checkCoverage=true
# ...
[TEST] Test Suites: 40 passed, 40 total
[TEST] Tests: 52 passed, 52 total
[TEST] Snapshots: 0 total
[TEST] Time: 84.786 s
[TEST] Ran all test suites.
[TEST] Coverage file (13067196 bytes) written to .nyc_output/coverage.json
[TEST] > nx storybook:coverage twenty-front --coverageDir=coverage/storybook --checkCoverage=true
[TEST]
[TEST]
[TEST] > nx run twenty-front:"storybook:coverage" --coverageDir=coverage/storybook --checkCoverage=true
[TEST]
[TEST] > npx nyc report --reporter=lcov --reporter=text-summary -t coverage/storybook --report-dir coverage/storybook --check-coverage=true --cwd=packages/twenty-front
[TEST]
[TEST]
[TEST] =============================== Coverage summary ===============================
[TEST] Statements : 70.45% ( 775/1100 )
[TEST] Branches : 45.39% ( 197/434 )
[TEST] Functions : 63.52% ( 209/329 )
[TEST] Lines : 71.28% ( 767/1076 )
[TEST] ================================================================================
[TEST]
```
```sh
> npx nyc report --reporter=lcov --reporter=text-summary -t coverage/storybook --report-dir coverage/storybook --check-coverage=true --cwd=packages/twenty-front
=============================== Coverage summary ===============================
Statements : 37.4% ( 9326/24931 )
Branches : 22.99% ( 2314/10063 )
Functions : 28.27% ( 2189/7741 )
Lines : 37.81% ( 9261/24488 )
================================================================================
ERROR: Coverage for lines (37.81%) does not meet global threshold (39%)
ERROR: Coverage for branches (22.99%) does not meet global threshold (23%)
ERROR: Coverage for statements (37.4%) does not meet global threshold (39%)
Warning: command "npx nyc report --reporter=lcov --reporter=text-summary -t coverage/storybook --report-dir coverage/storybook --check-coverage=true --cwd=packages/twenty-front" exited with non-zero status code
```
## Fix
Persist configuration scope arg to the `check-coverage` command
## Question
Should we add a step in the `ci-front` what would merge all
`performance,modules,pages` coverage and calculate the `global` coverage
? => I think that this has no plus value as we still compute each of
them individualy
# Introduction
It seems like I've just oversight adding it back while debugging
# Centralization
Please note that we only have access to the following context within a
job matrix properties:
```
Available expression contexts: github, inputs, vars, needs
```
We could centralize the `storybook_scope` as a job `outputs` in order to
avoid this to re-occurs.
Refers #8128
Changes Introduced:
- Added i18n configuration.
- Added a feature flag for localization.
- Enabled language switching based on the flag.
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
Before the `recordIndexId` was the name plural. This caused problems
because the component states were the same for every view of an object.
When we switched from one view to another, some states weren't reset.
This PR fixes this by:
- Creating an effect at the same level of page change effect to set the
`currentViewId` inside the object `contextStore`
- Adding the `currentViewId` to the `recordIndexId`
Follow ups:
- We need to get rid of
`packages/twenty-front/src/modules/views/states/currentViewIdComponentState.ts`
and use the context store instead
Ensure early return in `hasUserAccessToWorkspaceOrThrow` for existing
users during sign-in. This prevents further unnecessary execution when
access validation is complete.
Removed unused UserService dependency and simplified authCallback
function by using destructured parameters. Added checks for user email
and integrated invitation lookup and access validation for enhanced SSO
sign-in/up flow.
We were using metadata client by legacy. Architecture is not great for
Core engine: workflows are available both in data and metadata client.
It makes more sense to use the data client since workflows are part of
standard objects
In this PR:
- migrate WorkspaceActivationStatus to twenty-shared (and update case to
make FE and BE consistent)
- introduce isWorkspaceActiveOrSuspended in twenty-shared
- refactor the code to use it (when we fetch data on the FE, we want to
keep SUSPENDED workspace working + when we sync workspaces we want it
too)
# Introduction
Applying the most present `yaml` file extension to all
`.github/workflows/` files
## Notes
Regarding the `restore-cache` and `save-cache` composite actions github
agnostically searches for any `DockerFile` `action.yml` and
`action.yaml` within the target folder when invoking composite actions
as follows:
```yml
- name: Restore storybook build cache
if: steps.changed-files.outputs.any_changed == 'true'
uses: ./.github/workflows/actions/restore-cache
with:
key: ${{ env.STORYBOOK_BUILD_CACHE_KEY }}
```
