Allow fields to be marked as required at the project level

Comments

  • We need to be able to define required fields based on project workspace. We have several business units on the same instance of VersionOne, and we cannot customize required fields since this is currently only global functionality.

  • Fields can be marked as 'required' in the Spring 2012 release.

  • Please allow Program to be required at the Project level, that doesn't appear to work.

  • When a developer creates a story in Project A, I’d like to require him to fill in certain fields such as Status and Estimate, with the rest of the displayed fields being optional for him. When the developer then creates a story in Project B, I’d like to require him to fill in a different set of fields such as Planned Estimate and To Do, with the rest of the displayed fields being optional. Project workspaces are great for customizing display, but it would be great to have this additional feature for required fields so when I make a field required it doesn't affect the entire system.

  • We also need to be able to set fields as Required for specific projects only (and totally invisible to other projects). Please note that you have 3 different "Ideas" (that I've found so far) all related to this, with a total of 58 votes between the 3 of them. Can you get this supported please!!?

  • Required in certain locations or work space would help instead of global functionality.

  • Considering that it is possible to create a workspace at particular project levels, it is absolutely counter-intuitive that these different workspaces would NOT allow unique customization for displayed and required fields. Why not just have a single workspace and not allow creating new ones at different project levels if they are all going to be applied globally? Please fix this so that the different workspaces may have unique and independent settings for displayed fields and required fields.

  • It is strange and unexpected to have two checkboxes that work differently at the same place. I think people expect they work the same way and they only discover the difference when they need to set the field as require.

  • We need to be allowed to define required fields for a single project. We have tons of projects across our V1 instance and each project has VERY different processes and requirements. I can't make fields required without consulting with 7 other project managers, and literally 99% of the time it is a wasted effort because the fields I want to make required are completely irrelevant to the other project teams.

  • When different teams have different needs, it is important to have the ability to enforce data entry in a field for some projects and not others.

  • The Project Workspace concept is there to control the behavior and display of fields for that project…correct? Why not allow us to define mandatory fields for a specific Workspace? We have over 1000 developers in our company in several dozen teams with varying needs and custom fields for project workspaces. The "Required" behavior as it is today is useless because we can't get everyone to agree what fields to use much less what should be "required". It only makes sense to make “required” behavior to work on the Project Workspace level. Your implementation only makes sense for small companies where all the developers follow the same process.

  • Without the ability to enforce required fields at the project level, teams and management are left with the overhead of monitoring work items to ensure integrity.

    For example:
    We ONLY want work items that have been estimated and assigned to a team to show up in our Q2 2016 Program Increment.(if it hasnt been estimated, how can we commit to it?)
    We make that very clear to Product Owners and Scrum Teams, however they are human and they make mistakes.
    Without requiring those fields (Team & Estimate) in our Q2 2016 PI project we are left with the overhead of monitoring work items assigned to the project and reminding teams and individuals who forget.

  • Currently while defect or backlog item creation, assigning the same to an epic is not configured to be mandatory. But typically our defect team here will compulsorily create backlog item or defect under epic. Hence we would like to have the Epic field to be mandatory but to be affected only to the selected backlog unlike how its currently being implemented in a way that it affects globally.

  • Now If I make a field mandatory for given project, it becomes applicable globally. This is a big challenge for us as different teams are using different fields which is applicable to their project only. Say, we have a team which uses 3 fields and another team is using another set of three different fields. If I make the three fields mandatory for that project another team is forced to fill the details when they don't need to. Please provide some flexibility in this regard. At least if we disable the field from project workspace it should solve the problem.

  • Now If I make a field mandatory for given project, it becomes applicable globally. This is a big challenge for us as different teams are using different fields which is applicable to their project only. Say, we have a team which uses 3 fields and another team is using another set of three different fields. If I make the three fields mandatory for that project another team is forced to fill the details when they don't need to. Please provide some flexibility in this regard. At least if we disable the field from project workspace it should solve the problem.

  • +1

  • Um... We are almost unable to even use required fields due to their global nature. With dozens of different divisions, areas, companies, groups, teams, etc, it is literally impossible to find common ground that works for everyone in a required fields standpoint.

    PLEASE please please allow us to control this by project workspace! Otherwise, we may as well not even have required fields.

  • +1

  • 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