Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(database): Add trigger to set impersonation on first user #9195

Merged
merged 2 commits into from
Dec 24, 2024

Conversation

AMoreaux
Copy link
Contributor

@AMoreaux AMoreaux commented Dec 23, 2024

Introduced a trigger to automatically set canImpersonate to true for the first user inserted into the core.user table. The trigger is removed after the first user is added to ensure this behavior only applies to the initial user. Includes both the creation and rollback logic for the migration.

Close #9173

@AMoreaux AMoreaux self-assigned this Dec 23, 2024
Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR Summary

Adds a PostgreSQL trigger to automatically grant impersonation privileges to the first user created in the system, with self-cleanup functionality after initial user creation.

  • Added trigger insert_user_trigger in packages/twenty-server/src/database/typeorm/core/migrations/common/1734950137596-add-trigger-to-update-can-impersonate-on-first-user.ts that sets canImpersonate=true for first user
  • Potential race condition identified: concurrent user inserts could result in multiple users getting impersonation rights due to non-atomic check
  • Implemented self-cleanup via delete_first_user_trigger() function that removes the trigger after first user creation
  • Migration includes complete rollback functionality to remove trigger and associated functions

1 file(s) reviewed, 3 comment(s)
Edit PR Review Bot Settings | Greptile

Copy link
Member

@FelixMalfait FelixMalfait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! As discussed in DM I think it would be best to avoid using Triggers which are hard to monitor and not a pattern we use

Introduced a trigger to automatically set `canImpersonate` to true for the first user inserted into the `core.user` table. The trigger is removed after the first user is added to ensure this behavior only applies to the initial user. Includes both the creation and rollback logic for the migration.
Removed the database trigger for setting `canImpersonate` for the first user and implemented the logic directly in the `sign-in-up.service`. This simplifies the code by handling the first user creation within the application layer, ensuring better maintainability.
@AMoreaux AMoreaux force-pushed the feat/can-impersonate-to-true-for-first-user branch from 3ce581b to 1b9aa15 Compare December 23, 2024 13:12
@AMoreaux AMoreaux enabled auto-merge (squash) December 23, 2024 13:12
Copy link
Member

@FelixMalfait FelixMalfait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great!

@AMoreaux AMoreaux merged commit b52c23b into main Dec 24, 2024
22 checks passed
@AMoreaux AMoreaux deleted the feat/can-impersonate-to-true-for-first-user branch December 24, 2024 08:52
Copy link

Thanks @AMoreaux for your contribution!
This marks your 37th PR on the repo. You're top 1% of all our contributors 🎉
See contributor page - Share on LinkedIn - Share on Twitter

Contributions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

As the first user on the first workspace I should get admin access
2 participants