We need to be able to mark a field to display on the asset (Story or Defect) by individual project. Currently, if you mark a field to display on Story assets in one project, it is displayed on Story assets for all projects. What would be great would be a cascading hierarchy. If you mark it to display at a higher level project, the lower level projects default in, but we have the option to turn off the display for the lower level projects individually.

The same for Required Fields. We need to mark a field required for a Story or Defect asset in one project but not all projects. A cascading hierarchy for this would be great also.

Comments

  • 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!!?

  • We hae a big company which now devlop several applicatins with different organizations across the world. We have a strong need to make certain fields mandatory for one project which are not for antoher.

  • I vote for the part about allowing 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.

  • I vote for allowing required fields by project. You can add this ability to the Display Fields area. It can be mandatory by project. It's an easy add.

  • I vote for allowing required fields by projects rather than them reflecting all across the board. In our case, there are about 100 projects that I will have to go in an disable the new fields manually.

  • 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.

  • We add custom fields specific to a Train, and in many cases would like to make them required. We cannot force our entire enterprise to use and fill in these custom fields. The cost of not having this feature is high due to the amount of time we need to spend manually verifiying the appropriate Trains have populated the custom field.

  • This is a critical features for us. We have over 3100 planning levels with many different requests for new fields. It is an administration nightmare to turn off a new field and it would be easier if we could make an individual selection to turn it on.

  • Yes please .. good feature

  • I vote for this. It would be great to be able to set required fields based on the planning level(s).

  • Yes, we need to be able to customize the cards for the stories (including what is required). That is very important since different workspaces may have different worklows and data requirements. Please move this up in the list!!

  • VersionOne has supported Displayed Fields per workspace for a while now. In the Spring 2018 release, we introduced "Important Fields" which allows organizations to specify by workspace which fields are important for downstream reporting.

  • I'm not sure that important is the same as required. We really need required so that a Story cannot be created without the required fields (but that requirement only applies to a specific project, not all projects).

    Also does the "Planned" status mean that V1 will actually be adding this "Required by Project" feature? If so, do you have an expected release date?

  • The Summer 2020 release introduced the ability to enforce these fields at close. Check out https://community.versionone.com/Release-Notes-and-Downloads/Summer_2020_Release_Notes for more details