How do you 'retire' enumeration values in RTC.
If I have an enumeration value that I would like to not show up as an option any longer, but it is still valid for all existing work items, how do I retire it.
For Example,
What if I had a custom field called Operating System
and I had the following values
Solaris 32
Solaris 64
Linux 32
Linux 64
Windows 32
Windows 64
Mac
Then we decided NOT to support Mac, so we want all existing work items with the 'Mac' value to still be valid, but not to allow anyone to choose Mac for any future work items.
Right now, I don't see an option. If you delete it, then the old will just show the literal value, but not the name.
|
6 answers
currently the only thing we have found is to rename the enum value z_oldname - deprecated - do not use
so it goes onto the bottom of the normal list |
I'm looking for something more professional than putting z's at the beginning.. (We had thought of/discussed this.)\
Really - seriously - for a professional tool, this should be handled seamlessly.
Comments
sam detweiler
commented Mar 27 '13, 9:19 a.m.
I hear you. Same issue here.. this is the only alternative currently..
|
Sam - is there an active enhancement request around this feature? We are using enumerated lists to associate a work item with an IT funded project; a funded project only has a shelf life of 3-6 months. It won't be long before the z_s outweigh the active codes... There is a a feature in 4.0 to pull an enumerated list from an external source, right? Does that provide any help?
Comments
sam detweiler
commented Jun 09 '13, 6:15 p.m.
Enumerations sourced from database provide for archiving values. this feature was released in version 4.0.
Lora Estey
commented Jun 10 '13, 10:45 a.m.
Is there a simple way to switch from static attributes sourced from project to database sourced enumerations? |
Thanks Sam. It sounds like db enumerated lists are the long-term answer. One method which might work for awhile in the 3.x realm is to make the enumerated list dependent on another field. For example, we might do something like set a Project date field defaulted to the current list (2H2013) and update the default twice a year. the updated default date (1H2014) would give us a chance to scrub the enumerated list. Of course the enumeration itself will grow unbounded, but the end-users would not be exposed. Comments
sam detweiler
commented Jun 10 '13, 8:14 a.m.
remember that old enum values need to be preserved (archived) so that they can be used in queries and reports.. so uses WILL be exposed to the old values in some UIs.
|
We are using 4.0.0.1, and I can archive an enumeration value that is specified in the configuration XML.
In the eclipse UI, I can go to the Enumerations in the project configuration and set one to Archive. It is reflected in the XML source as "archived=true". In this way, they remain in the existing work items but cannot be used again. Susan Comments
Shubjit Naik
commented Jun 10 '13, 3:20 a.m.
The archive feature has been available since 4.0. |
yup, with the dependent ist, the old item is not removed, just unchecked from the active list:
1H2013 - A, B, C 2H2013 - C, D Enumerated list remains as A,B,C,D the database enumerated list is the right move if you're at 4.x Comments
sam detweiler
commented Jun 10 '13, 12:57 p.m.
except that the DB definition can't be used in a parent/child shared process template.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.