# 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>
In this PR, I'm fixing two issues that we have faced:
- computing a rich text first line in case of the first block content is
not a text
- migrating existing timelineActivities tied to tasks / notes to
linked-tasks / linked-notes during migration command
In this PR I layout the first steps to migrate Activity to a traditional
Standard objects
Since this is a big transition, I'd rather split it into several
deployments / PRs
<img width="1512" alt="image"
src="https://github.com/user-attachments/assets/012e2bbf-9d1b-4723-aaf6-269ef588b050">
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
Co-authored-by: bosiraphael <71827178+bosiraphael@users.noreply.github.com>
Co-authored-by: Weiko <corentin@twenty.com>
Co-authored-by: Faisal-imtiyaz123 <142205282+Faisal-imtiyaz123@users.noreply.github.com>
Co-authored-by: Prateek Jain <prateekj1171998@gmail.com>
- Add optional description field to webhook page in developer settings.
Fix https://github.com/twentyhq/twenty/issues/6236
---------
Co-authored-by: Thomas Trompette <thomas.trompette@sfr.fr>
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 issue was caused due to last comomit on issue by me only
fix_6127/support_button_updated
I had fixed the chat opening problem , in this commit
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
@Bonapara
Issue #6325
- Desired Behavior
The navigation should always be visible. Clicking on a Next/Previous
arrow should immediately increment the number without switching to the
skeleton loading step.
**Done**
Please let me know what do you think about this approach.
Thanks :)
https://github.com/user-attachments/assets/bda3608f-87e3-45bd-a7c8-4a6b48391cf2
Co-authored-by: Weiko <corentin@twenty.com>
Co-authored-by: martmull <martmull@hotmail.fr>
Closes#6255
- Move files from `messaging/common` into the correct module
- Remove common module between calendar and messaging
`calendar-messaging-participant-manager`
- Update and fix massaging and calendar participant matching
- Create `MatchParticipantModule`
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
- Throw service error from query runner
- Catch in resolver factories
- Map to graphql errors
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
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>
