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
FYI, inherited db enumerations do NOT work in child project areas. See https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=236225
and https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=206977 Guido Schneider selected this answer as the correct answer
|
3 other answers
Ralph Schoon (63.4k●3●36●46)
| answered Jan 18 '13, 2:17 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Guido,
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. Comments
Guido Schneider
commented Jan 18 '13, 8:52 a.m.
I will change the way we work to be compliant. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Jan 20 '13, 9:27 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
They are called "database enumerations" because they are stored in the database.
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
sam detweiler
commented Jan 20 '13, 11:38 p.m.
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..
Guido Schneider
commented Jan 24 '13, 4:28 p.m.
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.
Geoffrey Clemm
commented Jan 26 '13, 2:52 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
|
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.
Comments
Guido Schneider
commented Mar 27 '17, 10:05 a.m.
My RFE about this was recently declined in January 2017.
|
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.
Comments
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.
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.
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.
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.
ouch!..good thing we are not trying to use them