# 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>
* fix: state consistency issue while closing the email thread right drawer (#4205)
* Refactored to use useRecoilCallback in RightDrawer open/close hook
* - registered an email drawer click outside callback to memorize the thread id when drawer was closed
- added a state to memorize then event that triggered right drawer close
- added a predicate that checks if event that close email thread right drawer is not the same that the open email thread click event AND that the thread that we want to open is not the thread that is just being closed.
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
* Use recoil state for page info
* Remove memoization
* Remove right drawer fetch more loader
---------
Co-authored-by: Thomas Trompette <thomast@twenty.com>
* wip
* wip
* add pagination
* wip
* wip
* wip
* update resolver
* wip
* wip
* endpoint is working but there is still work to do
* merge main
* wip
* subject is now first subject
* number of messages is working
* improving query
* fix bug
* fix bug
* added parameter
* pagination introduced a bug
* pagination is working
* fix type
* improve typing
* improve typing
* fix bug
* add displayName
* display displayName in the frontend
* move entities
* fix
* generate metadata
* add avatarUrl
* modify after comments on PR
* updates
* remove email mocks
* remove console log
* move files
* remove mock
* use constant
* use constant
* use fragments
* remove console.log
* generate
* changes made
* update DTO
* generate
* Fetch messages with hard coded thread id
* Fix test
* Use first workspace member or person names
---------
Co-authored-by: Thomas Trompette <thomast@twenty.com>
* Adding message thread component
* Add state and mocks
* Rename components and use local state for messages
---------
Co-authored-by: Thomas Trompette <thomast@twenty.com>
* Trigger message thread top bar
* Rename message thread to thread
* Move all components in a directory
---------
Co-authored-by: Thomas Trompette <thomast@twenty.com>
