Thank you for the reply. We will have to look at our process model to determine a work-around. Our situation is that we are wanting to have a work item hierarchy of Task -> Sub-Task where both records have a field called Charge Number. Users with role of "Team Lead" can set the Charge number in either record. Users with a role of "Team Member" will be assigned to the Sub-Task and ideally would not be able to modify the Charge Number field. We wanted the Charge Number of the Sub-Task to be set by default to the Charge Number on the Task, which might not have been set when the Sub-Task was created. The plan was to check to see if the Charge Number of the Sub-Task is set when the Sub-Task is modified and if not, check to see if the parent Task has it set, then copy it down.

As an alternative, is it possible to have the Task save operation check to see if any of it's child Sub-Tasks are in need of a Charge Number value and have the children modified when the parent is saved? This may not be a great solution either, but might help us out.

Thanks again.

I have a case where a field of a work-item is supposed to be
read-only, but we want to set it behind the scenes to the value of
the same field of the parent work item (the child is to inherit the
parent's value). To accomplish this, I have written an
OperationParticipant extension, but I am running into permission
problems. Since the user does not have permission to modify the
field, the participant running on the server does not have permission
either.

With ClearQuest, the hook code that runs behind the scenes bypasses
field permissions, is there any way to do the same type of thing for
RTC?

We currently don't offer API that allows to circumvent permission
checks. If the attribute is marked as read-only, it won't be modifiable
in the UI, and maybe you could grant permissions to modify it in this case?

--
Regards,
Patrick
RTC Work Item Component Lead