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.
### ISSUE (BUG)
- Fixes: #6524
### DESCRIPTION
- List styles wasn't applying based on the theme, reason for applying
css to directly to **li** and **li strong** instead of applying to
unorderlist-element is that later on we might have **orderlist** in that
case if we had apply to **ul** here, this will issue will be raised
again, thus in **list element**
https://github.com/user-attachments/assets/64f0870e-4f82-4afd-8452-778aa54023fc
In this PR:
- adding Favorites to Tasks and Notes
- fixing inconsistencies between custom object creation and sync of
standard fields of custom objects
- fixing workspaceCacheVersion not used to invalidate existing
datasource
In this PR:
- refactoring auth module to extract a jwt module that can be re-used
from other part of the app (avoiding circular dependencies file module
=> auth => file (file and auth both need jwt actually)
- activating imageIdentfier on person on workspace creation (this will
put back the images on people)
- fixing picture upload (we were missing some fileToken)
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">
As per our guideline to maintain a smooth migration to the new minor
versions, this command is backfilling existing workspaces with the 3
userVars used to keep track of user onboarding:
```
ONBOARDING_CONNECT_ACCOUNT_COMPLETE = 'ONBOARDING_CONNECT_ACCOUNT_COMPLETE',
ONBOARDING_INVITE_TEAM_COMPLETE = 'ONBOARDING_INVITE_TEAM_COMPLETE',
ONBOARDING_CREATE_PROFILE_COMPLETE = 'ONBOARDING_CREATE_PROFILE_COMPLETE',
```
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>
Closes https://github.com/twentyhq/twenty/issues/5741
Filtering was already working.
I just added the required logic in the frontend to allow sorting by
primary link url (because label can be empty)
Fixes https://github.com/twentyhq/twenty/issues/5762
The problem was only happening with a sort on a select type field, also
appears with currency type and maybe other types.
This was because NULL values were sorted in a random order because the
sort function was comparing two NULL values as not equal, so I just
added a case for when A === B === NULL.
Introduced `updatedAt` column. and fix an existing bug where the field
edition page was crashing because we were trying to compute Date('now')
(param coming from the default value)
## Context
We recently introduced the new twenty ORM and used it in the update
methods in the query runner.
Initially we were using pg_graphql to fetch the record before updating
it allowing us to compare the before and the after and create a diff.
This diff is then used for the timeline activity creation. Now,
twentyORM is doing the fetch and pg_graphql is still doing the update
and their responses are not exactly the same, which means the diff is
not working as intended (e.g date types were always in the diff due to
one being in Date format and the other as a string)
This PR introduces a updatedFields property to the update event which
comes from the input. This is not ideal as this won't work for API users
that send the whole payload but will be sufficient enough for our FE
that only sends modified fields. We then compare only those fields in
the diff.
An ACTIVE workspace is a workspace that has a complete workspaceSchema
and is authorized to be browsed by users.
In this PR, I'm:
- introducing a new activationStatus: PENDING_CREATION (existing ACTIVE
/ INACTIVE)
- removing workspaceService.isWorkspaceActivated (based on
workspaceSchema existence which is not robust and checking
activationStatus.ACTIVE instead)
- removing dynamic activationStatus field on worksapce resolver (we can
use the postgres column directly now that data has been migrated)
- on user sign up creating the workspace in PENDING_CREATION, and on
workspace activation setting it to ACTIVE
- only re-activating a workspace if the current activationStatus is
INACTIVE through billing webhooks (a PENDING_CREATION should stay
PENDING and ACTIVE should stay ACTIVE)
- Add global listener on database event
- Fetch event listener associated
- Trigger associated workflow
Also updated the runner so it expects the input to be in the payload
rather than the trigger
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>
