Still able to save when an attribute is invalid, but only when the work item proxy is accessed in the validator script.
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
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.
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.
Comments
2 other answers
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).