I see, I think we would implement that by having a new section of the "Edit Tree" or "Edit List" dialogs that list any current custom configurations. This means that they will need some sort of name. We could call them something by default: "species1, species2, species3..." so that you don't normally have to name them all the time, but you could rename them in that same dialog to make it easy to keep track of them.

Thinking about the design I think that we may introduce a concept of configurable attribute:
1) In CM use_custom_configuration flag will be changed from boolean to enum and we will use dropdown instead of checkbox
2) dropdown will have 3 options - default, custom, saved
3) in case "saved" is selected user will see another dropdown that allows to pick a saved configuration for attribute
4) "Edit" button will open up a different dialog in case "saved" configuration is selected. This dialog will allow to add/edit/delete configurations for attribute.
5) We can also add this manage dialog to the main menu so user can add/edit/delete configurations outside of CM editor.
5) Configurations for attributes are independant and can be shared between CMs
6) We will add the logic to export attributes configurations independantly. When import CM if no approptiate configuration is found a warning will be shown and default attribute configuration will be used.
7) When export CM to xml we should promt user to export "saved" configurations for attributes that are used by this CM.

RRI Discussion:

So for tree attributes we would have 3 options:
Default tree - tree configured for all uses of the attribute if one of the two custom trees is not selected
Custom tree - customize the tree for a specific CM node
Saved tree - a configuration which is saved at applied and can be re-used

Some of the items are not clear for this case:

1) Should it be possible to share attribute configuration between multiple CMs?
On Tuesday meeting Emily suggested not to share configurations between CMs, but this is not final.

2) What should happen when user edit configuration that is shared?
Functionality to copy the configuration is easier to implement, but it will not allow to apply changes in multiple places.

3) we should also take into account that we have xml export/import logic that should be backward compatible.

In response:
1) now that configurable models can be used as templates for new CMs (this is correct?) I think they don't need to be "shared" between models.
2) When you make edits to a shared configured attribite, ask if you want to apply changes to all instances of this configured attribute on save.
3) no comment

Another possible design:
We already have default configuration that is shared between attributes in CM, but this is one-to-one relation. We can scale it to become one-to-many. We can introduce a concept similar to what we implemented for CyberTracker properties settings - in case when we are not using custom configuration user will see a dropdown with CM level configurations and he can pick one of them. Default configuration will always exist and can be edited, but cannot be deleted. If user deleted some saved configuration which used by some attribute, than default configuration will be used.

The way I see it in UI:
- dropown with list of saved configurations is added near "Use Custom configuration" checkox
- a button "Manage" will be placed near the dropdown, it will launch dialog that lists saved configurations and has buttons to add/edit/delete a new one (silimar to CT Properties Profiles dialog)
- "Edit" or "Revert to DM" buttons will work with currently selected configuration (as it was before)
- Edit dialog will have a textfield at the top that allows to enter a name for configuration (only for saved configurations, custom configurations cannot have names)

That sounds fine.

In 6.0.a5, most aspects appear to be working as expected. This error was encountered when importing an XML file that contained changes necessary for testing this ticket.
The Example CA was used to create and import in the XML.

New_Configurable_Model.zip

fixed rev. 6223

No further issues in 6.0.a6