More drag and drop problems #214

Closed
marnen opened this Issue Jan 26, 2014 · 15 comments

2 participants

@marnen

It looks like issues are no longer being randomly reordered as in #196, but some issues just don't want to move: after a drag and drop, they appear exactly where they did before. Sometimes deleting the issue and recreating it fixes the problem; sometimes it does not. Help?

@marnen

It may also be that particular pairs of issues don't want to exchange position. I'm not sure which is the case.

@marnen

Is there anything I can do to help nail this down? The lack of response on such an important feature is disturbing, to say the least.

@malclocke

Just standard bug reporting procedure will be most helpful:

  • What is the git sha of the version you are running.
  • Minimum steps to reliably recreate the error, starting from a blank project. As much detail as possible here helps.
  • Any errors that are generated in either the browser console or the rails log during a failure event.
@marnen
@marnen

@malclocke Looks like I was using e0f2e2b (with some commits of my own to get it to run on Heroku). I'll try the latest version and report back.

@marnen

@malclocke I just merged f71db17 into my deploy. Didn't help.

I am getting one "event.returnValue is deprecated. Please use the standard event.preventDefault() instead. " error (in Chrome 32), but it's pointing to a large minified JS file, so I can't tell where the error is. I'll investigate further. Note that I get this error once on app load, not each time I drag a story.

@marnen

...and that error appears to be only a deprecation anyway, so it wouldn't explain the problems.

What I suspect is going on is that there's a logic error, not a syntax error, in the client-side JS.

@marnen

@malclocke Potentially good news. I just tried getting rid of some of my Heroku-specific commits now that the latest master obviates them. I think that step may have got it working; I'll play around some more and close this if the issue has gone away.

@marnen

@malclocke Nope, not entirely gone, but a major part of the bug seems to involve story state. Under certain conditions, it's desirable to move an Unstarted story above a Started story (if the Started story is on hold), but this does not work. I think that the position value is being refreshed properly, but it looks like something in the display logic is preventing the Started story from being displayed at its proper position (but it's not displayed all the way at the top either!).

@marnen

@malclocke ...but this isn't the whole story either. I wonder if the earlier version of the application put the data in an inconsistent state. At the very least I think I'll start by renumbering the position of the stories to integers and see what happens.

@malclocke

Started stories always being above unstarted stories is by design, and that won't change. I'd suggest that if you have stories on hold for some reason you move their state back to unstarted.

You are probably right that the position value would update if you dropped an unstarted story in between two started ones (I'll have to double check that) but that is really a bug. Ideally the app shouldn't accept a drop in that position.

@marnen

@malclocke Deleting my previous comments regarding this being a poor design decision. This does make sense (and it's the way Pivotal Tracker behaves), and I will try reordering stories with that in mind. (I suspect that since I imported my stories from Redmine, rather than creating them all in Fulcrum, something may have got into an inconsistent state.)

Note, though, that not all my story order woes seem to be related to Started stories...

@marnen

BTW, if it's helpful, you're welcome to use https://www.pivotaltracker.com/s/projects/1026080 to double-check Pivotal Tracker behavior. (It's a public testing project.)

@marnen

@malclocke More information. It appears that for some reason, two stories (both Unstarted) are showing in an order opposite to their position. I'm not at all sure what to do about this. Dragging another story in between them to force reordering doesn't appear to help. I guess I'll try the renumbering idea...

@marnen

@malclocke And the mystery is solved! The stories that were giving me trouble were unestimated but Started (I know, a weird state, but apparently a possible one given the application logic). Closing this issue, but should we consider providing logic so that an unestimated Feature (as opposed to a Chore or Bug) can't be Started? Or should we at least display them more differently if they are Started? Part of the reason this took me so long to track down is that unestimated stories all look alike; there's no visual difference between Started and Unstarted.

@marnen marnen closed this Feb 27, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment