- My View
My developers do not have the Sprint Planner and can not set the Sprint field.
However, if they do a search for stories within a specific Sprint, and then click the New button, they are able to create a story with the Sprint field pre-populated to match their search.
Does anybody know why this is the default behavior and how I can turn it off?
Yiou can remove that for them with list control, this will remove the ability to cerate a new record
Steven, thanks for your reply. I do want my developers to have the ability to create stories, but just not the ability to have them be added to sprints. Is there a way to do that? I've been hunting around for scripts/business rules/etc that run when that New button is hit, but I haven't seen one that seems to apply yet.
you need the list control on the related list for stories under sprint, then you need to find the ACL for create on the stories table and verify they have the approriate roles to be able to create. The stories are not associated to sprint OOB and that field is read only. This will limit the ability to assocuiate stories to a sprint. Hope this helps
Hey Steven, I actually haven't tried the New button on the related list of stories in a sprint, but I imagine the same problem exists there. I am talking about the regular list view of all stories, with a filter applied like Sprint=X. If you click the new button from there, you will see that the story is automatically assigned to Sprint X, even as that field is read only. I opened a support case for this one and got this back:
ISSUE SUMMARY: Sprints auto assigning themselves to stories Desired Behavior When filtering on a specific sprint and then clicking the "New" button, the story form should not show the sprint filtered pre-populated on the form. Unexpected/Actual Behavior The "New Story Form" is showing with the sprint pre-populated. MOST PROBABLE CAUSE: This is expected Platform Behavior SOLUTION PROPOSED: I have heard back from the Product Owners on this issue and here was what they stated:
This is a standard platform behavior to pre-populate fields based on the filter condition on the list. If you observe the URL there is a sysparm_query which has the encoded query of the filter condition and it is used to pre-populate fields that are on the form based on the query. You can try that on the task form as well.
And as for only sprint planning being able to edit the sprint field, it is an expected behavior.
I have no filter condition to the list, when i click new and create a storie no sprint is associated. If you do not have this behavior i would check the business rules
I think you are missing the steps to reproduce here:
1) Go to the list view of all stories.
2) Add a filter condition where Sprint=A Specific Sprint that exists
3) Click New
4) Observe that the sprint field is filled in with the sprint from the filter condition. SN's help desk has confirmed that this is the default behavior.
What I'm trying to do now is figure out how to prevent this from happening. They suggested a UI Action.
This is the BR I found setting the sprint: your instance.com/nav_to.do?uri=sys_script.do?sys_id=b13c84c5efa1200099620fa3f8225658. This sets the Sprint when created from it. There is another BR: yourinstance.com/nav_to.do?uri=sys_script.do?sys_id=1e7fd132ef602000a7450fa3f82256a1 and this is calling a scipt include and there are many function in there that also could auto populate this. With this one there is no easy answer unfortuantely, you have to put the scoba gear oin and go diving in the code to understand
Thanks, Steven, I looked through the code and didn't see a place where .sprint is being set anywhere in there. Even in the ScrumUtils... it does seem like it must be there somewhere, but I couldn't find it.