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
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.
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.
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
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).