How do you define what attributes can get copied in a Copy Work Item operation?

Susan Hanson (1.6k●2●201●194) | asked Aug 15 '13, 7:24 p.m.

We have a custom work item with multiple custom attributes. When users do a "Copy Work Item", we want to limit a couple of these custom attributes from being copied to the new work item.

I looked at a previous post (https://jazz.net/forum/questions/119172/create-work-item-copy-windows-attributes-can-be-hiddenremoved-from-it) and it looks like in 2011, it wasn't possible to configure RTC not to show that attribute in the Copy Work Item Window and that it just automatically shows all non-null.

Is that still true in 4.0? If so, I'll open an enhancement request and go back to my stakeholder and let them know it isn't possible.

Susan

Comments

Susan Hanson commented Aug 15 '13, 7:45 p.m.

Follow-ons:

1) Does the save of the work item using Copy Work item follow the normal permissions? So if I have a custom work attribute that only Admin's can change, if a Team Member attempts to do Copy Work Item and the admin has set that attribute, can the team member create a copy of the work item that would then have that attribute set? I would hope not as that would violate the purpose of restricting that attribute to just Admins.

2) Is there a way to restrict the Copy Work Item command for the entire work item type (while that is extreme, it may be necessary)

3) If I can't get RTC to do this, is there a CopyWorkItem pre-condition plugin that I can use to write java code to allow or disallow the copy command AT ALL on the entire work item type or based on the role of the user perhaps.

Susan

4 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Clement Liu (1.5k●5●43●49) | answered Aug 15 '13, 8:00 p.m.
edited Aug 15 '13, 8:01 p.m.

Hi Susan,

Please see the comment 69 in Provide "Create Work Item Copy..." action in the Web UI. I've also copied it below:

The attributes are filled out in the following manner:
	
1) Get all built-in and custom attributes in the Work Item.
	
2) If attribute is not set (e.g. empty string, empty list, etc.), it is filtered out of the list.
	
3) Summary and Description are floated up to the top and the rest of the attributes are sorted alphabetically.
	
Once the user creates a copy, the selected attributes are saved in local storage so that the next time the user uses the option the previously selected items are checked. If local storage is empty then all attributes are checked.

Hope that helps. Thanks.

Comments

Susan Hanson commented Aug 15 '13, 9:26 p.m.

My problem is with #1 above, the "get all built-in and custom attributes in the work item". We need to restrict the ability to copy the value in a specific custom attribute, which is restricted to a be modified only by a specific role.

The exact scenario is:
1) User 1 (Team Member role) creates work item of our custom type. The restricted attribute is NOT set
2) A user with the "Release Architect" role reviews and sets the value of the restricted attribute (say, targeting it into a release or deliverable, which only the release architect role can do)
3) User 1 does Copy Work Item and selects ALL attributes, including this restricted attribute. It comes up in a new work item, they click save.

What I would EXPECT is that they get an error stating that they cannot save the work item because they do not have permissions to change this restricted access attribute. But tried this and my User 1 did NOT receive an error and they were able to copy the work item including this restricted access attribute.

I actually think this is a bug in the save permissions around this.

permanent link

sam detweiler (12.5k●6●195●201) | answered Aug 15 '13, 10:32 p.m.

the copy rule says that ALL the attributes will be replicated.
only the ones CHANGED after the copy are access controlled.

Comments

Susan Hanson commented Aug 16 '13, 12:10 a.m.

ouch! this is a problem for us :-) I'll submit an enhancement request to allow/change this behavior OR allow us to specify somehow that a specific custom attribute value cannot be copied via the CopyWorkItem functionality.

I find this somewhat interesting since changing the FiledAgainst (which crosses a process boundary) checks the access controlled fields, so I would have thought that CopyWorkItem would do the same.

Is there a plugin point for CopyWorkItem such that we could write a pre-condition that would disallow the CopyWorkItem function for a given custom work item type? While that is a little extreme, it would alleviate the current issue in our process.

Susan

permanent link

sam detweiler (12.5k●6●195●201) | answered Aug 16 '13, 8:12 a.m.

'since changing the FiledAgainst'

yes, CHANGING uses the checks.. COPY does not. If the user has authority to copy then they must also have access to all the fields (in some form).

I do not believe there is a specific extension point for copy (/move).

Sam

Comments

Susan Hanson commented Aug 16 '13, 8:43 a.m.

Oh, I totally agree .. but in actually, this is not how RTC works.
For example, in my exact scenario, only 1 role has "access" to modify a specific field .. normal Team Member does not.

So a team member creates a work item, the "special" role person modifies that specific field. Later, a Team Member comes in and makes a copy of the work item. This team member does NOT have "access to all fields", but they can copy the work item. If RTC would not allow this Team Member to Copy the work item because they do not have permission to modify all of the fields, then I would happy. However, this isn't how RTC works today it would seem.

I also found no way in the Permissions configuration to configure a ROLE that can CopyWorkItem (in general) or CopyWorkItem (by work item type). I can say who can CREATE a work item of a certain work item type, but can't restrict who can COPY (other than obviously the creation part). But if we want to say anyone can create one, but only this "special role" can Copy one, I would also be happy with that.

Susan

sam detweiler commented Aug 16 '13, 9:09 a.m.

"For example, in my exact scenario, only 1 role has "access" to modify a specific field .. normal Team Member does not."

the user doing the copy is not 'modifying' the field. they have READ access,
and the COPY makes an identical 'copy'.. so it set st he fields as they were set, and the user MUST have had access to READ the values.

permanent link

Ciprian Spiridon (31●2●5) | answered May 28 '18, 11:29 a.m.

Is there any progress in the customizing attributes of "Create work item copy"? I'm facing similar problem with my coworkers who wrote already about their issues.

My exact problem is that users can create new work items using archived "Filed Against" values by taking advantage of this function.

Thanks.

Comments

Ralph Schoon commented May 29 '18, 6:51 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I don't think there are changes. You could yourself write a precondition that would prevent saving work items if archived filed against are used during save.

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

How do you define what attributes can get copied in a Copy Work Item operation?

4 answers

Your answer