It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,788
×10,827
×17

question asked: Oct 28 '15, 11:45 a.m.
question was seen: 2,831 times
last updated: Mar 21 '19, 9:55 a.m.

Related questions

FAQ - How this Forum works

Still able to save when an attribute is invalid, but only when the work item proxy is accessed in the validator script.

0
Matthew Inman Cochrane (38●3●7) | asked Oct 28 '15, 11:45 a.m.
edited Oct 28 '15, 11:58 a.m.
I've seen posts on validators not working as expected where the resolution was to apply the "Attribute Validation" precondition. I've applied that to every role.

I've seen posts on validators not working that came down to the version of RTC, but as far as I can tell, 5.0.2 is not one of the problematic ones (also, I can get validators to work just fine).

This situation is one where my script looks at the workItem._proxy object for information. What happens is that the appropriate attribute will be marked as invalid, the Severity will be appropriately set to ERROR, and RTC will still save changes (even to State) to the work item. I've narrowed the problem down to accessing the proxy object (via getProxy() or directly).

For testing, I made a validator that is always invalid. 

dojo.provide("developer.alwaysInvalid");

dojo.require("com.ibm.team.workitem.api.common.Severity");
dojo.require("com.ibm.team.workitem.api.common.Status");

(function() {

var Severity= com.ibm.team.workitem.api.common.Severity;
var Status= com.ibm.team.workitem.api.common.Status;

    dojo.declare("developer.alwaysInvalid", null, {

        validate: function(attribute, workItem, configuration) {

            var myProxy = workItem.getProxy();

            var resultStatus = new Status(Severity["ERROR"], "This is a test. This is only a test. Do not panic, this is a test.");
            console.debug(resultStatus);
            return resultStatus;
        }
    });
})();

When I comment out the myProxy declaration, or even set it to a literal, this works. The attribute is invalid and I am not permitted to save (red message box in the header and everything). When any access to the work item proxy is included, RTC lets me save (no red message box).

My question comes down to this: is there a safe (or safer) way to access the workItem proxy, or even create a new one as needed?

(Edited for formatting)

Accepted answer

0
permanent link
Ralph Schoon (63.1k●3●36●46) | answered Oct 29 '15, 3:24 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I have never seen the access to this method in any script I have ever seen. I am also not sure what this would return and why you even wanted to use it. I am not even sure if this is a supported method in the JavaScript layer that is supported across the platforms. If you run in the Web UI then there are obviously other objects around, but this is only because of the environment. If you run in the Eclipse client, that would not be the case.

https://jazz.net/wiki/bin/view/Main/AttributeCustomization#API_for_Javascript explains the available API and as far as I am aware, that is pretty much it.

So I can't answer this question.
Matthew Inman Cochrane selected this answer as the correct answer
Comments
Matthew Inman Cochrane commented Oct 29 '15, 1:07 p.m.
Thanks for giving this consideration and a response, Ralph. True, I was trying to use some of the non-supported methods that are available to the workItem object.

It looks like the supported methods are really wrappers for _proxy methods that pass them safe parameters and avoid errors, while most of the unsupported methods just return the _proxy equivalent.

What I find particularly interesting is that some of the objects (within the _proxy object within the passed workItem object) should be perfectly accessible directly. They are accessible actually, the variable in my validation script always gets the expected object when its assignment occurs. Yet the presence of that access still breaks the save-prevention mechanism of the validator.

What I'm really after are the linkDTOs, which I can access directly with workItem._proxy.object.linkTypes.linkDTOs, but that still breaks things.
Matthew Inman Cochrane commented Oct 29 '15, 1:08 p.m. | edited Oct 29 '15, 1:10 p.m.
It's also interesting that workItem.getValue(attributeId) is a supported method that, itself, uses workItem._proxy.getValue, which can use workItem._proxy._getLinkType which returns workItem._proxy.object.linkTypes.


Maybe that opens up the door for a safe method to get link types by injecting one of those methods along the way with specific arguments to ultimately get the linkTypes returned. It seems remarkably roundabout when I would think dot notation should be fine, but I'll give it a shot.

I just still have no idea how any of these scenarios completely prevent the save-prevention mechanism from working. There's still an invalid attribute value after all.

Ralph Schoon commented Oct 29 '15, 1:33 p.m. | edited Oct 29 '15, 1:34 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

If I want more data, I use the Java Extension point and develop a Java provider. See https://rsjazz.wordpress.com/2013/06/26/attribute-customization-java-based-value-providers-conditions-and-validators/

I don't have the background and knowledge about what happens if you use the internal JavaScript API's so I can't comment on that, really.

And again, these proxies might not be available if the script runs in the Eclipse client. I think validations run in the server anyway, but I am not totally sure.

2 other answers

Most liked answers|Newest answers ↑|Oldest answers

0
permanent link
Olivier ROSET (50●1●21) | answered Mar 21 '19, 9:55 a.m.

Hi Matthew,


have you solved your problem with the Attribute Validation and the usage of workItem.getProxy() ? 

0
permanent link
Matthew Inman Cochrane (38●3●7) | answered Oct 30 '15, 5:49 p.m.
 Ralph's point about supported methods sent me on a path of comparing other sibling methods to the three supported ones.
The supported ones are wrappers for further getters at the workItem._proxy level. If one debugs slowly enough, the save-prevention mechanism will work, but at full speed it won't if any of the non-supported methods are used (or direct access to objects beyond ._proxy is attempted). I've even tried copying wrappers and making tiny adjustments, but it never goes well.
I'll be looking into a Java extension to provide information about links in a reliable way that doesn't result in a race condition (if that theory's correct).

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.