- Removed disableBlur property from dropdown because it is no longer
needed since there's only one OverlayContainer component so there can be
only one blur at a time.
- Removed blur CSS properties from every component that used it because
one standalone OverlayContainer is able to handle all cases if placed
properly.
- Also removed disableBackgroundBlur property from SingleRecordSelect
- Removed FieldInputOverlay and FieldTextAreaOverlay components that
were a first attempt to create something like an OverlayContainer
- Used new unified OverlayContainer in RecordInlineCell and
RecordTableCell
- Fixed ScrollWrapper so that it works well both for dropdown with non
overflowing content and dropdown with overflowing content.
- Removed export default value on SearchVariablesDropdown as it is not
used in this codebase
- Refactored SearchVariablesDropdown function as component anti-pattern
- Refactored SearchVariablesDropdownFieldItems UI problems with
separator and missing ScrollWrapper behavior
- Refactored SearchVariablesDropdownObjectItems with UI problems with
separator and missing ScrollWrapper behavior
- Fixed blur bug on Firefox due to wrong placement of the element that
had the CSS property. Blur works on Firefox it it's on the container
that has the highest level in the tree.
- Fixed bug in ActivityTargetInlineCell by removing an unnecessary
container component StyledSelectContainer
- Unified problems of field height with a new common component
FieldInputContainer, instead of putting width and height at the wrong
abstraction level, width and height are a field's concern not a
dropdown, overlay or low-level input concern.
- Fixed block editor dropdown with new OverlayContainer
- Aligning field dropdown with their anchor on inline and table cells,
there are still many small pixel misalignments that give a low quality
impression.
- Fixed FormDateFieldInput that was missing OverlayContainer
Having a global record crud action adds complex logic.
We decided to split those actions. I only kept a common folder / module
in backend.
⚠️ this may break existing workflows if these were using previous
actions!
Output schema is now separated in two sections:
- object, that gather all informations on the selectable object
- fields, that display object fields in a record context, or simply the
available fields from the previous steps
The dropdown variable has now a new mode:
- if objectNameSingularToSelect is defined, it goes into an object mode.
Only objects of the right type will be shown
- if not set, it will use the already existing mode, to select a field
When an object is selected, it actually set the id of the object
https://github.com/user-attachments/assets/1c95f8fd-10f0-4c1c-aeb7-c7d847e89536
Implemented the following actions for the workflows:
- Test Workflow
- Discard Draft
- Activate Draft
- Activate Workflow Last Published Version
- Deactivate Workflow
- See Workflow Executions
- See Workflow Active Version
- See Workflow Versions History
And the following actions for the workflow versions:
- Use As Draft
- See Workflow Versions History
- See Workflow Executions
Video example:
https://github.com/user-attachments/assets/016956a6-6f2e-4de5-9605-d6e14526cbb3
A few of these actions are links to the relations of the workflow object
(link to a filtered table). To generalize this behavior, I will create
an hook named `useSeeRelationsActionSingleRecordAction` to automatically
generate links to a showPage if the relation is a Many To One or to a
filtered table if the relation is a One to Many for all the record
types.
I will also create actions which will allow to create a relation.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
- create a serverless function when creating a new workflow code step
- add code editor in workflow code step
- move workflowVersion steps management from frontend to backend
- add a custom resolver for workflow-version management
- fix optimistic rendering on frontend
- fix css
- delete serverless function when deleting workflow code step
TODO
- Don't update serverlessFunction if no code change
- Factorize what can be between crud trigger and crud step
- Publish serverless version when activating workflow
- delete serverless functions when deleting workflow or workflowVersion
- fix optimistic rendering for code updates
- Unify CRUD types
<img width="1279" alt="image"
src="https://github.com/user-attachments/assets/3d97ee9f-4b96-4abc-9d36-5c0280058be4">
- Refactor VariableTagInput to have a reusable low-level TipTap editor
- Create three primitive form fields:
- Text
- Number
- Boolean
## Notes
- We should automatically recognize the placeholder to use for every
FormFieldInput, as it's done for FieldInputs.
## Design decisions
Our main challenge was for variables and inputs to be able to
communicate between each other. We chose an API that adds some
duplication but remains simple and doesn't rely on "hacks" to work.
Common styles are centralized.
## Demo
"Workflow" mode with variables:
FormFieldInput mode, without variables:
Behavior difference between fields that can contain variables and static
content, and inputs that can have either a variable value or a static
value:
In this PR:
- Ensure the `setNestedValue` does a deep copy of the provided object
and doesn't mutate it directly.
- Store the form's state in a `useState` instead of relying entirely on
the backend's state. This makes the form more resilient to slow network
connections.
- Ensure the input settings are reset when selecting another function.
- The Inner component now expects the serverless functions data to be
resolved before being mounted, so I split it.
Closes https://github.com/twentyhq/twenty/issues/8523
- Increase the dimensions of the ReactFlow nodes. This allows to ditch
scaling which made it hard to get the width of the nodes as they were
visually scaled by 1.3.
- Center the flow when the flow mounts and when the state of the right
drawer opens.
- Put the node type inside of the node so it doesn't overlap with the
arrow
- Make the edges non deletable
We'll have to make a refactor so the viewport can be animated properly:
https://github.com/twentyhq/twenty/issues/8387.
https://github.com/user-attachments/assets/69494a32-5403-4898-be75-7fc38058e263
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
Implemented:
* Account Connect
* Calendar sync via delta ids then requesting single events
I think I would split the messaging part into a second pr - that's a
step more complex then the calendar :)
---------
Co-authored-by: bosiraphael <raphael.bosi@gmail.com>
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>
- add `inputSchema` column in serverless function. This is an array of
parameters, with their name and type
- on serverless function id update, get the `inputSchema` + store empty
settings in step
- from step settings, build the form
TODO in next PR:
- use field type to decide what kind of form should be printed
- have a strategy to handle object as input
https://github.com/user-attachments/assets/ed96f919-24b5-4baf-a051-31f76f45e575
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
In this PR:
- Allow the `<ConfirmationModal />` to take additional buttons to
display between the cancel and the confirm buttons.
- Create a modal that's displayed when the user tries wants to use a
workflow version as draft while a draft version already exists. The
displayed modal contains a link to the current draft version and a
button to confirm the overriding of the current draft version.
A demo:
https://github.com/user-attachments/assets/6349f418-1b11-45b3-9f5e-061ca74c2966Closestwentyhq/private-issues#114
- update `send-email.workflow-action.ts` so it send email via the google
sdk
- remove useless `workflow-action.email.ts`
- add `send` authorization to google api scopes
- update the front workflow email step form to provide a
`connectedAccountId` from the available connected accounts
- update the permissions of connected accounts: ask users to reconnect
when selecting missing send permission
In this PR:
- Refactored components to clarify their behavior. For example, I
renamed the `Workflow` component to `WorkflowVisualizer`. This moved
forward the issue #7010.
- Create two variants of several workflow-related components: one
version for editing and another for viewing. For instance, there is
`WorkflowDiagramCanvasEditable.tsx` and
`WorkflowDiagramCanvasReadonly.tsx`
- Implement the show page for workflow versions. On this page, we
display a readonly workflow visualizer. Users can click on nodes and it
will expand the right drawer.
- I added buttons in the header of the RecordShowPage for workflow
versions: users can activate, deactivate or use the currently viewed
version as the next draft.
**There are many cache desynchronisation and I'll fix them really
soon.**
## Demo
(Turn sound on)
https://github.com/user-attachments/assets/97fafa48-8902-4dab-8b39-f40848bf041e
- Allows the deletion of triggers and steps in workflows. If the
workflow can not be edited right now, we create a new draft version.
- The workflow right drawer can now render nothing. It's necessary to
behave that way because a deleted step will still be displayed for a
short amount of time in the drawer. The drawer will be filled with blank
content when it disappears.
https://github.com/user-attachments/assets/abd5184e-d3db-4fe7-8870-ccc78ff23d41Closes#7057
- Add the SAVE_EMAIL action. This action requires more setting
parameters than the Serverless Function action.
- Changed the way we computed the workflow diagram. It now preserves
some properties, like the `selected` property. That's necessary to not
close the right drawer when the workflow back-end data change.
- Added the possibility to set a label to a TextArea. This uses a
`<label>` HTML element and the `useId()` hook to create an id linking
the label with the input.
## 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
## New Behavior
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.
## Setup
This PR can be tested only if some feature flags have specific values:
- `IsWorkflowEnabled` equals `true`
- `IsQueryRunnerTwentyORMEnabled` equals `false`
These feature flags weren't committed to don't break other branches.
## What this PR brings
- Display buttons to activate and deactivate a workflow version and a
button to discard the current draft version. I also scaffolded a "Test"
button, which doesn't do anything for now.
- Wired the activate, deactivate and discard draft buttons to the
backend.
- Made it possible to "edit" active and deactivated versions by
automatically creating a new draft version when the user tries to edit
the version.
- Hide the "Discard Draft", button if the current version is not a draft
or is the first version ever created.
- On the backend, don't consider discarded drafts when checking if a new
draft version can be created.
- On the backend, disallow deleting the first created workflow version.
Otherwise, we will end up with a blank canvas in the front end, and it
will be impossible to recover from it.
- On the backend, disallow running deactivation steps if the workflow
version is not currently active. Previously, we were throwing, which is
unnecessary as it's a valid case.
## Spotted bugs that we must dive into
### Duplicate workflow versions in Apollo cache
https://github.com/user-attachments/assets/7cfffd06-11e0-417a-8da0-f9a5f43b84e2
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
- 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.
