This PR removes useRecordTable barrel-hook and instead use the pattern
that enforces one hook per function.
This allows to have a easier to maintain React code with small dedicated
hooks.
This PR also improves the usage of those hooks by cleaning some logic
that calls them.
We introduce a new hook : `useRecordIndexIdFromCurrentContextStore` that
factorizes logic that was duplicated to retrieve the `recordTableId`.
Introduced `useHandleColumnsChange`, that saves table columns into view,
this could be discussed but is it isolated with a TODO comment so ok for
now.
Also lowered the coverage because not enough to cover with test here.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
This PR updates the subtitle under the "Endpoint URL" input on the
webhook creation form.
The updated text clearly states that the server sends POST requests with
application/json and recommends setting the correct Content-Type.
This addresses issue #13757.
Closes#13757
---------
Co-authored-by: Charles Bochet <charlesBochet@users.noreply.github.com>
Co-authored-by: ehconitin <nitinkoche03@gmail.com>
This PR removes the unintended line break in all IMAP section subtitles
so the text reads as a single inline paragraph.
✅ No functional changes
✅ Purely UI/text formatting fix
Closes#13783
Co-authored-by: Charles Bochet <charles@twenty.com>
In this PR, we add some validation logic and rules in both FE and BE to
ensure field permissions are handled correctly for relation fields.
- (BE) Only one field permission per fieldMetadata is accepted per
input. This is already guaranteed in the FE. It was added to help
guarantee that, when looking within the field permissions input for a
potential field permission on a relationTargetFieldMetadataId for a
relation field, there can only be 0 or 1.
- (FE) Only field permission with new values are sent to save, to avoid
sending contradictory field permissions for related fields. E.g. let's
say I have an existing field permission restricting read permission on
company's people field. By definition I also have one on person's
company field. If I update this field permission to enable the read
permission by updating company's people field, in the previous logic I
was also going to send for upsert the existing obsolete field permission
on person's company. Thus the server does not know which is the right
value so we should only send the new value.
- (BE) If the server receives two contradictory field permissions on two
related fields, e.g. on company's people with canRead = null and
person's company with canRead = false, it throws an error.
In this PR
- Introduction of readableFields and updatableFields in
objectMetadataItem selector to ease filtering from a developer
experience perspective ( + to help developers think to do it). In
discussion @lucasbordeau @charlesBochet
- Remove non-updatable field from CSV import process (@etiennejouan)
- QA fix / Non-readable fields should not show on show page
- QA fix / It should not be offered to create a kanban view on a
non-readable field
- QA fix / It should not be offered to create view groups on a
non-readable field
- QA fix / Rating field should have a readonly mode
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
## Before
https://github.com/user-attachments/assets/5f89e2c5-af59-46eb-a0af-6eb0ab103291
## After
https://github.com/user-attachments/assets/11accdc5-a49c-4479-8686-b01f44519d81
## The issue
`getStepDefinitionOrThrow` throws if the provided `steps` aren't
defined. With my recent refactor, the side panel is opened immediately,
as we no longer open it in the `useOnSelectionChange` hook. We use a
`useEffect` to set the `flowState` whenever the workflow version
definition changes. As the side panel is now opened faster,
`getStepDefinitionOrThrow` throws before the `flowState` could have been
set.
In this PR, I only fixed the bug I encountered. We might want to replace
the synchronization `useEffect` with explicit `setFlow` calls whenever
we change the workflow version.
In this PR:
- refactor timelineActivity computation to batch it
- make sure to pass the authContext to insert-query-builder in order to
pass user information to timelineActivity
- refactor message-participant /calendar-participant creation to batch
more
- fix favorite on view race condition (FE)
- deprecate PARTIAL_CALENDAR_EVENT_FETCH_LIST syncStage as we will
deprecate partial vs full notion (we will just leverage cursor emptyness
or not)
- introduce calendar / messging SCHEDULED syncStage that will allow
better performance granularity later
- activate quick message import after message list fetch to speed
performance on small message lists
This PR cleans a few parts of the workflow features and fixes a few
improper behaviors.
Here is a non-exaustive list of improved things:
- Clicking on an action will always reset the command menu's navigation
stack. Previously, the behavior wasn't unified between workflows,
workflow versions and workflow runs.
- Opening a step in the side panel is now down in the `onClick` event
handler put on individual Reactflow nodes. This makes interoperability
between filters (which are buttons on edges) and traditional actions.
- Simplified the code that automatically opens pending forms in the side
panel. This feature should now work more predictably.
- Splitted the `WorkflowDiagramEmptyTrigger` component into
`WorkflowDiagramEmptyTriggerEditable` and
`WorkflowDiagramEmptyTriggerReadonly`. This makes handling events easier
as the behavior isn't the same in both cases.
- Dropped all `useOnSelectionChange` hooks that were used to open steps
in the side panel upon user selection.
- Created a specific `WorkflowRunDiagramStepNode` instead of using
`WorkflowDiagramStepNodeReadonly` in `WorkflowRunDiagramCanvas`
- Deleted `useHandleWorkflowRunDiagramCanvasInit` as it was used to open
the initially selected step in the command menu, which is now handled in
an effect that works for all cases, including workflow run's state
refreshing.
Closes https://github.com/twentyhq/core-team-issues/issues/1227
Closes https://github.com/twentyhq/twenty/issues/11923
This PR fixes a bug that appeared because of a race condition with
context store when navigating between settings page and show page.
The bug was caused because record title cell used on record show page
was trying to retrieve the object metadata item before the context store
was initialized.
I created a new hook that supports an undefined state for one render
loop, since in that case components can be rendered before the context
store is initialized.
Fixes https://github.com/twentyhq/twenty/issues/13649
This PR removes any V2 naming in state management logic and some minor
utils and hooks.
It has a lot of changes but nearly all of them were made by the rename
functionality of vscode which is deterministic, so it shouldn't
introduce any regression.
QA has been made on this PR on the main features of the app without any
noticeable issue.
Also renamed some other v2 naming related items :
- TextInputV2 => TextInput
- TextInput => SettingsTextInput
- ObjectFilterDropdownFilterSelectMenuItemV2 =>
ObjectFilterDropdownFilterSelectMenuItem
- useInitDraftValueV2 => useInitDraftValue
- useOpenRecordTableCellV2 => useOpenRecordTableCell
In this PR:
- fix race condition while getting token and redirecting to workspace
domain (missing await)
- add userFriendlyMessage when user does not have password and we try to
log in using password
- refactor computePartialUserFromUserPayload to remove side effect
- add isEmailAlreadyVerified in userPayload that will set
user.isEmailVerified to true
This PR implements what's needed to edit field permissions on a role.
Field permissions that aren't useful are kept in the database to avoid
the overhead of adding cleaning logics both in front end and back end.
They just won't be taken into account if object permission doesn't allow
it.
In this PR we also handle the case were there's no object permission
override but where there are only field permission overrides, which can
happen if an object inherits from a "all object can read" but restricts
read only on some fields.
<img width="547" height="642" alt="image"
src="https://github.com/user-attachments/assets/77d81f89-4af9-42b6-97f3-fae3a6ba1eeb"
/>
<img width="590" height="912" alt="image"
src="https://github.com/user-attachments/assets/69fab8ee-7252-401a-bc6f-8a8b7c7f6bc4"
/>
Fixes https://github.com/twentyhq/core-team-issues/issues/1152
This PR lowers unit test coverage because the essential unit tests for
this PR have been written and writing more tests would not be a great
tradeoff for this feature which has already taken a lot of efforts.
Health status queries are failing at the moment - regression was
introduced in 01f25519f6
health status ids are not uuids, we use params to fetch them on the
frontend.
But maybe @FelixMalfait and @abdulrahmancodes have more context on this
one?
