Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Moving Workitems from Project area A to Project area B

Hello All,

I am using rtc 4.0 and I have 2 project areas. Now I am trying to move some workitems from one project area to another using the eclipse client. There seems to be a problem with the 'Enumeration' attribute.

In project area A , there is a enumeration called projects which contains some values. Now to while moving I got an error stating ' Attribute not found in target project area, hence it will be value will be unassigned'. So what I did was created the same attribute with the same ID ,added the values in the enumeration and added it to the presentation in Project area B.

Now I try to move but for some reason I still get the same error. Is it not possible to move enumeration attributes ?

Thanks
Vishnu M

0 votes



4 answers

Permanent link
 Hello Vishnu,
I would use the CSV Export and Import, along with custom mapping,
to map enum from PA A to the one of PA B

Hope it helps,
Eric

1 vote

Comments

Hi Eric,

I ended up doing this.. but this is a workaround.. Is it not possible to do it directly ? Instead a csv export & import for this attribute alone

Thanks again
Vishnu

Vishnu, you could try that, however the trick would be to get a mapping from the original work item ID (with the export for the enumeration) to the new work item ID. If you get that wrong, your values end up on the wrong items. The CSV import allows you to update existing work items, but you need the correct number/ID.

Ralph, I was using the BulkMoveWorkitem plugin in my eclipse client to do this operation. I created the enumeration attributes in the target project area with the same ID and also same enumeration ID. However when I move workitems , except the enumeration attributes all the other values get moved fine with no problems.

Error : Enumeration attribute not found (though it is present). I double checked the ID's but still was not able to move.

Thanks for your response.

 Hello Vishnu,

may you please send me the PA source as XML of the 2 project areas?
So I can give it a try.

Thanks,
Eric


Permanent link
Hi,

For our current project also we have this feature implemented. I am attaching the screen shot for your reference.

In our project we have this option for moving a particular work item into TRASH project area as delete option is not there.

For both the project areas we have a mandatory field -  Filed Against.

Having choosing the move option it will throw warning message saying "attribute not found" clicking OK will let you move to other project area.

PA_Move1

trash_pa


1 vote

Comments

Adding on to above comment, In our project what we have done is

We have not created any specific mapping between TRASH (which is a simple Project area) and other PA.

We have  just tried to keep the maximum number of fields available in other PA in TRASH.

The aim is to let all fields optional in TRASH in order to avoid potential problem after the move.

And Delete workitem including in bulk works now.  (we use it all the time during testing)


Permanent link
In my experience the BulkMoveWorkItem tool didn't do what I needed programmatically.  I know Susan Hanson's team has done some work item migration work, but I went with a custom approach to what BulkMoveWorkItem does.

The key is the CopyToProjectAreaOperation class in the RTC SDK.  CopyToProjectAreaOperation.java is found in the com.ibm.team.workitem.rcp.rtc.feature.source_* plugin, com.ibm.team.workitem.rcp.ui_* subarchive, and the com/ibm/team/workitem/rcp/ui/internal/wizards directory.  This is enough of the brains behind moving a workitem between project, and can be adapted to even include changing workflows of work items.

Then I created a class that takes callbacks when a copy problem has been found, and modifies the work item's working copy accordingly.  For example, missing attributes, non-matching Filed-Against, that kind of thing.

For each work item in the list:

1. Disable all email to owner, creator, and subscribers
2. Create the working copy
3. Call CopyToProjectAreaOperation to get the list of copy problems
4. For each CopyProblem instance, attempt to resolve it
5. Run a final check on the working copy, because some attributes aren't set correctly, even without a CopyProblem
6. Save the working copy, looking for errors on save

With plenty of logging and tracking, it's pretty easy to do this gradually across multiple executions.  If you're going to disable email make sure to store the user's preferences beforehand, since some disable their mail notifications already, and you don't want to re-enable them incorrectly.

Susan's team's solution may be better, but this worked with the code that I've already written internally.

0 votes


Permanent link
we found some odd behavior with the copy/move function in 4.0 as well. The current version 4.0.5 has vastly improved that function for us especially in the web which now has a straight copy operation for copy within the same project. We copy enumeration fields across projects regularly. Question about the fields enumeration in question. 1. are they enumeration or enumeration_list fields they behave differently. We do have enumeration fields that copy correctly. You have to ensure that the literal values are the same in both project area  process configuration source.If they are not you will run into the error you are receiving. Once we got the literals aligned we have no issues copy/move from project to project.

0 votes

Your answer

Register or log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,023
× 7,499

Question asked: Nov 25 '13, 2:00 a.m.

Question was seen: 6,835 times

Last updated: Feb 10 '14, 8:45 p.m.

Confirmation Cancel Confirm