Fix(Performance): limit task duration display to prevent Select2 performance issues

[stonebuzz]

Checklist before requesting a review

Please delete options that are not relevant.

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.
• This change requires a documentation update.

Description

• It fixes !39401

Although the duration (actiontime) of a task is limited to 100 hours

If a user decides to schedule this task over, for example, one year, the duration will be automatically updated according to the chosen schedule.

However, if one attempts to update the task afterward, we observe significant browser latency—particularly with Select2, which tries to load all the necessary options into the dropdown.

To mitigate this issue, I propose simply displaying the duration and period as text if it exceeds the maximum allowed value.

If the user wishes to modify the duration, they would need to unschedule the task first and then reschedule it.

Screenshots (if appropriate):

[orthagh]

@cconard96 You deleted a comment of you for this PR ?
I wanted to support your comment and say select2 is particularly bad for this kind of UX.

@stonebuzz If there is no special option in this dropdown, please, replace it completely by an input[type=number] .
To be checked, but this is something I may still greenlight for 10.0/bf

[orthagh]

Better than an input[type=number], an input[type=time] is probably more adapted.
And as seen together, we can still develop the proposed change that change the thing to a read only text when the task is planned.

[orthagh]

Ok after searching a bit, both ideas are not ideal in fact.
number input have issue with decimal numbers if we want to set durations (8:70 is possible)
time input doesn't let user type duration more than 23:59

So in fine, atm, I don't have more idea with a native control, so maybe let's continue with the original thing (set the duration as read-only)

[stonebuzz]

Setting it to read-only (disabled = true) does not prevent slow loading, as I assume Select2 still loads all options.

[cconard96]

@cconard96 You deleted a comment of you for this PR ? I wanted to support your comment and say select2 is particularly bad for this kind of UX.

I did, but decided it was probably more a general complaint than constructive on this particular PR.
In summary:

• Select2 is a legacy solution that isn't very performant
• Long lists really need to be virtual lists, using virtual dom to keep the number of actual elements to a minimum
• Generating predictable lists like this on the server and sending potentially really long HTML back to the client is going to be a bad UX

[stonebuzz]

As it stands, does this work for you @orthagh?

[orthagh]

Yes

[cedric-anne]

The form will no longer contain a plan[_duration] input, so I guess the value will not be submitted and the created event will not have the expected duration.

Suggested change

	echo Html::timestampToString($default_delay, false);
	echo Html::timestampToString($default_delay, false);
	echo Html::hidden('plan[_duration]', ['value' => $default_delay]);