This issue was resolved in Urban Turtle 4.21
When members of a specific team try to access the Product Backlog, a TF400898 error occurs and a stack trace similar to this one is logged in the Windows Event Logger:
Exception Message: Object reference not set to an instance of an object. (type NullReferenceException) Exception Stack Trace: at Pyxis.UrbanTurtle.Web.Areas.UrbanTurtle.Models.Presenters.PlanningBoard.BacklogItemPresenter.CreateIterationLink(Int32 iterationId) at Pyxis.UrbanTurtle.Web.Areas.UrbanTurtle.Models.Presenters.PlanningBoard.BacklogItemPresenter.GetBacklogItemViewModel(IBacklogItem backlogItem) at Pyxis.UrbanTurtle.Web.Areas.UrbanTurtle.Models.Presenters.PlanningBoard.BacklogItemPresenter.GetBacklogItemViewModels(BacklogItems backlogItems, Int32 parentId) at Pyxis.UrbanTurtle.Web.Areas.UrbanTurtle.Models.Presenters.PlanningBoard.BacklogItemPresenter.GetBacklogItemViewModels(BacklogItems backlogItems, Int32 parentId) at Pyxis.UrbanTurtle.Web.Areas.UrbanTurtle.Models.Presenters.PlanningBoard.BacklogItemPresenter.GetBacklogItemViewModels(BacklogItems backlogItems, Int32 parentId) at Pyxis.UrbanTurtle.Web.Areas.UrbanTurtle.Controllers.ProductBacklogController.Index() at lambda_method(Closure, ControllerBase , Object) at System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext controllerContext, IDictionary`2 parameters) at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters)
Other users in the project seem unaffected by the problem.
The problem is most likely caused by a work item that is in an iteration that is hidden for some users but that Urban Turtle has to display because it is stuck between a parent and a child that are in an selected iteration. It is possible to verify this hypothesis by activating all the iterations for the team.
- Go to the project home page
- Select "Configure schedule and iterations..."
- Select the project as the root iteration for the team
- Check all iterations
If following the previous procedure makes the Product Backlog accessible again for the user that were previously getting the error, it is probably because a situation similar to this one occurs in the Product Backlog.
Lets say that there are 3 work items in 2 iterations:
Task A in Iteration Foo;
Task B in iteration Bar;
Task C in iteration Foo;
Lets also say that the team for which the user that gets the error is working in, has only access to iteration Foo, iteration Bar being reserved for another team. The following parent-child relationship is known to potentially cause problems
"Task B" is in an iteration that must not be displayed but Urban Turtle has to display "Task C" because it is in a visible iteration.
A hint that might lead to the problematic work item could be a set of work items that has a 3 level deep parent-child relationship. Un-checking each iteration one by one until the one that causes the crash is found could also be tried. This way, it will be known which iteration the work item belongs to.
If the iteration that is problematic is known, it might be possible to find the work item by querying all the work items that are under that iteration and then filter only linked work items that are not under that iteration*. Queries can be created in Web Access by accessing the work item sub-tab under WORK. The clauses for the query are the following:
*Thanks to Mikael H. for his help with the query.