Make a Required system Field Not Required

Idea ID 1790077

Make a Required system Field Not Required

Would like to create a rule to make an existing required field Not required. 

Use Case: We have a team that currently uses Jira for User stories and defects. We are creating a one way link using the synchronizer to copy Jira User Stories to Octane. We don't want to bring over the Jira Status because there are way too many and they don't fit within the Octane phase theme. However, when I configure the synchronizer link, since Phase is a required field, I have to map it and I have to map all Jira Status values to the Phase values.

I would like to be able to create a rule that says "Make Not Required". Then I could select whatever system field that was required and make it not required. In this case "Phase".

Thanks.

11 Comments
Micro Focus Expert
Micro Focus Expert

Hi,

Some system fields are required like "phase" since they are necessary for important Octane functionalities. Therefore you cannot set them to optional / not required for good reason. It just does not make sense if they are blank.

I see three options:

a) Convince the JIRA teams that their status system is over-complicated and they should reduce the complexity. Sorry, just kidding. Forget about that...

b) Configure the synchronizer to map several JIRA status values to a few phases in Octane. This might be possible depending on the process implemented in the JIRA status system. (Actually I am not quite sure if you can do that in our Micro Focus Synchronizer of if you need a different synchronizer.)

c) Sync the JIRA status values into a new Octane user defined field "JIRA status". Create a business rule which maps the JIRA status values to Octane phases.

Just my 2 cents - could someone in R&D / product management please add your perspective?

Thanks,

Dirk

Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

@Dirk Hedderich great summary and suggestions.
I would add from R&D POV that we're trying to limit the required system fields for each entity to minimum and leave only the ones that are really needed.

 

@Tuboysdad How about Dirk's 3rd suggestion or something of the sort?

Honored Contributor.
Honored Contributor.

So I talked to the team and they did streamline the Jira workflow . . well.. . sort of. In this case I'm going to probably map the Jira statuses to multiple Phases in Octane. I've also created  a string field just to capture the Status from Jira, do you think the string field would be sufficient or does the Phase field require mappings?

I'm trying to eliminate the need for adding list fields that could potentially change in the future and subsequently break the link.

I understand the need for fields to be required, but in this case, the one way synch from Jira to Octane doesn't require the Phase be updated. I'd also say that it still defaults to "New" when a new US or defect is created. The system can certainly suggest what fields should be required, but should not enforce that without a way to un-require. I would still  like to have  a way where we could make required system fields not required. If there are risks to this action, then we should have the choice to understand and accept those risks.

Howard

Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
Status changed to: Waiting for Votes
 
Honored Contributor.
Honored Contributor.

There is another use case for this type of rule. One of the teams is omitting the "Feature" field from their defect forms in the defect module. However, when they create a defect from the manual runner, the feature field displays and is required. They don't use this field as intended in Octane and don't want it to be required. Creating a rule like this would help in this case as well.

Micro Focus Expert
Micro Focus Expert

@Tuboysdad Octane general policy regarding system required fields is to mark them as required only if not having a value in that field will break octane system logic.
The decision to make field required is not taken lightly, and done only if there is no other practical alternative.

Usually, if field is required it is possible to provide default value, which is either provided by Octane itself, or can be provided by Business Rules, like this

image.png

This should make the fact that Feature field in Defect required irrelevant, as it will be field with data for user, field can be even removed from the new defect form and user doesn't need to be even aware that it's there.

Outstanding Contributor.
Outstanding Contributor.

All,

I had a similar requirement where I need to make "Featire" field in Defect Module as Not required field. I though to create a new ER. But, found this thread on going. So, Im voting for it and adding my note as below: 

Currently, ALM Octane does not allow to make Syetsm required fields like Feature to make Not required. This field is not use bu my QA teams. So, they do not want to see it in Defect Module while creating a new defect and also while creating a they are in Run screen to create defect. Thus, I would need to make "Feature" field as Optional. 

Micro Focus Expert
Micro Focus Expert

@NEW_ALM12 have you tried the solution of using rules to provide default value ?

Honored Contributor.
Honored Contributor.

@yael , does the default suggestion also work if the field is not present on the entity's forms?

Outstanding Contributor.
Outstanding Contributor.

@alex-shnayder I used a run to set up a default value. But, is there a much efficient process to make System field Optional from required. 

BTW, there a option to make Required from Optional. But, not optional from required. 

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.