Framework: wrong display order of over-midnight, non-all-day events in monthly mode

Created on 13 Oct 2014  路  18Comments  路  Source: vaadin/framework

Originally by _winfried.stenzel_


The display order is wrong for over-midnight, non-all-day events.

Steps to reproduce:

  • go to vaadin calendar sampler
  • create an event with caption "first", start=20:00 on day x and end=4:00 on day x+1
  • create another event with caption "second" with start=20:00 on day x+1 and end=4:00 on day x+2
  • change to monthly mode (if not already)

on day x+1 the events are in the wrong order: i.e. "second" is shown before "first"


Imported from https://dev.vaadin.com/ issue #14849

bug Stale

Most helpful comment

Originally by _rzenz_


So let me be the one who pokes this once more.

All 18 comments

Originally by @hesara


Note to whoever investigates this: might be related to #8616.

Originally by @denis-anisimov


Looks like it doesn't matter whether the events are over-midnight or not.

I see the same behavior (events are not ordered by date) even for events within the same day.

Originally by @denis-anisimov


Events are sorted by duration, not by the start date.
In that specific case duration of both events is the same.
If it's the same then they are sorted in the order of creation.
That's what could be changed. Sorting algorithm should use start date as a secondary sort condition and creation order should be the last one.

Originally by _winfried.stenzel_


Thanks for investigating this issue.

Yes, a secondary sort condition (start date) would help a little.

I suppose that sorting by duration as primary condition is done, because it shows the 'timely most important' events first. Is this right?

If you cannot change the primary sort condition to use the start date, what do you think about the following minor change:
The first primary sort condition is not the duration of the whole event anymore, but the duration of the event only on the specific day.
This change would emphasize the 'timely most important' notion.

Nevertheless, in my use case (a personnel planning system), using the start date is still the best, easiest and most obvious thing, because the chronological order is more relevant than the 'timely most important' notion.

Do you have an idea, if I can easily override the default behavior?

Originally by @denis-anisimov


I would suppose the better idea (I think that it's better): introduce a server side option to point which sorting strategy has to be used inside month view for the events.

I don't know why primary sorting condition is duration. It has some sense but it's not obvious and it not what you would like to have in some cases. I agree that sorting by start day of event is absolutely natural primary condition. As it's in your case.

So I'm going to introduce the server side method that will allow to set either default sorting behavior (by the duration) or by the start date. So it will be configurable.

What do you think ?

Originally by @denis-anisimov


Replying to Sara:

Note to whoever investigates this: might be related to #8616.
This is actually duplicate of #8616.
But let's keep this one to track the issue instead of old one.

Originally by _winfried.stenzel_


@denis-anisimov

What do you think ?
Perfect.

Do you think of any secondary sort conditions, when sorting by start date? Customers are normally happy, if it is the same behaviour as in Microsoft products. I don't have MS Outlook here, but in my Thunderbird calendar Lightning, it seems that a longer event is shown after a shorter event, when they both start at the same time. I.e. for Lightning the second sort condition seems to be: end date ascending or duration ascending

Originally by @denis-anisimov


OK, let's do it in this way.

Originally by _winfried.stenzel_


@denis-anisimov

OK, let's do it in this way.
Thank you!

I have just tested the secondary sort condition with MS Outlook 2010. MS Outlook has the opposite sort order than Thunderbird Lightning, i.e. end date descending or duration descending.

So I think, the Outlook behaviour would be the best option (also because the secondary sort condition would the same as the first sort conditon of the existing solution).

Originally by _sseppola_


https://dev.vaadin.com/review/#/c/5286/

Originally by _vralfy_


When will this feature be available?

Originally by _Markus Koivisto_


As soon as the patch passes review, it will be included in the next maintenance release. It seems this fell through the cracks in the review queue, so we will update the ticket shortly.

Originally by [email protected]_


Has this made it into a review yet?

Originally by _spungin_


This is still an issue, as the calendar month view only displays the correct order if sorting by start date DESC. My results are sorted ASC and they show up reversed in the component.

All documentation states that the event provider getEvents should sort by date, but does not specify the required sort direction.

Originally by @denis-anisimov


https://dev.vaadin.com/review/#/c/5286/

Originally by _rzenz_


So let me be the one who pokes this once more.

A lot of tickets have been left hanging in the issue tracker through the years. Some of them are still relevant, some of them have been fixed a long time ago and some are no longer valid. To get a better look on what is important and still relevant, we are closing old tickets which have not been touched in a long time. No further work will be done on this ticket. If the ticket seems to be still actual, please verify the problem existence over latest framework version and then open a new ticket in vaadin/framework with all the suitable information.

The issue was automatically closed due to inactivity. If you found some new details to it or started working on it, comment on the issue so that maintainers can re-open it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sarahfuchs picture sarahfuchs  路  6Comments

TatuLund picture TatuLund  路  3Comments

RobertZenz picture RobertZenz  路  6Comments

lanmaster picture lanmaster  路  3Comments

hannuvaadin picture hannuvaadin  路  6Comments