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:
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
Ralph Schoon (63.5k●3●36●46)
| answered Oct 09 '15, 4:15 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Oct 09 '15, 4:16 a.m.
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. |
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. 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.
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.
Ralph Schoon
commented Oct 13 '15, 2:11 a.m.
| edited Oct 13 '15, 2:13 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
|
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.