It's all about the answers!

Ask a question

Representing the Workflow as diagram in RTC WI. (version 4.0)

sandeep rao (131313) | asked Dec 16 '13, 6:07 a.m.
We would like to represent the workflow of the WI in a separate tab in the workitem. We have referred to the steps stated in the link:

and tried to implement the same in a script based default value and attribute of type large html but we are not able achieve the same.
Please find below the script file

(function() {
    var doDebug = true;
    var scriptname = "WorkflowStateScriptedCalculatedValue2";
    var WorkItemAttributes =;

    dojo.declare("com.acme.providers.script.WorkflowStateScriptedCalculatedValue", null, {

        getValue: function(attribute, workItem, configuration) {
            var workFlowState = workItem.getValue(WorkItemAttributes.STATE);
            debug("WorkflowState: " + workFlowState);
            // Adjust attachment numbers in the code below
            return "{{|New}}";
            function debug(display){               
                    console.log(scriptname + " " + display);

Kindly let us know where are going wrong. Thanks in advance.
Sandeep Rao.

sam detweiler commented Dec 16 '13, 6:16 a.m.

u need to remove the '|New' from the resource URL link.
it was just to help you know which content object to put there..|New}}";

sandeep rao commented Dec 16 '13, 6:32 a.m.

To add more inputs: We have also made the WI Attribute type as Wiki and image URL  "". 

sam detweiler commented Dec 16 '13, 7:03 a.m.

sorry, your comment is unclear.. do you mean it still does not work?

I thought the field needed to be Large HTML.  (maybe that is what u mean by 'wiki')

if u put that URL in your web browser, does the image open properly?

sandeep rao commented Dec 16 '13, 7:11 a.m.

Hi Sam,
It still doesnot render the image. If I put the URL in the Browser url, it will display dialog box for "Open/ Download image" and we did try with large html also and still didnot work.

Thanks again.

Accepted answer

permanent link
Ralph Schoon (63.2k33646) | answered Dec 17 '13, 6:52 a.m.
As described in Lab 5, there are several limitations. You have to use a Wiki Type attribute. You have to upload the attachments to a work item to make the preview work. You also have to make sure to get the right attachment ID to create the link.
Ralph Schoon selected this answer as the correct answer

vishnudharan manivannan commented Dec 20 '13, 6:35 a.m.

Thanks Ralph.. We were able to get the Workflow image in the Wiki attribute.. This is a great for a start!! Brilliant article :) 

5 other answers

permanent link
Abhishek Kumar (49722) | answered Apr 09 '15, 4:06 a.m.
Hello Marie,

If you are trying to achieve you business requirement by storing the workflow Images externally, then you should host those images as an URI not an URL(All the images stored in a RTC Workitem are of URI format). 

Also the Server in which you are hosting the image should expose a Public URI(No authentication mechanism should be present). if not then they will be rendered as broken link in the wiki attribute.

Hope that helps!


Abhishek Kumar commented Mar 27 '15, 7:01 a.m. | edited Apr 09 '15, 4:33 p.m.

Hello All 

I was trying to replicate the same scenario  in which i succeeded, but when i make the attribute as read only then RTC doesnot allow me to save.

the error msg shows that not able to modify the wiki type attribute.

Is there any way to make the attribute as readonly ?

Business Justification : User should not be able to edit the wiki attribute. He should only be able to see the possible workflow transitions.

Thanks in advance.
Abhishek Kumar  

sam detweiler commented Mar 27 '15, 7:58 a.m.

Don't make the attribute read-only..  (setting on each attribute)

Make the presentation of the attribute read-only (setting on each display element)

Ralph Schoon commented Mar 27 '15, 8:09 a.m.

If you set the attribute with a calculated value provider, you should be able to make the attribute read only. At least that is how it should work. It is even suggested to do so. Because you don't want to have users edit calculated values. If it does not work, that might be a defect.

Ralph Schoon commented Mar 27 '15, 8:16 a.m.

You should be able to make an attribute read-only and calculated values of attribute customization should still work. In fact, as far as I recall, this is a suggestion for calculated attributes. You don't want that to be edited by a user typically, also not in plans or queries.

If it does not, this might be a defect. I would suggest to contact support and provide the version of RTC you use.

Ralph Schoon commented Apr 09 '15, 4:40 a.m.

Thanks for sharing!

sam detweiler commented Apr 09 '15, 7:51 a.m.

 >then you should host those images as an URI not an URL

can someone describe the difference 

Abhishek Kumar commented Apr 09 '15, 8:49 a.m.

 In short URI is the identifier for the resource(in your case image) where as URL is the locator for the resource. 


Ralph Schoon commented Apr 09 '15, 9:08 a.m.

Marie Michelin commented Apr 09 '15, 11:07 a.m. | edited Apr 09 '15, 4:35 p.m.

Hello Abhishek,

Thank you for this information. In fact, I'm not sure exactly to understand what a URI is.
What is a format of this URI ? What do I need to put in place on the server storing the images ?
My URL is https://myserver/v01/State_0_Initiate.png.
So what is my URI ?

Is the syntax different fo showing it in a wiki attribute ? {{http://myserver/v01/State_0_Initiate.png|New}}

I'm still trying to make it works without success.

Thank you for your help,

sam detweiler commented Apr 09 '15, 11:17 a.m. | edited Apr 09 '15, 11:45 a.m.

  the point from the original reply on URL vs URL was that each specific image needs to be specified, NOT a generic pointer to a folder.

the technical speak here is that URL does NOT name a SPECIFIC resource, only the general (folder or path), while a URI includes the resource 'name' part. 

A better post (in my opinion) would have been:
Insure that the server hosting your images allows access to them without authentication, and that each image is named completely (ie  http://server/path/filename)

Geoffrey Clemm commented Apr 09 '15, 4:48 p.m.

On the URI/URL question ... to avoid terminological confusion I'm going to have to be a bit "disagree"able (so apologies to the posters I'm disagreeing with :-).
First, the statement:
  "then you should host those images as an URI not an URL"
is incorrect, so don't try figuring out what it means (:-).
A URI is just a syntax.   A URL is a particular kind of URI, in particular, a URI which when placed in a web browser, will allow you to access the resource identified by that URL.  So saying that is should be "an URI, not an URL" is saying that the image should be identified by a URI that cannot be used to actually access that image, which is clearly not what you want.
Second, the statement "URL does NOT name a SPECIFIC resource" is also incorrect.  A URL does name a specific resource, and because it is a URL, also names it in a way that a web browser can be used to actually access that resource using that URL.
But other than that, I agree with the statements made so far in this thread.

showing 5 of 11 show 6 more comments

permanent link
vishnudharan manivannan (1183642) | answered Dec 16 '13, 7:21 a.m.
Hi Sandeep,

I tried to reproduce the same , below are the steps I followed.

1.Create an attribute field in task WI called "Workflow" with type as Large HTML
2. Create a "default value" in attribute customization as "script based value"
3. Added the script for the attribute and also added the same in the presentation
4. Added the attachement link as mentioned


I don't see the image rendering as well. You might want to check the script again. I will come back with my findings by modifying the same.

Vishnu M

sam detweiler commented Dec 16 '13, 9:45 a.m. | edited Dec 16 '13, 10:05 a.m.

hm.. where are u guys getting the '142' number? 

from eclipse.. not the web UI.  never mind

sandeep rao commented Dec 17 '13, 12:42 a.m.

Hi Sam,

The 112 and 142 are two different attachment URIs we used for testing the above functionality  and was generated by uploading the file through Workitem link attachment feature. Kindly let us know if we are following the right step for generation of URI for attachments.

Thanks Again.
Sandeep Rao.

sam detweiler commented Dec 17 '13, 5:28 a.m.

yes, I see that now.. I was using the web browser and getting a different URL string.
I haven't had a chance to try with an html field.

permanent link
Marie Michelin (14317) | answered Apr 08 '15, 9:04 a.m.
Hello All,

I succeeded in this scenario, but as I would like to implement it in a process template for multiple project area, and then exporting it in another RTC installation, I don't want to store the pictures in a workitem attachment. I would prefer using project area attachment or external resource (that we can access with a URL), so that it is not mandatory to modify the link after importing the process template.

But it doesn't work.
If I try the first idea, I can't find a way to access the project area attachments.
If I try to access to a picture stored externally, it only displays a link, not the picture directly.
For example, I use the following "wiki code" : {{http://myserver/v01/State_0_Initiate.png|New}}

How can I do to display external images in a wiki attribute ?

Do you have another solution for my problem ?

Thank you for your help,

Ralph Schoon commented Apr 08 '15, 9:08 a.m.

You have to store it as an attachment to a work item, as explicitly stated in the description of the workshop. The image would only be displayed if you do it that way, because the image is provided by a specific REST service.

You can't store it as process attachment and, as far as I can tell, if you just provide an image URL, that is only shown as hyperlink and will not get displayed.

Marie Michelin commented Apr 08 '15, 9:15 a.m.

Thank you for your really quick answer Ralph!

I feared it was not possible another way than using a workitem, but I was hoping.

So how can I do to implement this in a process template that I export, then import in another RTC installation ? I prefer not to modify it after importing it.
Is there another solution ?

If not, does that mean that I must create a work item to store the attachments for each project area using the process template ?

Thank you for your help,

Ralph Schoon commented Apr 08 '15, 9:55 a.m.

I am not aware of any simple solution for this. I have shared what I know.
What you could try is, to host the images on a work item in one project area and reuse that for all others.

Marie Michelin commented Apr 08 '15, 11:55 a.m.

Thank you for your help.
I'll try as best as I can, but each time I will have to export the process template, I'll need to create a new work item, because these RTC servers don't see each others.
Whatever, really thank you for your quick answers!

permanent link
Abhishek Kumar (49722) | answered Apr 10 '15, 3:51 a.m.
 Hello Marie,

When you are Hosting the Image on the External application you need to make sure that the  application exposes the image a Rest Service 

the syntax will be as follows  using JAX-RS packages:

public class ImageService {
private static final String yourImagePath = "Image Path";
public Response getFile() {
File file = new File(yourImagePath);
ResponseBuilder response = Response.ok((Object) file);
response.header("Content-Disposition", "attachment; filename=image_from_server.png");

So when you implement this logic in you external application where you would be storing the image,the URI to the image will be: https://yourservername/applicationname/image/get

Hope this Helps.


permanent link
Marie Michelin (14317) | answered Apr 10 '15, 5:07 a.m.
Hello Abhishek,

Really thank you for the precision. It's really clearer for me now.

Today, my images are stored on a folder on an IIS web server with a WebSphere Platform.
I'm not administrator of this server and I'm not used to it.
But I'll discuss with my admin to see how we could implement that.

I'll suggest him to use this link :
And we'll see.

Thank you for your help!

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.