It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,883
×6,033
×496

question asked: Aug 08 '19, 3:02 a.m.
question was seen: 1,855 times
last updated: Aug 08 '19, 6:04 a.m.

Related questions

how we can set permission

0
Snehal Yendhe (15●2●35) | asked Aug 08 '19, 3:02 a.m.

Hi team,


I am using CLM 6.0.6

I have created 3 work items in RTC. ABC is parent WI and PQR, XYZ is a child of ABC WI. I set permission for 3 WI And creates one plugin like if we change "ABC" WI state to "In progress" then automatically PQR and XYZ WI state will change to "in progress".
but if I directly change PQR WI state to "In progress" then ABC WI state not able to modified, getting error like unable to save WI as PQR state already in "In Progress".
if we remove permission of PQR WI then created plugin is also not working.
So how I can restrict for PQR WI(they can not able to change state manually). 

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Ralph Schoon (63.6k●3●36●46) | answered Aug 08 '19, 5:57 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Aug 08 '19, 6:04 a.m.

Several thoughts here.


  1. Automation like that is always suspicious. Usually you want to make sure all the necessary work is done and then change the parent state. The other way around, someone could unintentionally change the parent and mess with the child states. https://rsjazz.wordpress.com/2012/11/27/resolve-parent-if-all-children-are-resolved-participant/ is one approach to automate the parent state, if the children are worked on. Another would be to prevent changing the parent state unless the children are done. This is an advisor that is in the tool. similar advisors could be done for other states than "resoved".
  2. It is possible to control which role can change a workflow state in the permissions, however, the permission that is available in a follow up action is also based on the roles and permissions of the user saving the work item. If you prohibit the user to perform the state change manually, they will not be able to do it in the automation.
  3. As an author of an automation it is your duty to make sure that the automation deals with such situations. It would be possible to ignore the child state if it has already reached a later workflow state. This is just one obvious solution that avoids damaging the usability of the tool.
My suggestion: Do not implement such an automation at all.
 

Your answer

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