Description of problem: during drag'n'drop sorting, take into account sortkeys of unselected cases Version-Release number of selected component (if applicable): 3.7.1 How reproducible: always Steps to Reproduce: 1. Suppose you have three cases: [ ] Case Sortkey ================ [ ] A None [ ] B 10 [X] C 20 2. use "Re-order cases" to trigger drag'n'drop sorting 3. move A to the bottom of the list, below C 4. hit "Done sorting" Actual results: A gets "10", so the actual sort is: A: 10, B: 10, C:20 Expected results: A gets 30 so that TC order after "Done sorting" is hit matches the one user have seen before hitting the button Additional info: This gets more complex when the insertions (putting A between B and C in reproducer) and filtered-out cases are taken into account. Based on my hands-on experience, I'd prefer to modify all affected sortkeys in a consistent manner.
> > Steps to Reproduce: > 1. Suppose you have three cases: > [ ] Case Sortkey > ================ > [ ] A None > [ ] B 10 > [X] C 20 > > 2. use "Re-order cases" to trigger drag'n'drop sorting > 3. move A to the bottom of the list, below C > 4. hit "Done sorting" > > Actual results: > A gets "10", so the actual sort is: A: 10, B: 10, C:20 > > Expected results: > A gets 30 so that TC order after "Done sorting" is hit matches the one user > have seen before hitting the button > Your problem couldn't be reproduced on "https://tcms.engineering.redhat.com". I try to resort cases in testplan, steps to reproduce are as follows, 1. Open testplan, https://tcms.engineering.redhat.com/plan/6692/ 2. Move case 184617 to bottom of case list, below case 154356(sort-key is 10) and case 154355(sort-key is 20), 3. click Done Sorting. Actual results is, [ ] Case Sortkey ===================== [ ] 154356 370 [ ] 154355 380 [X] 184617 390 this result meets my requirement. Is there any different with your problem?
Hi Xin, look at the plan again - the case 184617 now has sort key of "10" after I moved it in front of TC 154356... I'm using: firefox-10.0.4-1.el6_2.x86_64 xulrunner-10.0.4-1.el6_2.x86_64
David, It's so weird... Any way, I'll confirm this problem with dev.
Hi, For now, tcms re-sorting is designed to re-order selected cases by increasing 10 every time like 10,20,30,40... It has nothing to do with sortkeys of unselected cases when re-sorting. After re-sorting, tcms will display the whole test cases(both selected and unselected cases) by sortkey. We can not reproduce this bug. Could you provide some detailed info about steps to reproduce? Thanks
(In reply to comment #4) > Hi, > > For now, tcms re-sorting is designed to re-order selected cases by > increasing 10 every time like 10,20,30,40... > > It has nothing to do with sortkeys of unselected cases when re-sorting. > Which is a separate bug, if you want to sort subset of an existing plan (say just one tag), you end up with mess of multiple 10s, 20s, etc. > After re-sorting, tcms will display the whole test cases(both selected and > unselected cases) by sortkey. > > We can not reproduce this bug. Could you provide some detailed info about > steps to reproduce? > > Thanks Hi, I provided already all info I'm aware of in comment 0 and comment 2. If you need anything more concrete, please specify what.
Hi David, I can understand your meaning, that is also what I expect. But the existing feature implementation is different with our expectation. There is assumption user selected the checkebox on all of the test cases which sort key wants to be changed. Based on your example in comment #1, you want to reorder not only A, also B and C. So you need to set their three checkbox before you click "done sorting". Then they can be set the sort key as you expect. And only the selected test cases will be re-ordered, and set the sortkey from 10. So in your example, if only case A is checked, its sortkey will be 10, no matter where you drag A to. Based on current implementation, you can select all cases, and drag them, then all cases' sort keys will be set as the order displayed on screen.
(In reply to comment #6) > Hi David, > I can understand your meaning, that is also what I expect. But the existing > feature implementation is different with our expectation. > There is assumption user selected the checkebox on all of the test cases > which sort key wants to be changed. > > Based on your example in comment #1, you want to reorder not only A, also B > and C. So you need to set their three checkbox before you click "done > sorting". Then they can be set the sort key as you expect. By not checking some cases, I mean that their respective order should not be changed. Anything else leads to many WTFs when actually using the feature. Actually, IMO we should go even further than that and display also hidden cases during the view so it is much harder to screw up whole plan order when one actually wants to sort few cases with specific tag or priority. > > And only the selected test cases will be re-ordered, and set the sortkey > from 10. So in your example, if only case A is checked, its sortkey will be > 10, no matter where you drag A to. > > Based on current implementation, you can select all cases, and drag them, > then all cases' sort keys will be set as the order displayed on screen.