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
- Increase the dimensions of the ReactFlow nodes. This allows to ditch
scaling which made it hard to get the width of the nodes as they were
visually scaled by 1.3.
- Center the flow when the flow mounts and when the state of the right
drawer opens.
- Put the node type inside of the node so it doesn't overlap with the
arrow
- Make the edges non deletable
We'll have to make a refactor so the viewport can be animated properly:
https://github.com/twentyhq/twenty/issues/8387.
https://github.com/user-attachments/assets/69494a32-5403-4898-be75-7fc38058e263
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
FIX: #6977
Implementation:
1. Parent (Summary componenet) width is set to 100%. (dosen't grow even
if the child exceeds width)
2. span element is set to `text-overflow: ellipses` when overflown.
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
- Create a new component state `contextStoreFiltersComponentState` and
refactor `contextStoreTargetedRecordsRuleComponentState`
- Refactor `computeContextStoreFilters` to use filters when no records
are selected
- Use a label to make the whole card interactive
- Disallow the Toggle component to shrink; it used to on mobile devices
A focus indicator is missing for the Toggle component. We'll have to add
one.
**TLDR**
Refactor WebhoonAnalytics Graph to a more abstract version
AnalyticsGraph (in analytics module). Thus enabling the components to be
used on different instances (ex: new endpoint, new kind of graph).
**In order to test:**
1. Set ANALYTICS_ENABLED to true
2. Set TINYBIRD_JWT_TOKEN to the ADMIN token from the workspace
twenty_analytics_playground
3. Set TINYBIRD_JWT_TOKEN to the datasource or your admin token from the
workspace twenty_analytics_playground
4. Create a Webhook in twenty and set wich events it needs to track
5. Run twenty-worker in order to make the webhooks work.
6. Do your tasks in order to populate the data
7. Enter to settings> webhook>your webhook and the statistics section
should be displayed.
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
Implemented:
* Account Connect
* Calendar sync via delta ids then requesting single events
I think I would split the messaging part into a second pr - that's a
step more complex then the calendar :)
---------
Co-authored-by: bosiraphael <raphael.bosi@gmail.com>
This PR was created by [GitStart](https://gitstart.com/) to address the
requirements from this ticket:
[TWNTY-7536](https://clients.gitstart.com/twenty/5449/tickets/TWNTY-7536).
---
### Description
Migrate all menu items components to twenty ui and update imports.
```typescript
MenuItem
MenuItemAvata
MenuItemCommand
MenuItemCommandHotKeys
MenuItemDraggable
MenuItemMultiSelect
MenuItemMultiSelectAvatar
MenuItemMultiSelectTag
MenuItemNavigate
MenuItemSelect
MenuItemSelectAvatar
MenuItemSelectColor
MenuItemSelectTag
MenuItemSuggestion
MenuItemToggle
```
\
Also migrate all other dependent components and utilities like
`Checkbox` & `Toggle`\
\
Fixestwentyhq/private-issues#82
---------
Co-authored-by: gitstart-twenty <gitstart-twenty@users.noreply.github.com>
Co-authored-by: gitstart-twenty <140154534+gitstart-twenty@users.noreply.github.com>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Simplifying the logic around multi-object pickers and search by getting
rid of the behaviour that keeped selected elements even when they did
not match the search filter (eg keeping selected record "Brian Chesky"
in dropdown even when search input is "Qonto"). This allows us to
simplify the fetch queries around the search to only do one query.
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Fixes https://github.com/twentyhq/twenty/issues/8233
Typing a search input was triggering a re-render of the whole
RecordBoardCard, resetting the search input to its initial value, an
empty string, making it impossible to actually type anything.
useRelationPicker had (legacy?) useless dependencies to recoil states
that caused the rerenders.
### Description
- This PR has as the base branch the TWNTY-5491 branch, but we also had
to include updates from the main branch, and currently, there are
conflicts in the TWNTY-5491, that cause errors on typescript in this PR,
so, we can update once the conflicts are resolved on the base branch,
but the functionality can be reviewed anyway
- We Implemented a new layout of object details settings and new, the
data is auto-saved in `Settings `tab of object detail
- There is no indication to the user that data are saved automatically
in the design, currently we are disabling the form
### Demo\
<https://www.loom.com/share/4198c0aa54b5450780a570ceee574838?sid=b4ef0a42-2d41-435f-9f5f-1b16816939f7>
### Refs
#TWNTY-5491
---------
Co-authored-by: gitstart-twenty <gitstart-twenty@users.noreply.github.com>
Co-authored-by: gitstart-twenty <140154534+gitstart-twenty@users.noreply.github.com>
Co-authored-by: Marie Stoppa <marie.stoppa@essec.edu>
Co-authored-by: Weiko <corentin@twenty.com>
Reusing the useUploadAttachment Hook
In the implementation of the feature to ensure the attachment table is
updated whenever new images are added to a RICH_TEXT field #7617 , it is
likely that the useUploadAttachment hook is reused.
The useUploadAttachment hook is responsible for handling the upload of
attachments, including images, and returning the uploaded file URL. By
reusing this hook, you can leverage its existing functionality to handle
image uploads within the RICH_TEXT field.
In this case, the modified image handling logic would utilize the
useUploadAttachment hook to upload new images added to the RICH_TEXT
content. The hook would then return the uploaded file URL, which would
be used to update the attachment table with the details of the newly
added images.
By reusing the useUploadAttachment hook, you can avoid duplicating code
and ensure consistency in the way attachments are handled throughout the
application.
Fixes#6565
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
