As a VersionOne user I would like to create new Backlog Items, Defects, and Tasks from templates without providing a value for one or more of the required fields because some required fields are not known at the time the record is created. Downstream control such as record editing and grid views could be used to ensure required fields are populated at the appropriate point in the work flow when the information is known and/or needed.
by: Khris C. | over a year ago | Sprint Planning
Comments
Alternatively, enable workflows so you can make field required 'conditionally', thus allowing them to be blank on record creation, but not allow them to be blank when some other condition is met.
More complete user story:
As a VersionOne user I would like to create new Backlog Items, Defects, and Tasks from templates without providing a value for one or more of the required fields because some required fields are not known at the time the record is created. For example, we have a custom field "Requires End User Documentation" (Yes/No) that must be set by product owners and/or teams during planning; if we give this a temporary, default value in the template, such as "No," developers have no incentive or enforcement to change the value to "Yes."
This problem occurs for all new items created from a template because we have a handful of custom fields, required fields, for both Backlog Items and Defects. This problem impacts all users who depend on the custom fields being populated so that they can make planning decisions or run reports.
I am having similar issues. Having required fields without some type of condition has little or no value in most situations.
The values for some required fields may not be known until the item (PBI, task, etc) has reached a particular state. Maybe fields could be configured to be required only after an item reaches a particular state. This should be possible since the enumerations for list types have a defined order in the configuration screen. An example might be to make the "Owner" field required before a task can be marked as "In Progress". Another would be to make the "Resolved in Build" field required before a defect can be accepted or closed.
A simple example would be the ability to configure the defect fields resolution and resolution details to be required if a defect is marked as "Done" or if the defect is being closed.
With defects the ablity to configure fields as the bug moves through the status fields is a must to get accurate counts.
Didn't see another idea about adding workflow, but seems like workflow would address this notion and a number of the suggestions in the comments.
I would add that if there are required fields that are not in the Inline list, we can't use the Add Inline. This is extremely frustrating to those adding items so we had to turn off the requirement for certain fields that we really need/want to have the data for.
This is a serious reason for us NOT to use Defect Templates. If I have to enter default text in a Required field in order to save it as a Template this defeats part of the purpose of making the field Required - that being to force a user to pay attention and enter a valid entry.
Typing "Add build number" in the field often results in a saved defect with "Add build number". Should users read this and update? Yes. But I can't monitor every single defect to make sure they do.
I think we'll just scrap Templates and use the default form...at least until\if this ever gets fixed.
Having required fields on template results in everyone just suing the default value that was setup in the template. Instead of updated with a more appropriate value.
We have specific fields that are required when creating a new Work Item (Backlog/Defect), for example Portfolio, Team, Description, etc…, which has also made them Required when creating a Template.
Made these additional fields required, to make sure people are entering the data we need for our metrics that we want to get out of VersionOne.
Example : We have a Template for Defects, but we don’t know which specific Portfolio the Defect will belong to, and don’t want to create a new Template for every Portfolio. It would be nice if the Required fields could be left blank when creating a Template. This way when the users create a new item from the Template they would be required to enter any additional fields that are mandatory, without just using the default value that was setup in the Template. (Same applies to Backlog templates)
I totally agree that this is a significant oversight, that makes the use of Template impossible. I hope that VersionOne can address this. Just defer the checking of required field if it's the Template, and the template must be treated in such a way that it won't be included in the normal view
We whole heartedly agree with all the clearly written sentiments in this thread. Not much more to add.
Maybe I can break the approach to fix the problem down into three prioritized steps:
1st Priority - we would all benefit if generating a story from the template wouldn't first write the contents to the Database (whose fields are set to required) and get immediately rejected, but instead the generation of the story from the template should write the story fields to an open buffer table/space) and present the user with an editable story form first. This would at least give the user a chance, at story creation, to enter the required fields before the story fields are written to the database.
2nd Priority - Allow the required fields to be tied to a workflow step/status/event (as mentioned in previous posts).
3rd Priority - allow the required fields to be set at the project folder level (just like the non-required fields) instead of being globally forced.
We hope this will be addressed within the next few version updates. The current way required fields are implemented in VersionOne has been a major roadblock for our companies goals to consolidate our various instances of VersionOne. And the auditing required to work without using required fields has been a heavy drain on our resources. Added my vote and looking forward some progress on this old issue.
I completely agree this feature is needed especially for Defects! You want to force users to put in resolution details and make the build fixed in fields after marking the defect fixed. However, before that happens you don't want those fields required.
The Spring 2020 release included the ability to mark fields as Important by Planning Level and the Summer 2020 release introduced the ability to enforce these fields at close. Check out https://community.versionone.com/Release-Notes-and-Downloads/Spring_2020_Release_Notes and https://community.versionone.com/Release-Notes-and-Downloads/Summer_2020_Release_Notes for more details