Why is the DEFINITION of a database enumeration not in the process definition XML?
We have created an database enumeration in the process configuration. Then we created an attribute and added this to a UI with a presentation and we marked the right to add literals.
The UI is working and we are able to create workitems and add a literal to the attribute on the fly and then reuse this literal in the next workitem or create a next one.
Now we took the process definition XML part to another repository and replaced the XML of an existing project area on this other RTC server.
Problem we see: the attribute is available, but it is not working as expected. We then found out, that the DEFINITION of the enumeration is not seen in the XML of the process definition. Without this, the inheritance of the process configuration is not working correctly nor the transport of a central process development to a live system by copy/past of the XML is not working.
From my point of view only the LITERALS have to be in the database per ProjectArea. But the definition of the enumeration belongs to the process configuration.
What's the idea behind? Maybe I have not understood it coorrectly?
Accepted answer
and
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=206977
3 other answers
I can only second Sam's statement. I don't think that copying XML is a survivable strategy. As far as I recall related questions, everyone has always discouraged to copy/paste process XML around.
I would strongly suggest to follow the process sharing strategy instead. Please see https://jazz.net/library/article/1008 for details. That way you can actually use process templates to move process versions around. You can use project areas created from them to seed your production project areas. You can switch over if it is convenient and you can develop the process safely on any server, including a test server.
If you want the enumeration to be stored in the process.xml, just define them to be "process specification enumerations".
And unlike database enumerations, process specification enumerations work fine with process sharing.
Comments
what we thought we were getting was a portable definition, usable in all the other scenarios, including sharing, which would lighten the admin load, by allowing distributed admins some control..
unfortunately this this is really totally unusable beyond one project.
we only have shared project templates.
Exactly. Just because they are called "database enumerations" doesn't means that the definition must be in the database. Just the literals should be stored in the database.
This is a defect in the design. The development has not understood the usecase.
WRT Sam's comment, the work item to make database enumerations work with process sharing is https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/236225 . Please feel free to add a comment to that work item indicating your interest/support.
WRT whether or not enumerations that are stored in the database should have been called "database enumerations" ... I'll leave that to others to debate. If there is some particular use case that you'd like to see supported, please feel free to submit an enhancement request identifying the use case you'd like to see supported.
Has there been any work done to resolve this issue in the last 5 years? I also work for a large company. We will end up having several hundred project areas. Each project area needs to have enumerations that are inherited from the parent and enumerations which are unique to that project area. We are using Process Sharing to manage the large number of project areas. We have only a handful of parent project areas. The database enumerations are exactly what we needed. However the use of process sharing makes it impossible for us to use them.
The only solution I can come up with is to use categories as the type for the attribute which requires unique values per project area. This does work, however the list of categories is unmanageable and the list is not unique per attribute. Has anyone come up with a work around or some other solution to this problem? Any help is greatly appreciated
Comments
My RFE about this was recently declined in January 2017.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=95687
Comments
Kevin Ramer
Jan 17 '13, 2:04 p.m.The entire process XML ? I've copy pasted enumeration definitions many times from one process configuration to another. When I do that I search for 'enumerations' in the XML and make sure I paste the entire new enumeration.
I'd be hesitant to copy/paste in total.
sam detweiler
Jan 17 '13, 2:30 p.m.Looks like the definition is also stored in the database..
I just defined a database hosted enumeration on my 4.0.1 test system and it does not appear in the process config XML at all.
Guido Schneider
Jan 17 '13, 4:04 p.m.Thanks, looks like thi is the current implementation. But this is bad. The definition must be in the XML. Otherwise it is not transportable.
I will now test with parent/child PA's. I think it will not work, if I define the db enumeration on the parent and us it on workitems on the childPA. This is then definitifly a defect.
@@Kevin: we develop the schema on a development system and copy the XML over to the productive system into the parent PA, where all other PA's are inheriting the process. So we have only ONE process for all 100+ PA's and an isolated development environment.
sam detweiler
Jan 18 '13, 12:18 a.m.well, it must work on the same server. and starting with 4.0, it must work sharing the process template across servers..
we also today export the process config, import to another server, then create a project from that process template, then share that projects process
we do NOT copy/paste the xml.
sam detweiler
Jan 18 '13, 8:04 a.m.ouch!..good thing we are not trying to use them