Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scheduler date() is incorrectly populated when using selectable=true #781

Open
arnederuwe opened this issue Mar 6, 2018 · 6 comments
Open

Comments

@arnederuwe
Copy link
Contributor

When making the scheduler selectable, if you select an empty cell or if you select an event, the scheduler's date() property is updated internally to reflect this selected date().
This works differently in standard kendo as it does in the bridge, causing a serious issue in our current project. Below are 2 gists, one for kendo and one for the bridge. Perform the following steps:

  • edit an event so it falls outside of the current view range (if you selected a week view, set the event start date to a date before this week)
  • select a cell: console logs the correct date
  • select the edited event: console logs the END date in the kendo gist, console logs the START date in the bridge gist

This is a serious issue for us because we sometimes refresh the scheduler's view, this causes the view to jump to the range from the event start date, which is very confusing to the end user.

https://gist.run/?id=9b0279895cd39c60ce2ab40d7763d815
https://dojo.telerik.com/AmAzIRaD

@JeroenVinke
Copy link
Member

JeroenVinke commented Mar 6, 2018

this is weird. why doesn't the date() change when I switch between two cells that are next to each other horizontally, while it does change when I select a cell further away?

  schedulerSelectionChange(e) {
    console.log(e);
    console.log(this.scheduler.date());
  }

this is interesting to see as well. I'm not sure what to make of this

@arnederuwe
Copy link
Contributor Author

arnederuwe commented Mar 6, 2018

The exact same issue occurs in the kendo dojo as well, so it's not related to the bridge after all. It's very strange, the date doesn't update consistently when performing the same actions, and sometimes takes the end/start of an event..
I'm filing an issue with Progress for this, will keep you posted here

@adriatic
Copy link
Member

adriatic commented Mar 6, 2018

It's easy to say now "I knew it", but I really expected this outcome 😏

@arnederuwe
Copy link
Contributor Author

arnederuwe commented Mar 6, 2018

I just filed an issue on their enterprise support channel:

Hi,
See the following dojo: https://dojo.telerik.com/AmAzIRaD/5
The scheduler is made selectable, when you click on a cell or event, the dojo logs the scheduler.date() to the console.
PART 1
When you select an empty slot on the sunday, monday, then tuesday, wednesday,... you see the console logging the correct date
When you do the same in reverse (sat=> sunday), you can see the date only updates once in 2 clicks, so the logged date isn't reflecting the reality.
PART 2
Select an empty slot on the sunday, the console logs 6/2. Next, select the interview event, the console logs 6/2 again, which is understandable because the date() can't really be determined from the selected event
Select an empty slot on the friday, the console logs 7/6. Next, select the interview event, the console logs 25/5!! which is the start of the selected event, and completely false because 25/5 doesn't represent the current scheduler date at all. Now, if you would refresh the scheduler with the dedicated button, the view range will switch to the range containing 25/5, which is very confusing to end-users

This completely prevents us from using the selectable functionality at the moment, as we refresh the scheduler view a lot (we bind the scheduler to dynamic groups/resources).

I hope you can confirm to me that this is a bug, and that it will be resolved. If you can provide me any workaround for this in the meantime it would be much aprreciated. I don't really care about the date(), but it can't jump outside of the currently visible view range, as this breaks the refresh user experience.

it's very very funky behavior if you ask me.. :) I burned 3 hours trying to track this down...

@arnederuwe
Copy link
Contributor Author

Good news, it's now an official bug :)
telerik/kendo-ui-core#4057

@JeroenVinke
Copy link
Member

Nice :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants