## Changes
- Updated the property name in the upgrade guide to reflect the
permission split in Admin Panel:
- `canImpersonate`: only provides access to impersonate functionality
- `canAccessFullAdminPanel`: provides access to all other admin panel
features
This PR fixes issue https://github.com/twentyhq/twenty/issues/11865.
The highlight heading logic in TOC was checking the heading text which
could be the same for multiple headings.
The ids for these headings were also just the heading texts, leading to
conflict in ids too.
Fix:
- Appended index of the heading item from the list of headings to the id
of the heading. This fixed conflicting ids.
- Used these unique ids to toggle the highlight style.
Behaviour after the fix:
https://github.com/user-attachments/assets/ab3bc205-0b0e-451d-b9cb-4fa852263efc
Edit:
close#11865
---------
Co-authored-by: prastoin <paul@twenty.com>
isEmailVerified was set to false which was annoying in the staging
environment
Also updated password for tim@apple.dev from AppleCar2025 to just
tim@apple.dev since the joke is outdated
Now the source of truth for the version is set during the build process.
We set it as an environment variable from the tags.
We could add it back to the package.json during the build process (from
the git tag), but there is not use for it at the moment since it's not
npm packages.
Let's deprecate Sentry Release and use APP_VERSION instead.
It'll make it more clear in the interface to use named version for bug
analysis, than commit sha
# Introduction
closes https://github.com/twentyhq/core-team-issues/issues/591
Same than for `twenty-shared` made in
https://github.com/twentyhq/twenty/pull/11083.
## TODO
- [x] Manual migrate twenty-website twenty-ui imports
## What's next:
- Generate barrel and migration script factorization within own package
+ tests
- Refactoring using preconstruct ? TimeBox
- Lint circular dependencies
- Lint import from barrel and forbid them
### Preconstruct
We need custom rollup plugins addition, but preconstruct does not expose
its rollup configuration. It might be possible to handle this using the
babel overrides. But was a big tunnel.
We could give it a try afterwards ! ( allowing cjs interop and stuff
like that )
Stuck to vite lib app
Closed related PRs:
- https://github.com/twentyhq/twenty/pull/11294
- https://github.com/twentyhq/twenty/pull/11203
# Introduction
Lately encountering a lot of out of memory error when running
twenty-front in watch mode with both TypeScript and lint checkers
```ts
Error: Worker terminated due to reaching memory limit: JS heap out of memory
at new NodeError (node:internal/errors:405:5)
at [kOnExit] (node:internal/worker:287:26)
at Worker.<computed>.onexit (node:internal/worker:209:20)
```
The existing configuration looks like this:
```ts
// packages/twenty-front/vite.config.ts
'cd ../.. && eslint packages/twenty-front --report-unused-disable-directives --max-warnings 0 --config .eslintrc.cjs',
```
This is wrong as computing the root eslintrc completely omitting
twenty-front's one ***and its ignorePattern*** so will be checking in
`node_modules` etc checking for project-structure :).
For example this a
[snippet](https://gist.github.com/prastoin/d7f8ad4ef5eb2f7732209b756a38094c)
of the above commands errors. We can see rule that should be disabled by
`eslintrc.react.cjs` extension made from twenty-front `eslintrc` :
```ts
/Users/paulrastoin/ws/twenty-two/packages/twenty-front/src/modules/settings/data-model/fields/forms/components/__stories__/SettingsDataModelFieldSettingsFormCard.stories.tsx
23:27 warning Forbidden non-null assertion @typescript-eslint/no-non-null-assertion
```
## Fixes
- consume the `twenty-front` package eslint configuration within the
vite lint checker
- eslint overrides extends are getting merged based on glob inclusion of
their files declarations
- any linted files should be included in one of our `tsconfig`
- removed redundant and counter-productive negative `ignorePatterns`, as
eslint will naturally only lint files within configuration file
directory by default which will result making it go through local
`node_modules` project structure
## Now
Less cpu usage <3.5 gb and faster
```ts
// from packages/twenty-front
TIMING=1 npx eslint . --report-unused-disable-directives --max-warnings 0 --config .eslintrc.cjs --debug
#...
Rule | Time (ms) | Relative
:-----------------------------------------------|----------:|--------:
project-structure/folder-structure | 19578.927 | 20.2%
prettier/prettier | 13746.156 | 14.2%
no-redeclare | 9546.570 | 9.9%
@nx/workspace-explicit-boolean-predicates-in-if | 8167.805 | 8.4%
@typescript-eslint/no-unused-vars | 6872.803 | 7.1%
import/no-relative-packages | 6577.273 | 6.8%
@nx/enforce-module-boundaries | 6520.945 | 6.7%
import/no-duplicates | 4987.476 | 5.2%
react/no-direct-mutation-state | 2323.082 | 2.4%
react/require-render-return | 1155.261 | 1.2%
```
## Conclusion
Please note that `nx linter` might not be as strict as vite config
eslint runner
---------
Co-authored-by: Charles Bochet <charlesBochet@users.noreply.github.com>
A small PR but a big step towards making Twenty easier to self-host and
upgrade!
Now changing the tag and pulling a new version should be the only step
to upgrade as migrations script will be ran automatically upon starting
the containers. It was already the case for typeorm migrations, but not
for standard objects migration and data migration scripts. It is still
possible to disable this behavior for the most complex deployments such
as our own cloud.
Done :
- move metrics and health cache services from health module to metrics
module
- refactor metrics counter from specific method to set up from enum keys
- add OpenTelemetry (Otel) instrumentation for metrics
- set up Otel SDK to send metrics to Otel collector
To do later :
- implement Otel instrumentation for traces + plug Sentry on top
- Add validation for the `release` field of the releases collection
- The `release` must follow semver format
- The `slug` matches the `release` by default and must follow semver
format, too
- Order the releases properly
- `0.10.0` appears before `0.3.0`; I made the comparison against
`0000.0010.0000` and `0000.0003.0000`
- Set up images for release's contents
- Refactor the release notes of the version `0.43.0` to be editable in
Keystatic; it will serve as an example
## Demo
https://github.com/user-attachments/assets/d82851e9-11e7-4e27-b645-cf86a93d77bf
# Introduction
This PR contains a big test file and few snapshots
Related to https://github.com/twentyhq/core-team-issues/issues/487
## New env var `APP_VERSION`
Now will be injected directly in a built docker image the twenty's built
version. Inferred from the build git tag name.
Which mean on main or other `not a tag version` built APP_VERSION will
be `null`
## New upgrade-commander-runner
Refactored the upgrade command to be more strict regarding:
- Version management
- Sync metadata command always run
- Added failing workspaces aggregator + logs on cleanup
From now on the `upgrade` command will compare the `WORKSPACE_VERSION`
to the `APP_VERSION` in order to bypass any workspace version != than
the upgrade version `fromVersion`
## Existing commands
Note that the version validation will be done only when passing by the
`upgrade` command.
Which means that running the following command
`upgrade:x.y-some-specific-command` won't result in workspace version
mutation
This is to enforce that all an upgrade commands + sync-metadata has been
run on a workspace
## Will do in other PR but related
### New workspace
New workspace will now be inserted with version equal to the APP_VERSION
they've been created by
### Old workspace
Will create a command that should be ran outside of any `upgrade-runner`
extending command, the command will have to be ran on every workspace
before making the next release upgrade
This command iterates over any active and suspended workspace that has
`version` to `NULL` in order to update it `APP_VERSION` -1 minor
### SENTRY_RELEASE
- Either deprecate SENTRY_RELEASE in favor of `APP_VERSION` => What
about main with null version ? or create a new env var that would be
`APP_COMMIT_SHA` instead of SENTRY third party ref
### Update CD to inject APP_VERSION from branch name
### Update docs and release logs
Adding documentation for `APP_VERSION`
## Related PRs:
https://github.com/twentyhq/twenty-infra/pull/181
Closes https://github.com/twentyhq/core-team-issues/issues/271
This PR
- Removes the feature flag IS_COMMAND_MENU_V2_ENABLED
- Removes all old Right drawer components
- Removes the Action menu bar
- Removes unused Copilot page
driver implementation for sending emails with microsoft
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
This PR introduces Keystatic to let us edit twenty.com's content with a
CMS. For now, we'll focus on creating release notes through Keystatic as
it uses quite simple Markdown. Other types of content will need some
refactoring to work with Keystatic.
https://github.com/user-attachments/assets/e9f85bbf-daff-4b41-bc97-d1baf63758b2
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
### Update of path for copying postgres dumpfile to docker host folder.
The original path stated in the upgrade guide for self hosted docker.
(Option 2) Database migration, contains a wrong path to be able to copy
the backup file. The command results in a "there is no such file"
I replaced the line
**docker cp twenty-db-1:/databases_backup.sql .**
with
**docker cp twenty-db-1:/home/postgres/databases_backup.sql .**
and it worked as it should.
So this is the edit of the correct path on the user guide on the webpage
Simplifying a lot the upgrade system.
New way to upgrade:
`yarn command:prod upgrade`
New way to write upgrade commands (all wrapping is done for you)
```
override async runOnWorkspace({
index,
total,
workspaceId,
options,
}: RunOnWorkspaceArgs): Promise<void> {}
```
Also cleaning CommandModule imports to make it lighter
