Defect #1583
Error when loading backlog: NoMethodError (undefined method `reset_positions_in_list' for #<Issue:0x00007fab205fd390>):
Added by Cyril Poulet over 4 years ago.
Updated over 1 year ago.
Description
from production.log :
Started GET "/projects/environnement-de-webconf-securise/product_backlog" for XX.XX.XX.XX at 2020-06-12 15:16:10 +0200
Processing by ProductBacklogController#index as HTML
Parameters: {"project_id"=>"environnement-de-webconf-securise"}
Current user: aaaa.bbb (id=34)
Redirected to https://redmine.canton-consulting.com/product_backlog/26
Completed 302 Found in 26ms (ActiveRecord: 6.0ms)
Started GET "/product_backlog/26" for 82.66.49.25 at 2020-06-12 15:16:10 +0200
Processing by ProductBacklogController#show as HTML
Parameters: {"id"=>"26"}
Current user: aaaa.bbb (id=34)
Completed 500 Internal Server Error in 123ms (ActiveRecord: 9.3ms)
NoMethodError (undefined method `reset_positions_in_list' for #<Issue:0x00007fab205fd390>):
plugins/scrum/app/controllers/product_backlog_controller.rb:208:in `check_issue_position'
plugins/scrum/app/controllers/product_backlog_controller.rb:214:in `block in check_issue_position'
plugins/scrum/app/controllers/product_backlog_controller.rb:213:in `check_issue_position'
plugins/scrum/app/controllers/product_backlog_controller.rb:202:in `check_issue_positions'
lib/redmine/sudo_mode.rb:65:in `sudo_mode'
Installed Redmine :
Redmine version 4.1.1.stable
Ruby version 2.5.5-p157 (2019-03-15) [x86_64-linux-gnu]
Rails version 5.2.4.2
Environment production
Database adapter PostgreSQL
Mailer queue ActiveJob::QueueAdapters::AsyncAdapter
Mailer delivery smtp
(I am the one that created this issue on advanced_roadmap : https://redmine.ociotec.com/issues/1580)
Up
This makes the plugin not usable, as we cannot create spints until the backlog exists, and we cannot create the backlog.
Hi, I will take a look to the error... please disable the plugin setting to check PBIs sort on product backlog and let me know the results
Hi
So as our use of redmine evolved, the problem evolved too.
I currently have a project with 8 subprojets, and the problem only occurs in one of the subprojet (not in the main project nor in the other subprojects).
It is still the same error with the same log signature.
I tried to check or uncheck the PBIs sort in the settings, but no changes.
This comes when you assign an issue to the backlog that is not allowed to be in the backlog. It will also happen if you change the tracker to one that is allowed at the same time as you assign it to the back log.
The best work around is to allow all issue types in the back log. That alone will not fix your backlog, and unfortunately the log message doesn't tell you the ticket number that is breaking the backlog so there is no way to find it without manually querying the database. After you allow all issue types in the back log take everything out of the backlog, make sure the backlog works, then assign them back into the backlog.
I created a custom query to find the issues breaking the backlog, but it doesn't always work if someone changes the tracker and assigns it to the backlog at the same time. Getting the issue number in the log instead of the binary id number would be very useful.
As I type this the backlog for this project is similarly broken!!
I'm running into this problem as well:
Sep 24 18:39:32 pro-web-osticket docker[12372]: Completed 500 Internal Server Error in 12ms (ActiveRecord: 4.5ms)
Sep 24 18:39:32 pro-web-osticket docker[12372]: NoMethodError (undefined method `reset_positions_in_list' for #<Issue:0x00007f788baf1080>):
Sep 24 18:39:32 pro-web-osticket docker[12372]: plugins/scrum/app/controllers/product_backlog_controller.rb:208:in `check_issue_position'
Sep 24 18:39:32 pro-web-osticket docker[12372]: plugins/scrum/app/controllers/product_backlog_controller.rb:214:in `block in check_issue_position'
Sep 24 18:39:32 pro-web-osticket docker[12372]: plugins/scrum/app/controllers/product_backlog_controller.rb:213:in `check_issue_position'
Sep 24 18:39:32 pro-web-osticket docker[12372]: plugins/scrum/app/controllers/product_backlog_controller.rb:202:in `check_issue_positions'
Sep 24 18:39:32 pro-web-osticket docker[12372]: lib/redmine/sudo_mode.rb:65:in `sudo_mode'
Disabling "PBIs sort on product backlog" produced no noticeable effect.
I am facing the same issue.
Some user accidentally assigned a task type issue to backlog, and after that accessing Backlog stopped working. Luckily workaround suggested by Kent Hulick above worked (Thanks!). I searched for all non-user story issues that were assigned to backlog, and moved them to "none" sprint. This got my backlog working again.
I also got this issue then moving an issue (User story) with multiple tasks from Sprint to Backlog. The problem is that the tasks don't get assigned a position. This is an issue (tracker 4 User Story) and two tasks (tracker 5). Then it is moved from a sprint to the backlog it will break it.
id tracker_id project_id subject parent_id root_id lft rgt sprint_id position
2577 4 20 Parent NULL 2577 1 8 4 0
2601 5 20 One task 2577 2577 2 3 4 NULL
2602 5 20 One more task 2577 2577 4 5 4 NULL
A solution I came up with which seems to fix this is to set position to the id of the parent
update issues set position = parent_id where position is null and sprint_id = 4 and tracker_id = 5 and parent_id is not null
Of course you need to exchange the 4 for the id of your backlog and 5 to the id of your tracker containing tasks. Moving Simple PBI:s and Issues with only one task don't create this problem.
Update: I tried the suggestion above from Kent Hulik. I didn't crash the backlog and the item was sent to the backlog BUT the tasks remained on the sprintboard but moved to the backlog column.
- Alone changed from No to Yes
- Target version set to Scrum v0.22.0
- Status changed from New to In progress
- Category set to Product backlog
- Status changed from In progress to Resolved
I had the same problem with 0.21.0 (the latest version I could find here).
The Johan Dahl solution solver my problem. What I noticed is that I had issues with two different trackers. One of the trackers was PBI ant the other was Tasks. Probably someone moved tasks to the backlog sprint, but the tracker remained ant the past position was set to null. Giving a position to the tasks solved my problem.
Emilio González Montaña , is it fixed in 0.22.0? Where can I find this version?
Thanks.
Kent Hulick wrote in #note-4:
This comes when you assign an issue to the backlog that is not allowed to be in the backlog. It will also happen if you change the tracker to one that is allowed at the same time as you assign it to the back log.
The best work around is to allow all issue types in the back log. That alone will not fix your backlog, and unfortunately the log message doesn't tell you the ticket number that is breaking the backlog so there is no way to find it without manually querying the database. After you allow all issue types in the back log take everything out of the backlog, make sure the backlog works, then assign them back into the backlog.
I created a custom query to find the issues breaking the backlog, but it doesn't always work if someone changes the tracker and assigns it to the backlog at the same time. Getting the issue number in the log instead of the binary id number would be very useful.
As I type this the backlog for this project is similarly broken!!
We had the same problem, I can confirm that Kent Hulick's solution works!
- Target version changed from Scrum v0.22.0 to Scrum v0.23.1
Added extra protection just in case...
- Has duplicate Defect #1610: Undefined method 'reset_positions_in_list' for Issue added
- Has duplicate Defect #1603: Displaying backlog gives Internal error added
- Has duplicate Defect #1600: Displaying backlog gives 500 error added
Also available in: Atom
PDF