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

Modify read-only type field in Operation Participant

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?

Thank you,
Jamie Berry.

0 votes



2 answers

Permanent link
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

0 votes


Permanent link
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

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
× 10,937

Question asked: Nov 12 '10, 11:42 a.m.

Question was seen: 5,396 times

Last updated: Nov 12 '10, 11:42 a.m.

Confirmation Cancel Confirm