Software » Web » Redmine plugins » Scrum

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.

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!