Customizing artifact types at the project level

You may find an artifact type that you want to use in your project, but you might like some of its attributes/attribute options to be named differently. And you may want to change the order in which they are configured to be displayed. Also you may want some attributes to be removed or added to the artifact type. In all these scenarios, you can still add that artifact type to your project and make all such changes at the project level without affecting its global definition.

There are still more customization options available at the project level and you can find them by going through the artifact type administration screens of a project.

Renaming attributes and attribute options

When renaming attributes or attribute options, make sure that the name you select sounds distinct from other attribute/option names. Attributes with similar names can confuse the users when entering artifacts.

Deactivating artifact types

If you do not want an artifact type to be used for entering new artifacts, you can deactivate that artifact type. You can query on inactive artifact types even though you cannot enter or edit artifacts of that type. The same rule applies for inactive attributes too.

Deleting versus deactivating attributes

If you have entered values for an attribute in the artifacts that you created but later you decide not to use that attribute, you can either deactivate that attribute or remove that attribute from the artifact type. If you remove that attribute, the values entered for that attribute will be lost and they cannot be recovered if you change your mind and add the attribute back later. If you are not quite sure whether you might need the attribute later with the values entered, you can simply deactivate the attribute rather than deleting it.

Configure attributes for quick search

If you think users would search for artifacts primarily based on the criteria for few of the attributes, you can enable the 'Included in custom query?' flag for those attributes. Users can then use the 'Query' tab, which will display only these attributes, and they can quickly search on them.

Configure duplicate check

You can decide whether to enable or disable duplicate check based on the people who enter artifacts. If they have a good knowledge of the artifacts in the system, then it is probably better to disable it. If the artifacts are entered directly by the end users or by a large QA team, where the chances for different engineers to file the same artifact are high, then it is probably better to enable it.

When selecting an attribute group for duplicate check, try to make sure that it has the minimum number of attributes and the combination of values that would be entered for those attributes is likely to be unique. Duplicate check will not be useful if many artifacts are going to have an identical combination of values for the attributes selected for duplicate check.

Setup dependency rules

You can setup dependency rules between attributes at the project level in addition to the rules inherited from the global artifact type. Once all the rules are set up, make sure that all the rules show up as valid. If you set up two rules that conflict with each other, one of them will be turned down as invalid and the invalid rule will not be enforced when entering/editing artifacts.

You cannot modify inherited rules at the project level. However, if for instance you want to add one more actions to an inherited rule, you can copy it as a new rule at the project level, remove the existing action(s), and then add the new action to the rule.