Copy work item does not copy attachments

Harry Koehnemann (301●2●52●38) | asked Nov 06 '13, 3:00 p.m.

It appears copied work items reference attachments instead of copying them. We have supplier project areas and copy defects to them for suppliers to work. However those suppliers cannot see the attachments. They appear as as "Unknown" for id and name and "NaN" for size. It appears the attachments in the copied work items are really references back to the attachments in the real work item. And of course we would expect copy meant "copy" - we can see the log files, screen snapshots, etc.

Is there a way to perform a work item "deep copy"?

Thanks.

4 answers

Most liked answers ↓|Newest answers|Oldest answers

permanent link

Kohji Ohsawa (595●1●3●10) | answered May 14 '15, 10:14 p.m.
JAZZ DEVELOPER

Hi Yaron,

Unfortunately I don't think there is a simple way to do it. However, you can copy a WI with its attachments from one PA to another, then move back the created WI. I know it is tiring but you can do at least what you want to do by this way.

0	permanent link Yaron Norani (472●6●70●65) \| answered May 14 '15, 9:12 a.m. Hi, Is there a way to copy WI to same project area with the attachments? Thanks, Yaron Comments Don Yang commented May 14 '15, 10:14 p.m. this does not seem to be possible currently.

permanent link

Arun K Sriramaiah (3.2k●1●31●77) | answered Feb 11 '14, 8:54 a.m.

Hi Harry,

There is already an RFE created for the same, vote for it.;

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

Regards,

Arun

Comments

Kohji Ohsawa commented Aug 25 '14, 9:42 p.m.

JAZZ DEVELOPER

I have just confirmed this can be done on 5.0.1 RC1. Yahoo!

permanent link

Don Yang (7.7k●21●109●138) | answered Nov 06 '13, 6:53 p.m.

Hi, Harry

What version of RTC did you have this issue? I just tested with RTC 4.0.3 and there is no problem at all to access to the attachment in the copied workitem in another project area.
I guess that the problem could be in the source workitem in which the attachment is not appearing as file name only instead it may have local path to the file and that could lead to the problem you are seeing. If your source project area is in IE8(or higher) and see the attachment showing in full path to the local machine, you may want to try the below solution:

1. Open Internet Explorer options from Tools > Internet Options
2. Select Security tab
3. Click Custom Level ...
4. In the Miscellaneous section look for option called "Include local
directory path when uploading files to a server".
5. Click Disable

Then attach the file again and confirm it will be a file name only in workitem's link then copy to another project and see if that works now.
Hopefully this helps.

Don

Comments

Harry Koehnemann commented Nov 07 '13, 6:58 p.m.

Thanks for the quick reply Don. We will try what you proposed above. However it is strange that the user can see the attachment when he belongs to the source project area. And sees the "Unknown" and "NaN" when not a member. So the RTC server must be deciding to send the "Unknown" and "NaN" text based on membership and access control rules. I am not confident the problem is in the browser.

Don Yang commented Nov 07 '13, 10:56 p.m.

You could be right that the issue may not related to the one I mentioned. I remember I saw this issue some time ago but I tried in v4.0.3 now for the above use case, I don't see any problem. What version do you use now? It could be an issue in relative old version and was fixed now.

Rachel Biderman commented Jan 23 '14, 2:52 p.m.

We are using 4.0.3 and see the same issue.

It is clearly privileges issue - if a user has privileges in both projects, he can view the attachment.

If he belongs only to the project where it was cloned to, he can't.

Is there an open Work Item or we should submit one?

it is really critical for us, since we can't ask the origin projects to add all our users.

Or maybe there is a workaround?

Thanks

Harry Koehnemann commented Jan 23 '14, 3:02 p.m.

Hi Rachel,

I did not submit a Defect. Our workaround was to save and then re-attach any attachments to the copied work item. Painful, but mandatory if you need to collaborate and protect sensitive information.

If you submit a Defect, please post the link here so others (like me) can follow it and add their +1.

Don Yang commented Jan 23 '14, 8:58 p.m.

The behavior is as expected from product point of view. I found the below note from the Infocenter:
https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.team.workitem.doc/topics/t_triaging_work_items.html&scope=null

Note: To access attachments in a work item that is copied to a different project area, users must have permissions to access the project area that contains the source work item.

Hence the user needs to have the access to the source project area in order to access to the copied workitem's attachment.

The workaround I can think is:
1) if the workitem is no longer used in source project area, use the Move instead of copy to move the workitem to another project area, in that case, the users in the target project area should be able to access to the attachment.
2) if the workitem is need in the source project area, try to duplicate the workitem first in the source project area and then move it to the target project area, this will make the two identical workitems in the two project areas.

Rachel Biderman commented Feb 11 '14, 8:35 a.m.

Well i am glad that IBM agreed it is a required enhancement and plan to include it in next release - see:70127- Copy Of Attachments

showing 5 of 6 show 1 more comments

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.

It's all about the answers!

Related questions

Copy work item does not copy attachments

4 answers

Your answer