Run a JavaScript Validator (or anything) on Document Load Event? RTC 5.0.2
I've run into a situation where I need to make an attribute with an input field look read-only to a user without actually setting it as read-only in the editor presentation or attribute settings, all based on the value of another attribute.
(For the purposes of this code and conversation, let's say it's a Defect work item type, Defects have an internal or external "Source" and based on that I need to make the input for the attribute "Special Number" read-only.)
I'd like not to focus on whether or not that's the best way to meet this need (there's more to it I promise), because one of my attempts would seem to be helpful for several other needs if it could be worked out. I attempted to write a validator for this attribute that assigned a function to the document.onload event. If it runs without a delay, there's no input field to change the CSS properties of, so the document needs to load first.
The problem is that the assignment works fine, but the function is never called when the document loads. I ended up resolving this (for the time being) with a setTimeout, but it would be extraordinary if we could work this out.
Here's a very abbreviated version of my attempted code:
dojo.provide("thisCode");dojo.require("com.ibm.team.workitem.api.common.WorkItemAttributes");
dojo.require("com.ibm.team.workitem.api.common.Status");(function() {var Status = com.ibm.team.workitem.api.common.Status;dojo.declare("thisCode", null, {validate: function(attribute, workItem, configuration) {document.onload = function() {var defectSource = workItem.getLabel("defect.source");var targetDOMelement = document.querySelector("input[aria-labelledby='Special Number']");if (defectSource === "Internal") {targetDOMelement.setAttribute("disabled", "");return;}}return Status.OK_STATUS;}});})();
Can anyone explain why, even though the assignment to document.onload works and the anonymous function that is supplied to it also works when using a setTimeout approach, these actions are never executed when the document's load event fires?
Does anyone have any ideas on a way to make this work (even if it has nothing to do with validators)?
2 answers
I am completely at a loss, what the code is supposed to do. The JavaScript capabilities that can be used in attribute customization are explained here:
https://jazz.net/wiki/bin/view/Main/AttributeCustomization
a more extensive workshop can be found here:
where Lab 5 explains JavaScript.
If you want to make a work item attribute read only based on some other work item attribute, you should use a condition and not a validator. Also see https://rsjazz.wordpress.com/2015/06/19/a-custom-condition-to-make-attributes-required-or-read-only-by-role/ for a more extreme case.
https://jazz.net/wiki/bin/view/Main/AttributeCustomization
a more extensive workshop can be found here:
where Lab 5 explains JavaScript.
If you want to make a work item attribute read only based on some other work item attribute, you should use a condition and not a validator. Also see https://rsjazz.wordpress.com/2015/06/19/a-custom-condition-to-make-attributes-required-or-read-only-by-role/ for a more extreme case.
As Ralph said, you should use a condition rather than a validator. In the condition (JavaScript) the code should return true when "defect.source" is "Internal", otherwise false. Then assign the "Special Number" attribute to this condition in the "REad-Only Attributes For Condition" precondition in the Operation Behavior configuration (details in Ralph's blog linked in his answer).
I have never tried to get a document property and change it in the attribute customization. It may not be a good idea.
I have never tried to get a document property and change it in the attribute customization. It may not be a good idea.
Comments
Attribute customization can not be used to directly write to any object. You can only return values. If the attribute customization is a calculated or default value, and the value returned is a valid value, this can change the attribute. Otherwise you can NOT change anything in an attribute customization.
Since Attribute customization runs in the Eclipse Client in the Web Client and partially in the Jazz Server (conditions, validators), you can not assume to be able to use the full event mechanisms or other values provided by the web browser.
Thank you Ralph and Don for your responses.
I should elaborate on the "situation where I need to make an attribute with an input field look read-only to a user without actually setting it as read-only in the editor presentation or attribute settings." The Special Number attribute I've been referring to actually needs to be modifiable whether Source is "Internal" or "External," in this way:
If Source is "Internal", users select checkboxes from other attributes and the Special Number is calculated (by a Calculated Value provider) according to those checkboxes. A user in this scenario should not be able to directly edit the Special Number by its input field. As long as we don't set Read-Only at the attribute level, this seems to work
If Source is "External", users need to directly input the Special Number, meaning the presentation needs to be editable. The challenge resulting from this is that after a work item is loaded into view, a user might toggle Source between "Internal" and "External."
Using a condition seems like a great idea. I considered it early on, but the documentation I found didn't seem to indicate that it would trigger in any situation except a Save. We really want users to immediately see that they can't directly edit the Special Number when Source is "Internal" immediately, not just with a message when they try to save.
With your input, I've started to test a condition with this code, and it actually looks like it gets triggered when the document loads, just like a validator, but it also gets triggered whenever an attribute on the page changes, which enables it to serve the live-toggling purpose that we need.
It's also VERY good to hear Ralph's point about event mechanisms. If we do this with a condition in the end, it will require thorough testing on all required browsers.
Have you even tried to use a condition? I don't think so and I think you should. You are making conclusions on something you have not yet well understood.
The condition essentially switches the editor presentation read only dynamically and the user can basically see that he can't enter anything any more, as soon as the condition says so. Changing the input value, would make the field read only at that point.