Defect #1522
Problem dragging & dropping tasks in the Sprint board
Description
I had Redmine 3.0 and Scrum plugin 0.12.0. I migrated Redmine to 3.4.3 and Scrum plugin to 0.18.0. In my old Redmine I Drag & Droped post-its normally, but after migration, when I try to move the post-its, de application show me the Error: "Fail to change the task status." and the post-it come back to old status (visually in Sprint board). Despite this, if I refresh the Sprint board (Pressing F5 in browser) the post-it appears in the new status correctally, in other words, although the error message is shown, the status change occurs.
I identified that in the update of versions (of Redmine and Scrum plugin), the Sprint field of subtasks lost its data reference. Despite that, the subtasks are shown in the Sprint board inside the correct Sprint, but when I edit one subtask its Sprint field is empty, causing the problem described. If I select the Sprint value in the combo and save, the Drag N' Drop of this subtask works correctly.
I figured out that the "sprint_id" field of all subtasks were migrated as [null], while all parent issues came with the "sprint_id" filed fill correctly. Maybe there are any problem with migration script?
Files
Updated by Germano Costa about 7 years ago
Actually, I realized that in Redmine 3.0 and Scrum 0.12 all "sprint_id" fields of subtasks are empty, despite that I can move the post-its correctly. After migration, the drag n' drop of post-its only works if I fill the field.
Why in Scrum 0.18 I need to fill "sprint_id", when in 0.12 did not? I think that the behaviour must be the same.
Updated by Germano Costa about 7 years ago
From Log:
(sensitive data replaced by ##############)
Started POST "/redmine/projects/############## Processing by SprintsController#change_task_status as */* Parameters: {"task"=>"##############", "status"=>"##############", "project_id"=>"##############"} Current user: ############## (id=##############) Rendered mailer/_issue.text.erb (10.7ms) Rendered mailer/issue_edit.text.erb within layouts/mailer (14.5ms) Rendered mailer/_issue.html.erb (2.5ms) Rendered mailer/issue_edit.html.erb within layouts/mailer (5.0ms) Rendered plugins/scrum/app/views/scrum/update_task.js.erb (6.2ms) Completed 500 Internal Server Error in 5603ms (ActiveRecord: 82.0ms) ActionView::Template::Error (undefined method `project' for nil:NilClass): 14: $("#<%= "pbi_#{@issue.parent_id}_row" %>").replaceWith("<%= 15: escape_javascript(render :partial => "post_its/sprint_board/pbi_row", 16: :formats => [:html], 17: :locals => {:project => @issue.sprint.project, :sprint_board_id => 'sprint_board', 18: :pbi => @issue.parent, :task_statuses => IssueStatus.task_statuses}).html_safe 19: %>"); 20: <%- if @old_status != @issue.status -%> plugins/scrum/app/views/scrum/update_task.js.erb:17:in `_plugins_scrum_app_views_scrum_update_task_js_erb__2021098135277629363_70167659636960' plugins/scrum/app/controllers/sprints_controller.rb:109:in `block (2 levels) in change_task_status' plugins/scrum/app/controllers/sprints_controller.rb:108:in `change_task_status' lib/redmine/sudo_mode.rb:63:in `sudo_mode'
Updated by Germano Costa about 7 years ago
Germano Costa escribió:
I had Redmine 3.0 and Scrum plugin 0.12.0. I migrated Redmine to 3.4.3 and Scrum plugin to 0.18.0. In my old Redmine I Drag & Droped post-its normally, but after migration, when I try to move the post-its, de application show me the Error: "Fail to change the task status." and the post-it come back to old status (visually in Sprint board). Despite this, if I refresh the Sprint board (Pressing F5 in browser) the post-it appears in the new status correctally, in other words, although the error message is shown, the status change occurs.
I identified that in the update of versions (of Redmine and Scrum plugin), the Sprint field of subtasks lost its data reference. Despite that, the subtasks are shown in the Sprint board inside the correct Sprint, but when I edit one subtask its Sprint field is empty, causing the problem described. If I select the Sprint value in the combo and save, the Drag N' Drop of this subtask works correctly.
I figured out that the "sprint_id" field of all subtasks were migrated as [null], while all parent issues came with the "sprint_id" filed fill correctly. Maybe there are any problem with migration script?
This is a problem, since I do not need to change the Sprint value in all subtasks when I change in the parent issue. The parent issue value rules.
Updated by Emilio González Montaña about 7 years ago
- Source changed from Development to Customer
- Priority changed from Immediate to Normal
- Subject changed from Problem with Migration from Scrum 0.12 to 0.18 to Problem dragging & dropping tasks in the Sprint board
That piece of code could contain an error due the fact task issues could have a parent PBI issue but they could be not assigned to an Sprint.
So I will review that piece of code.
But on the other hand I have no idea how your issues where unassigned from any Sprint to nothing... do these issues have any kind of history where you can check how this could happen?
Updated by Germano Costa about 7 years ago
Thanks for your answer!
Well, in Redmine 3.0 with Scrum 0.12, when I create a subtask, the default value of Sprint field is blank as shown at Default Sprint in subtask.jpg. Despite the subtask has empty Sprint value, it's parent PBI always have a valid Sprint value and this is sufficient to show both PBI and it's subtask in Sprint board, I suppose. The fact is, all PBI (wich contains subtasks) have Sprint value, but for all subtask, Sprint value is blank, despite this, in Redmine 3.0 with Scrum 0.12, drag n' drop works well.
Updated by Emilio González Montaña about 7 years ago
- Target version set to Scrum v0.18.2
- Status changed from New to Resolved
Fixed on `master` branch.
Updated by Germano Costa about 7 years ago
Thank you very much, Emilio!
Do you can tell me when TAG 0.18.2 will be available?
Updated by Emilio González Montaña about 7 years ago
Germano Costa escribió:
Thank you very much, Emilio!
Do you can tell me when TAG 0.18.2 will be available?
Germano, so idea right now, no so much was accumulated on this version...
If you support this open source project, you gain GIT access, take a look to:
No presure :)