Fixes issue #6487
Added a new prop, `isInRightDrawer` to both the `ShowPageSummaryCard`
and `ShowPageRightContainer` components. This prop allows for different
styles to be applied based on the specific needs of the drawer..
Rather than creating a new component, I opted to add this prop to avoid
code duplication. However, if you would prefer a separate component for
this functionality, I'm happy to make that adjustment—please just let me
know!
Also added `box-sizing: border-box` to `ShowPageSummaryCard` to make
sure it aligns with figma designs.
https://github.com/user-attachments/assets/38e8d85e-55d5-471e-884a-11c67467f56f
This PR introduces the following changes:
- Add the ability to filter webhooks by objectSingularName and Actions
- Refactor SettingsWebhookDetails edition to not use react-hook-form
(which will be deprecated on the whole project)
- Updating the tests with a complex set of mock (we just need to fix ~30
of them now :D)
<img width="1053" alt="image"
src="https://github.com/user-attachments/assets/4e56d972-f129-4789-8d1c-4b5797a8ffd7">
Hi @FelixMalfait,
Regarding Issue #6278
I’ve resolved the issue with fields involving numbers and text.
However, I’ve encountered a problem with how dates are parsed, selected,
and displayed. When a date is selected for the first time, it is
correctly parsed and adjusted to the local timezone (e.g., 05:30:00 AM
for my timezone). However, when trying to change the date, the day prior
to the selected date is shown instead of the intended date. Please refer
to the attached video for a demonstration of this bug.
I suspect this issue is related to how the date is parsed and selected
in relation to timezones, and I am currently investigating it further.
Could you please review the changes made so far?
Thanks!
https://github.com/user-attachments/assets/4f0e5694-530b-489c-807e-3b7d52da0742
---------
Co-authored-by: Weiko <corentin@twenty.com>
@lucasbordeau
Issue #6374
Fixed the navigation state issue! I also found and resolved a similar
bug with the "Edit Fields" functionality. The
`setNavigationMemorizedUrl` state now correctly updates on navigation to
settings, ensuring users return to the correct page.
Please review.
In this PR, I'm:
- adding createdBy field (type ACTOR) on custom objects when created
- moving `name` and `position` default column to the set of columns
automatically creation on object creation
- fixing a bug on mutations (update / create), if the targetted object
has a 'data' custom field, it was conflicting with the payload ==> I
feel we need to refactor this part of the code but we can keep this for
a bit later as we plan to move out of pg_graphql
<img width="1198" alt="image"
src="https://github.com/user-attachments/assets/891c4a97-bab1-415c-8551-dabd5996a794">
Closes#6434.
We don't want to override the values of the records' address or links as
they are composite field and it is costly to loose the data.
We will need a more unified behaviour here - maybe introduce a Ctrl+Z
option.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
When migrating the option values of a select type, if the field is non
nullable (for now, only available for opportunity's "stage" standard
field), we fallback to the (potentially updated) default value instead
of nullifying the value to avoid getting a database error.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
This pull request introduces a new `FieldMetadataType` called `ACTOR`.
The primary objective of this new type is to add an extra column to the
following objects: `person`, `company`, `opportunity`, `note`, `task`,
and all custom objects.
This composite type contains three properties:
- `source`
```typescript
export enum FieldActorSource {
EMAIL = 'EMAIL',
CALENDAR = 'CALENDAR',
API = 'API',
IMPORT = 'IMPORT',
MANUAL = 'MANUAL',
}
```
- `workspaceMemberId`
- This property can be `undefined` in some cases and refers to the
member who created the record.
- `name`
- Serves as a fallback if the `workspaceMember` is deleted and is used
for other source types like `API`.
### Functionality
The pre-hook system has been updated to allow real-time argument
updates. When a record is created, a pre-hook can now compute and update
the arguments accordingly. This enhancement enables the `createdBy`
field to be populated with the correct values based on the
`authContext`.
The `authContext` now includes:
- An optional User entity
- An optional ApiKey entity
- The workspace entity
This provides access to the necessary data for the `createdBy` field.
In the GraphQL API, only the `source` can be specified in the
`createdBy` input. This allows the front-end to specify the source when
creating records from a CSV file.
### Front-End Handling
On the front-end, `orderBy` and `filter` are only applied to the name
property of the `ACTOR` composite type. Currently, we are unable to
apply these operations to the workspace member relation. This means that
if a workspace member changes their first name or last name, there may
be a mismatch because the name will differ from the new one. The name
displayed on the screen is based on the workspace member entity when
available.
### Missing Components
Currently, this PR does not include a `createdBy` value for the `MAIL`
and `CALENDAR` sources. These records are created in a job, and at
present, we only have access to the workspaceId within the job. To
address this, we should use a function similar to
`loadServiceWithContext`, which was recently removed from `TwentyORM`.
This function would allow us to pass the `authContext` to the jobs
without disrupting existing jobs.
Another PR will be created to handle these cases.
### Related Issues
Fixes issue #5155.
### Additional Notes
This PR doesn't include the migrations of the current records and views.
Everything works properly when the database is reset but this part is
still missing for now. We'll add that in another PR.
- There is a minor issue: front-end tests are broken since this commit:
[80c0fc7ff1).
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
This PR fixes two bugs:
- A broken link to the task page that had been left on the mobile
version
- On Kanban cards, the badge for notes/tasks wasn't properly displayed
because the title wasn't loaded from the backend
# Feature: Email thread members visibility
For this feature we implemented a chip and a dropdown menu that allows
users to check which workspace members can see an email thread, as
depicted on issue (#4199).
## Implementations
- create a new database table (messageThreadMember)
- relations between `messageThreadMembers` and the relevant existing
tables (`MessageThread` and `WorkspaceMembers`)
- added a new column to the `MessageThread table`: `everyone` - to
indicate that all workspace members can see the email thread
- create a new repository for the new table, including new queries
- edit the queries so that the new fields could be fetched from the
frontend
- created a component `MultiChip`, that shows a group of user avatars,
instead of just one
- created a component, `ShareDropdownMenu`, that shows up once the
`EmailThreadMembersChip` is clicked. On this menu you can see which
workspace members can view the email thread.
## Screenshots
Here are some screenshots of the frontend components that were created:
Chip with everyone in the workspace being part of the message thread:

Chip with just one member of the workspace (the owner) being part of the
message thread:

Chip with some members of the workspace being part of the message
thread:

How the chip looks in a message thread:

Dropdown that opens when you click on the chip:

## Testing and Mock data
We also added mock data (TypeORM seeds), focusing on adding mock data
related to message thread members.
## Conclusion
As some of the changes that we needed to do, regarding the change of
visibility of the message thread, were not covered by the existing
documentation, we were told to open a PR and ask for feedback on this
part of the implementation. Right now, our implementation is focused on
displaying who is part of an email thread.
Feel free to let us know which steps we should follow next :)
---------
Co-authored-by: Simão Sanguinho <simao.sanguinho@tecnico.ulisboa.pt>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Implement date formatting per workspace member settings
We'll need another round to maybe initialize all workspaces on the
default settings.
For now the default behavior is to take system settings if nothing is
found in DB.
---------
Co-authored-by: Weiko <corentin@twenty.com>
Closes#6431
- create new field `activationStatus`
- create migration commands
- add logic to update `activationStatus` on workspace activation and on
stripe subscriptionStatus change
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
In this PR, I am:
- removing a useEffect (we use the onCompleted prop of useFindManyQuery
hook)
- moving this logic into a RecordShowPageHeader to avoid re-renders of
the whole tree
This PR was created by [GitStart](https://gitstart.com/) to address the
requirements from this ticket:
[TWNTY-4238](https://clients.gitstart.com/twenty/5449/tickets/TWNTY-4238).
This ticket was imported from:
[TWNTY-4238](https://github.com/twentyhq/twenty/issues/4238)
---
## Description
- We moved the filter from RecordIndexContainer to RecordBoardCard, this
change will fix the fix issue that the name column was not visible in
Kanban view and will keep the behavior in the Kanban card. The options
dropdown uses the same state that the card uses, but the name is
rendered on the card because, for the name field, the card uses another
data because the render of the name is different from the render of the
other fields, so we removed the filter in the state, but we need to
filter only in the card to avoid duplicated data, we could not find any
other case that this filter is useful for another component
- We updated the type in RecordBoardFieldDefinition to fix TS error in
RecordBoardCard file
### Demo
<https://jam.dev/c/7c9db8e1-9b53-49cf-a44c-0b0fec5b1988>
### Refs
- #4238Fixes#4238
Co-authored-by: gitstart-twenty <gitstart-twenty@users.noreply.github.com>
Adding support for all Composite Fields while using the "import"
functionality. This includes:
- Currency
- Address
Edit :
- Refactored a lot of types in the spreadsheet import module
- Renamed a lot of functions, hooks and types that were not
self-explanatory enough
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
This pull request addresses an issue where the delete button, placed
closely to the export button, could lead to accidental deletions without
confirmation. The problem was that the confirmation modal for the delete
action, being the second action, was not displayed. The code was updated
to map all action bar entries and display their respective confirmation
modals correctly.
### Changes Made:
- Updated the rendering of action bar entries to ensure all confirmation
modals are shown.
Changed from displaying only the first action bar entry's confirmation
modal to mapping through all entries and displaying each modal if it
exists.
- Removed the delete from the onClick because it is present in the
onConfirmClick.
### Description
Resolves Issue: [https://github.com/twentyhq/twenty/issues/6224](#6224)
### Additional Consideration
I have changed the default start rating value from 1 star to no star
since clicking on the selected start was reverting the filed to 1 star
which didn't seem like the appropriate behaviour. Let me know if this
change is fine
---------
Co-authored-by: JosephAshwin23 <joseph.sanjivi@anywhere.co>
Co-authored-by: Thomas Trompette <thomas.trompette@sfr.fr>
- Removed enabled props from useScopedHotkeys becayse it doesn't work
- Moved enter useScopedHotkeys in a handler that we drill down to the
text inputs on the settings form
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
This PR aims to fix#6102
I think we should dicuss a bit about how we should manage the lenght and
set the variables globally
Edit :
@RobertoSimonini1 I used this PR to fix various problems that were left
unsolved :
- Refactor TextDisplay component, EllipsisDisplay was redundant with
OverflowingTextWithTooltip
- Removed maxWidth on TextDisplay for all other components, as it wasn't
the right way to do it, the parent container should be responsible for
width not the TextDisplay (code smell)
- Drilled-down isCentered to respect its intent in the RecordInlineCell
display of the record show page title
- Fixed RecordInlineCellEditMode so that the portal is well centered
above the record show page title
- Fixed DoubleTextInput width so that it expands normally and takes all
its parent available space.
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>