This PR is preparing states to we'll be able to handle view groups
correctly with table data.
RowIds are now stores in 2 component states, one storing ids by view
group and another storing all the rowIds.
We're doing that because some other state like focus, or select must not
be scoped by view group id.
This PR adds "type" to the reserved keywords list in
validate-object-metadata-input.util.ts. This prevents users from
creating objects with "type" as a key, which has caused issues in the
past .
issue solved #8543
1.Updated the RESERVED_KEYWORDS array to include "type"
---------
Co-authored-by: Weiko <corentin@twenty.com>
Fixes: #8531
1. Summary
There is `onClick` event handler defined for `NavigationDrawerItem`
component, and inside the handler, if `to` is not empty, we trigger
another navigation when it's already handled by `Link` component from
`react-router-dom`
2. Solution
Removed extra navigation logic from `NavigationDrawerItem`'s `onClick`
handler
3. Screen Recording
https://github.com/user-attachments/assets/cfefdd51-1663-4d96-acd2-57783ae9877f
# Description
Closes#8169
Extract Add New button from entitiesToSelect and add it as a separate
element .
There doesn't seem to be a point in having Add New as part of a list, it
seems better off in its own component, apart from list items
## Rationale
There already is #8353 addressing the same issue, but it seems it
doesn't really remove the duplicate "Add New" in the list, leaving a
duplicate "Add New" in `SingleEntitySelect`
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
The `QueryResultGettersFactory` that is called on every query return to
was called only on the first level of relations because recursivity
wasn't implemented.
In this PR I implement recursivity and add some typing for the possible
forms a GraphQL query field can take.
This PR will fix any issue we have with pictures that were losing their
token (here for person.avatarUrl)
Fixes https://github.com/twentyhq/twenty/issues/8425
Fixes https://github.com/twentyhq/twenty/issues/8498
---------
Co-authored-by: Weiko <corentin@twenty.com>
We will remove the `twenty-postgres` image that was used for local
development and only use `twenty-postgres-pilo` (which we use in prod),
bringing the development environment closer to prod and avoiding having
to maintain 2 images.
Instead of provisioning the super user after the db initialization, we
directly rely on the superuser provided by Spilo for simplicity. We also
introduce a change that tries to create the right database (`default` or
`test`) based on the context.
How to test:
```
docker build -t twentycrm/twenty-postgres-spilo:latest -f ./packages/twenty-docker/twenty-postgres-spilo/Dockerfile .
docker images --no-trunc | grep twenty-postgres-spilo
postgres-on-docker:
docker run \
--name twenty_pg \
-e PGUSER_SUPERUSER=twenty \
-e PGPASSWORD_SUPERUSER=twenty \
-e ALLOW_NOSSL=true \
-v twenty_db_data:/home/postgres/pgdata \
-p 5432:5432 \
REPLACE_WITH_IMAGE_ID
```
First step of https://github.com/twentyhq/twenty/issues/6868
Adds min.., max.. queries for DATETIME fields
adds min.., max.., avg.., sum.. queries for NUMBER fields
(count distinct operation and composite fields such as CURRENCY handling
will be dealt with in a future PR)
<img width="1422" alt="Capture d’écran 2024-11-06 à 15 48 46"
src="https://github.com/user-attachments/assets/4bcdece0-ad3e-4536-9720-fe4044a36719">
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
Co-authored-by: Weiko <corentin@twenty.com>
fix#8204
I changed "API keys" to "API values".
Stopped inputting special characters in Select field option keys.
@lucasbordeau please check the changes and tell me if I need to do any
other changes. :)
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
This is the result of a long discussion we had here:
https://github.com/twentyhq/twenty/issues/8001.
The goal is to stop iOS from automatically zooming when the user focuses
on an input whose font size is less than 16px.
The options were:
1. Disable zoom for all devices
2. Disable zoom for devices detected as iOS devices, which doesn't
prevent users from zooming manually but fixes the auto-zoom bug
3. Set the font size of the inputs to be equal to or greater than
16px—this change would take a lot of time
To me, the second option is the best, as iOS prevents developers from
disabling zoom. They saw that it was overused and chose to restrict this
setting. Setting a `maximum-scale` doesn't prevent users from zooming,
but it fixes the initial bug we had.
My implementation can be seen as [progressive
enhancement](https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement
): If we can detect that the user uses an iOS device, we'll set the
`maximum-scale` viewport property. Relying on the user agent is always
unstable, and the check might fail unpredictably. We might not disallow
auto-zoom for some iOS devices.
However, I think we can either:
- Invest some time to choose a more reliable user detection pattern if
the one I suggest is not sufficient ([we find many different checks on
the
internet](https://stackoverflow.com/questions/9038625/detect-if-device-is-ios),
I'm not sure which one is the best)
- Choose to apply the viewport setting to all devices and remove the JS
code. According to my tests, it doesn't prevent zooming on desktops.
However, it does on Android phones. I think it's not lovely to disallow
zoom, but if the team agrees that we should go this way, I won't
disagree.
I know my JavaScript code does not follow a pattern we want to spread in
the app. The synchronous script will run as soon as possible to ensure
the viewport is correctly set when the website launches. This shouldn't
be an example followed by others.
Thanks, @harshit078, for your help in thinking about the best option.
I'm tagging @lucasbordeau and @charlesBochet for a technical review.
I would appreciate if someone could test on a more recent iOS device
than mine.
Here is a demonstration of the behavior on iOS:
https://github.com/user-attachments/assets/d49fb65f-dd76-455c-9ac0-d4c002a7fe89
