Commit Graph

4 Commits

Author SHA1 Message Date
Baptiste Devessier 5d1208f8af Set default zoom to workflows (#7331)
## Improvements

- This PR calls `fitView` when the Reactflow component inits. It tries
to fit the flow in a view with a fixed min and max zoom.
- Every time the WorkflowDiagramCanvas is rendered for a different
`workflowVersionId`, the `fitView` will be re-called. This is
implemented with a React `key`.
- The canvas will be re-rendered when an activated/deactivated version
is updated (and a new draft version is created.)
- It will also be re-rendered when the user selects another workflow
version and this doesn't cause the `WorkflowDiagramCanvas` component to
unmount. It happens if the user wants to go the previous or next
workflow or workflow version.

## Previous Behavior

![CleanShot 2024-09-30 at 10 32
06@2x](https://github.com/user-attachments/assets/ea43cd43-8c9c-491c-a535-8cca9168fb22)

## New Behavior

![CleanShot 2024-09-30 at 10 26
47@2x](https://github.com/user-attachments/assets/7bfb91b2-1782-47a1-ab5a-3eaa9f1be923)


https://github.com/user-attachments/assets/cb73f456-58b1-49c3-bd31-a1650810e9dd

## Notes

Closes #7047

This PR is a simplification of #7151. We'll have to improve the way we
manage zoom in another PR.
2024-09-30 11:24:57 +02:00
Baptiste Devessier e9f8e6e718 Display tag for workflow version status (#6972)
- Move where we fetch workflow data. We now fetch them in the `Workflow`
component directly. That's useful to access it in the
`WorkflowShowPageEffect` and `WorkflowDiagramCanvas` components.

![CleanShot 2024-09-10 at 16 27
53@2x](https://github.com/user-attachments/assets/7d30f407-31ab-472c-a096-c525042c0f35)
2024-09-13 11:25:07 +02:00
Baptiste Devessier 3548751be2 Scaffold empty workflow (#6926)
- Create a workflow version when the user visits an empty workflow.
- If the trigger is not defined yet and the user selects either the
standard object type or the event type first, we automatically select
the first option of the other value. Indeed, every state update is
automatically saved on the backend and we need both standard object and
event types to save the event name.
- Introduces a change in the backend. I removed the assertions that
throw when a workflow version is not complete, that is, when it doesn't
have a defined trigger, which is the case when scaffolding a new
workflow with a first empty workflow version.
- We should keep validating the workflow versions, at least when we
publish them. That should be done in a second step.
2024-09-12 17:01:10 +02:00
Baptiste Devessier a2b1062db6 Update workflow nodes configuration (#6861)
- 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`
2024-09-04 17:39:28 +02:00