It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,877
×4,715

question asked: Jan 17 '13, 11:32 a.m.
question was seen: 7,347 times
last updated: Mar 27 '17, 10:05 a.m.

Related questions

Why is the DEFINITION of a database enumeration not in the process definition XML?

0
Guido Schneider (3.4k●14●91●115) | asked Jan 17 '13, 11:32 a.m.

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?

Comments
Kevin Ramer commented 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 commented 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 commented 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 commented 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 commented Jan 18 '13, 8:04 a.m.

ouch!..good thing we are not trying to use them

Accepted answer

0
permanent link
Brian Fleming (1.6k●1●19●28) | answered Jan 18 '13, 6:58 a.m.
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

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Ralph Schoon (63.5k●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.
0
permanent link
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..

unfortunately this this is really totally unusable beyond one project.
we only have shared project templates.

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.

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.

0
permanent link
Jim Tompkins (19●3●17) | answered Mar 22 '17, 11:56 a.m.

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
Guido Schneider commented Mar 27 '17, 10:05 a.m.

My RFE about this was recently declined in January 2017.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=95687

Your answer

Register or to post 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.