GLPI 11 : Forms / Date and Time / No Time in calendar

[tristangallet]

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Version

11.02

Bug description

Hello. In a form, when you want a date and time, a calendar comes but without the time, it's not the same as GLPI 10.

Calendar forms glpi 10 - GLPI 11.pdf

Relevant log output

Page URL

No response

Steps To reproduce

Create a form in GLPI 11.02.
Make a question with Date and Time., ask for Date and Time
Test the Form, the calendar has no time to select. In Glpi 10 Time was in the calendar.

Your GLPI setup information

No response

Anything else?

No response

[AdrienClairembault]

Hello @tristangallet,

This is something we did on purpose, the calendar "widget" has been replaced by the default date picker from your browser.

We thought it was similar enough, is this really an issue on your side?
The time can be added directly in the input after the date since it is just two numbers.

[cconard96]

Hello @tristangallet,

This is something we did on purpose, the calendar "widget" has been replaced by the default date picker from your browser.

We thought it was similar enough, is this really an issue on your side? The time can be added directly in the input after the date since it is just two numbers.

Is there a technical reason not to use Flatpickr to match the look and feel of the other date/time fields in GLPI?
The native date/time input controls work very differently between browsers. Chrome has no picker while Firefox does but doesn't have the time inside the picker.

Unless Flatpickr had some technical issues, and maybe even then, I think it should be used here as well to have a consistent user experience across the entire app, regardless of the browser.

[cconard96]

Apparently the lack of a time picker in Firefox is a bug, but my comment is still relevant.

Before Firefox 144, only displays a date picker without a time picker, see [bug 1726107](https://bugzil.la/1726107) and [bug 1726108](https://bugzil.la/1726108).

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/datetime-local#browser_compatibility

[AdrienClairembault]

Chrome has no picker

Are you sure? I tested on my side on it does seem to have one.

I think it should be used here as well to have a consistent user

It was discussed with @orthagh at the time and we wanted to see if we could remove flatpicker everywhere so this was a step in this direction.

(It was a while ago so opinions may have changed since then)

[orthagh]

My opinion hasn't changed. In general, if a native control exists, I'll prefer we use it for the main reason it's less dependency to maintain.
Regarding particular datetime control, we may miss some features. I know people like a [today] button, this example is not available in firefox. I don't know if it's an important feature or not. Apparently, time picker was a bug, but it needed 2 years for firefox to fix it... (and on my local ff 144, it still doesn't work)
A contrary example was color picker where I think we moved to native controls.

My point is, if we lack only "optional" features, we may move to native, otherwise keep library.

[cconard96]

Are you sure? I tested on my side on it does seem to have one.

I am using Chrome 140 and nothing shows up when clicking the field.

at the time and we wanted to see if we could remove flatpicker everywhere

That's fine, if it worked well, but it should have been a global replacement IMO. As it is now, if you didn't comment on it, I and users as well would probably think the field is broken because it doesn't work like the rest of the application for date/time fields.

In general, if a native control exists, I'll prefer we use it for the main reason it's less dependency to maintain.

This sounds OK if browsers actually handled native inputs the same and we (or Bootstrap/Tabler) styled them as best as we could to match between browsers and match the rest of the UI.

A contrary example was color picker where I think we moved to native controls.

We still use spectrum. The native color picker is another example of browsers doing their own things with "standard" input types. Chrome is a bit better with this field UX and has support for other color formats in the selector while Firefox does not.

Firefox:

Chrome:

[orthagh]

So guys, my opinion is not that complex, if the current native control is not sufficient (that's a shame, but 🤷🏽‍♂️), let return to flatpickr.
The latter works well, and it's not the most concerning dependency.

[tristangallet]

Hello @tristangallet,

This is something we did on purpose, the calendar "widget" has been replaced by the default date picker from your browser.

We thought it was similar enough, is this really an issue on your side? The time can be added directly in the input after the date since it is just two numbers.

Hello, i've tested with Firefox, with Edge it's ok. With Firefox, The time is difficult to be added after (for a regular user) and these are extra clicks. I can understand that it's more difficult but native calendar is just ugly when you were using GLPI 10. For me, this undermines the fantastic work done on the GLPI interface. I prefer a unified interface, as it makes the user experience more consistent.