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

RTC: What do you think is the best way to force (and keep) Owned By = Unassigned while in a particular state?

Questions
Tags
Users
Badges
Michael Reed
(126●5●16) Jul 18 '17, 12:53 p.m.

I am hoping that I might get some good direction on how best to handle this scenario:

One of my customers wanted to have a holding state called Inventory where all reviewed WI's will reside until picked up for a release. While in that state there are quite a few attributes that are read-only to prevent modification. Initially, we were thinking of doing the same to Owned By but that prevents us from changing the value to Unassigned.

I would like some feedback on what the community thinks would be the best way to handle this. I you have examples of simple code that would be great. Otherwise, an outline of what you think would be the simplest answer to ensuring that Owned By is reset to Unassigned and forced to be kept as Unassigned while in the state=Inventory would be great.

I will come up with my own way to handle this but I am not at this customer all the time so I thought I would reach out for ideas before I do head over there again. I hope you don't mind.

-michael

0 votes

3 answers
1,756 views
0 votes

3 answers

Permanent link
Donald Nong
(14.5k●6●14) Jul 19 '17, 12:46 a.m.

How about a validator? It can be a bit annoying when a user finds this out only after clicking the Save button, but it should meet you "force and keep" requirement.

0 votes

Comments
Michael Reed
Jul 19 '17, 1:15 p.m.

Hi Donald,


Thanks! I thought about this but the really annoying part is that I can't customize the error message to help the user understand why the value needs to change to Unassigned. However, I may still pursue this if the stakeholders are willing to deal with the training and usage aspects with their users.

Donald Nong
Jul 19 '17, 8:17 p.m.

You do have the option to customize the error message. See the sample code here:
https://jazz.net/wiki/bin/view/Main/AttributeCustomization#Script_Based_Validation

Michael Reed
Jul 20 '17, 5:37 p.m.

 Thanks for the reminder Donald!

Permanent link
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (63.9k●3●36●48) Jul 19 '17, 2:24 a.m.

I am not sure if a read only by condition would work. The safest would be a work item save advisor. I agree to Donalds statement though.

0 votes

Comments
Michael Reed
Jul 19 '17, 1:20 p.m.

Thanks Ralph. 


The customer has limited support hours and wants them to last as long as possible. I did have an intern that was doing a great job picking up the slack that I was allowing to do some pro-bono work to help keep the customer happy and moving forward. Unfortunately, he took a job after graduating so I no longer have a resource I can leverage to keep costs down so creating custom advisors and spending the time and effort to do more than simple code changes will have to be put into the "nice to have" category for now.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jul 20 '17, 1:39 a.m.

I would argue what the business value of this customization is - I don't see any. I was actually about to add that to my answer, but then decided to save the time.

Michael Reed
Jul 20 '17, 5:40 p.m.

I totally agree Ralph. That is another reason I don't really want to spend cycles on this.

Permanent link
Nate Decker
(378●1●47●61) Jul 19 '17, 10:31 a.m.

I'm not sure I'm correctly visualizing what Ralph and Donald are suggesting. It sounds like they are saying there should be a pre-condition that will prevent you from moving the work item into the "Inventory" bucket unless the Owned By is set to Unassigned. Then once in that state, the attribute could be made read-only or another pre-condition could disallow modification of the attribute while in that state.

That would work, but it forces the user to set the "Owned By" before they can move it into the Inventory bucket. If that's considered more cumbersome than desired, there could be an alternative.

You could handle this with a follow-up action instead of a pre-condition. The Follow-Up would set "Owned By" to Unassigned if the work item was in the Inventory bucket. It would do it when the work item was first moved into that bucket and reset the value back to "Unassigned" if it was changed. You'd probably want to display some kind of warning when it does it though so the user doesn't get confused as to why they cannot set the value.

0 votes

Comments
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jul 19 '17, 10:39 a.m.

No, I said, you can try to use a condition and the operational behavior read only by condition to make the contributor attribute read only if owner is unassinged. I am not sure that will work.

The safest way is a custom work item save advisor that prevents the owner/contributor from being set, or the state to be changed if the owner/contributor is anything other than unassigned.
 

Michael Reed
Jul 19 '17, 1:36 p.m.

Thanks for the response Nate.


Donald's is a simple mechanism that really just says that a user can't save the work item into the Inventory state until the Owned By value is changed to Unassigned. If it were easy to provide customized error messaging or even a pop-up while transitioning into the Inventory state to explain to users that they need to change the value to Unassigned then it would end up being the simplest solution.

Ralph's is, as always, (no offense Ralph 8D) is more code focused as I would expect from the main proponent of API coding endeavors. I just don't have the resources available to spend time developing a more robust solution.

I'm going to have to think about your follow-up action paragraph. I don't think it is as simple as it is sounding and I have to admit that I'm not sitting in front of their process configuration at the moment to start considering possibilities. It is times like this where I really miss the simplicity and elegance of ClearQuest hook structures.

Thanks to all of you for your responses.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jul 20 '17, 1:50 a.m.

My personal experience and the experience with forum questions in that area with JavaScript Attribute customization is pretty bad. Various reasons, find some of the limitations here: https://rsjazz.wordpress.com/2016/07/15/rtc-process-customization-what-you-can-and-cannot-do/ and in many of my answers and the API description.

If I could I would rip the JavaScript attribute customization out of the tool. It is far too limited but too easy to access so it seems to also attract users that probably don't have programming and development skills. This causes all kinds of issues (e.g. impact performance). Business Process customization should be limited to stuff that is worth the effort. Obviously I am not very successful in advertising that aspect.

Just because I publish a lot of API example does not mean I want to promote to implement stuff just because one can. It has to pay back the development which means if only the Java Server API was available users would really start thinking if they need certain stuff or not (you mentioned a free resource which s now gone - I'd say no resource is free).


Michael Reed
Jul 20 '17, 5:55 p.m.

Thanks for that insight Ralph. Since I am usually contractually bound with very budget conscious customers (aka cheap) I try to look at the expedient way to accomplish most of the requests that come in. That usually forces me to spend time with the JavaScript attribute customization although there have been times where we needed to develop a robust solution using the API. 


My problem is that I don't use the API on a regular basis because I usually delegate that down to interns that can spend more time working on it while I'm still being productive getting with the implementation and mentoring/training.

To be honest, the API is extremely tedious and problematic for new users and, if you are not knowledgeable with Eclipse or Eclipse plugin development it has a steep learning curve.

Most, not all but most, of my customers are happy with the out-of-the-box functionality with some customization to attributes and forms and not as much automation, REST or API mods since they want to take full ownership at some point it doesn't make sense for them.

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.

Ask a question
Guidelines
FAQ
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,938

Question asked: Jul 18 '17, 12:53 p.m.

Question was seen: 1,756 times

Last updated: Jul 20 '17, 5:55 p.m.

Confirmation Cancel Confirm