Commit Graph

9 Commits

Author SHA1 Message Date
05adad4648 Fix incorrect relative path (#12582)
Not sure why we didn't see it before but I see errors in the console on
staging when trying to load the manifest.json
2025-06-13 08:09:06 +02:00
5343dd62d6 Update readme with partner logos (#11722)
Recognize the role of Greptile/Sentry/Crowdin/Chromatic which give
generous open source plans + some cleanup
2025-04-24 16:09:43 +02:00
b6e344e7be Various fixes (#11448)
# Scrollbar fix

Fixes https://github.com/twentyhq/twenty/issues/11403

<img width="1512" alt="image"
src="https://github.com/user-attachments/assets/b13fe0f2-8c61-4ea8-9ea1-e61e571a90da"
/>

---------

Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
2025-04-09 01:03:43 +02:00
d6171c66df [BUGFIX] Dynamic default body background depending on device preferences (#10626)
# Introduction
close #9965 

When landing on twenty you should be able to see a white screen
flickering if you had setup dark mode.
This is because before the SPA has been loaded we're not displaying
anything, which in a white screen from the browser.
During this period we should display a background color following the
user's device theme.

## Reproduction
In order to reproduce this behavior define a fast 4G connection from
your network console.

## Cons
Device mode might not the one chosen afterwards when the user has been
authenticated
=> We should store appearance settings in the local storage in order to
optimistically render the default "loading" background ( wouldn't be
100% bullet proof for instance if the user is now unauth for some reason
)

Body background will be override by theme after app bootstrap
2025-03-04 15:54:16 +01:00
64938d5a05 Refactor RecordPicker part 2 (#10502)
Keep clarifying folders:
- record-picker is now clean
- record-picker-morph-legacy contains activityTarget logic that will be
abstracted later
2025-02-26 13:54:16 +01:00
e5754d2152 Remove env-config.js (#9331)
Fixes #5340 which had been open for a long time
2025-01-03 15:18:02 +01:00
08a9db2df6 Add Twenty Shared & Fix profile image rendering (#8841)
PR Summary: 

1. Added `Twenty Shared` Package to centralize utilitiies as mentioned
in #8942
2. Optimization of `getImageAbsoluteURI.ts` to handle edge cases


![image](https://github.com/user-attachments/assets/c72a3061-6eba-46b8-85ac-869f06bf23c0)

---------

Co-authored-by: Antoine Moreaux <moreaux.antoine@gmail.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
2024-12-17 09:24:21 +01:00
898006f89d Prevent automatic zoom when focusing inputs on iOS (#8477)
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
2024-11-13 15:34:20 +01:00
5bdca9de6c Migrate to a monorepo structure (#2909) 2023-12-10 18:10:54 +01:00