Create new item type from existing item type

Definitely agree on the desire to be able to derive from an existing type. While we're trying hard to align our different product groups on a common set of shared item types, occasionally there are customizations one group requires that preclude using the standard item type, so we have to "clone" the existing item type and make a subset of customizations to the clone.

Since there's not currently an easy way to do this, we end up manually creating the cloned item type from scratch, manually comparing the old with the new to duplicate the "common" fields between the two types (and invariably leaving something out).

Hi Grant (and others),

Wanted to add to Stephen's comments, hopefully to give additional insight:

We currently have 7 distinct Jama instances (database plus web front end); each instance has a unique set of data on it (that is, we are not synchronizing all data across each instance).  We do share portions of the data across instances, but not all of it.  Today, four of the instances each have active document records numbering in the several millions (if combined into a single instance, this would be in the 10 - 20 million range, which does not take into account the support records such as versions, activity log, baselines, test plans, test cycles, and many other types of content).  We discovered in earlier versions of Jama that having a large number of records on one instance, along with the associated user interactions and automation tools, would degrade the user experience to a point that was untenable.  As well, whenever re-indexing an instance with a large number of records, the required time to complete the re-index was longer than the available non-work hours (since we are a global company, we have to consider those cultures where Sunday is a normal work day), which impacts business.  So that was one reason for separating into multiple instances.

I should note that more recent releases of Jama have improved the indexing performance significantly; thanks for that.

Another reason, as Stephen mentioned, is that the user experience from some geographies was noticeably poorer than from others.  This can be mostly attributed to our own company not willing (or not able) to increase the bandwidth between certain end points.  But it can also be partially attributed to the "chattiness" of the Jama UI between web server and the client browser.  The only solution in that case was to install an instance geographically closer to the users.  Again, Jama has improved the chattiness in previous releases, but it is something that needs to be watched carefully in future releases as well.

Two more reasons for separate instances that I will mention are 1) that we needed to isolate some of the data in an environment that can hold what we consider "Top Secret" data.  Unfortunately, the environment is such that security takes priority over performance, so it's not practical to use the same environment for all instances.  And 2) we also needed one instance that is accessible to external customers so that we can share data from within our firewall with an instance that is outside the firewall.

As mentioned, we're not duplicating the data exactly across all instances, so it's not as impossibly difficult as it initially sounds.  But we are trying to build a catalog of reusable records (use cases, requirements, test cases, etc) that will be sync'd across most of these instances... and since the records are supposed to be of the same item type (not as useful to reuse records if each instance has different field labels or different pick list options than other instances), it is important to keep many of the item type elements (the type itself, the pick lists, the relationship types, etc) in sync.

What I hope this highlights, for Jama in particular, is that having a way to manage Org Admin type functionality via the REST APIs would be incredibly valuable, especially Item Types, Pick Lists, Permissions (and by extension, User Groups), and Reports.

Would love to hear from other Jama users what kind of data volume you are dealing with, just to get a reference compared to our usage.