This PR was created by [GitStart](https://gitstart.com/) to address the
requirements from this ticket:
[TWNTY-7536](https://clients.gitstart.com/twenty/5449/tickets/TWNTY-7536).
---
### Description
Migrate all menu items components to twenty ui and update imports.
```typescript
MenuItem
MenuItemAvata
MenuItemCommand
MenuItemCommandHotKeys
MenuItemDraggable
MenuItemMultiSelect
MenuItemMultiSelectAvatar
MenuItemMultiSelectTag
MenuItemNavigate
MenuItemSelect
MenuItemSelectAvatar
MenuItemSelectColor
MenuItemSelectTag
MenuItemSuggestion
MenuItemToggle
```
\
Also migrate all other dependent components and utilities like
`Checkbox` & `Toggle`\
\
Fixestwentyhq/private-issues#82
---------
Co-authored-by: gitstart-twenty <gitstart-twenty@users.noreply.github.com>
Co-authored-by: gitstart-twenty <140154534+gitstart-twenty@users.noreply.github.com>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
In this PR:
- Add support for manual triggers in the backend
- Add a right drawer to let users select the type of trigger they want
- Create a specific right drawer for database event triggers
- Create a right drawer for manual triggers; let the user select where
the manual trigger should be made available
- Create a default trigger as soon as the user selects the type of
trigger they want. It prevents the user to see empty selects for record
type and event type. By default, the database event trigger will be set
to "company.created". It should be visible enough for users to
understand what happens and choose another record type or event type.
https://github.com/user-attachments/assets/29a21985-1823-4890-9eb3-e4f876459c7a
- Improve the design of the right drawer
- Allow to update the trigger of the workflow: the object and the event
listened to
- Allow to update the selected serverless function that a code action
should execute
- Change how we determine which workflow version to display in the
visualizer. We fetch the selected workflow's data, including whether it
has a draft or a published version. If the workflow has a draft version,
it gets displayed; otherwise, we display the last published version.
- I used the type `WorkflowWithCurrentVersion` to forward the currently
edited workflow with its _current_ version embedded across the app.
- I created single-responsibility hooks like
`useFindWorkflowWithCurrentVersion`, `useFindShowPageWorkflow`,
`useUpdateWorkflowVersionTrigger` or `useUpdateWorkflowVersionStep`.
- I updated the types for workflow related objects, like `Workflow` and
`WorkflowVersion`. See
`packages/twenty-front/src/modules/workflow/types/Workflow.ts`.
- This introduced the possibility to have `null` values for triggers and
steps. I made the according changes in the codebase and in the tests.
- I created a utility function to extract both parts of object-event
format (`company.created`):
`packages/twenty-front/src/modules/workflow/utils/splitWorkflowTriggerEventName.ts`
This PR adds the possibility of creating new steps. For now, only
actions are available. The steps are stored on the server, and the
visualizer is reloaded to include them.
Selecting a step opens the right drawer and shows its details. For now,
it's only the id of the step, but in the future, it will be the
parameters of the step.
In the future we'll want to let users add steps at any point in the
diagram. As a consequence, it's crucial to be able to walk in the tree
that make the steps to find the correct place where to put the new step.
I wrote a function that returns where the new step should be inserted.
This function will become recursive once we get branching implemented.
Things to mention:
- Reactflow needs every node and edge to have a unique identifier. In
this PR, I chose to use steps' id as nodes' id. That way, it's easy to
move from a node to a step, which helps make operations on a step
without resolving the step's id from the node's id.
