Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

More drag and drop problems #214

Closed
marnen opened this Issue · 15 comments

2 participants

Marnen Laibow-Koser Malcolm Locke
Marnen Laibow-Koser

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 Laibow-Koser

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

Marnen Laibow-Koser

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.

Malcolm Locke
Owner

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 Laibow-Koser
Marnen Laibow-Koser

@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 Laibow-Koser

@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 Laibow-Koser

...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 Laibow-Koser

@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 Laibow-Koser

@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 Laibow-Koser

@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.

Malcolm Locke
Owner

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 Laibow-Koser

@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 Laibow-Koser

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 Laibow-Koser

@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 Laibow-Koser

@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 Laibow-Koser marnen closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.