Attribute customization: is it possible to get the work item save additional parameters value via JavaScript API?
We use RTC's script-based customization for Required Attributes For Condition and Read-Only Attributes For Condition. We would like to pass runtime data to the customization scripts as part work item saves done programmatically via the RTC SDK. Work item save additional parameters looks to be a possible mechanism to do this. Is it possible to get the work item save additional parameters value in our script-based customization via the JavaScript API (or in some other way)?
showing 5 of 7
show 2 more comments
|
One answer
I don't think so.. the parms to the scripts are limited.. the 'configuration' parm is the only one that would have any flexibility, but not on a per transaction basis.
Comments
Ralph Schoon
commented Mar 07 '16, 11:23 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I don't think you have access to the "Additional Save Parameter" values, that you can access in pre-conditions and follow up actions. Within the Attribute Customization framework. I had a fairly deep look into what can and what can't be accessed I never came across these. Of course I did not force to put an additional parameter in the save, so I could have missed it.
|
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.
Comments
What kind of "additional parameters" do you have in mind? You can probably use global (non-local) variables to achieve this, but a well-defined use case will be easier for the discussion. For a sample of the non-local variables, see the below post.
https://jazz.net/forum/questions/217064/rtc-601-make-required-attribute-depending-of-the-previous-values
0ur scenario is that we need to temporarily bypass Required Attributes For Condition and Read-Only Attributes For Condition checking when programmatically updating / creating a work item. We currently do this by setting an "internal work item attribute" to true. We then reset the internal attribute back to false in a work item operation participant via an additional work item save. While using an internal attribute does work, it has following issues:
(1) The additional work item save causes unnecessary / unexpected emails to be sent to the work item subscribers. This is a critical issue for our users.
(2) The additional work item save causes significant performance overhead.
(3) Additional logic is required in our operation advisors / participants to properly handle the addition work item save.
We are looking to address these issues, especially the first one, by using work item additional save parameters, rather than an internal attribute, to indicate that Required Attributes For Condition and Read-Only Attributes For Condition checking should be temporarily bypassed.
I don't fully understand what "additional work item save" is, as I haven't done much advisor development using the RTC SDK. But as you indicated that you use JavaScript condition scripts, will it be beneficial to just return "false" at the beginning of the condition script, when seeing a particular variable (my choice is a JavaScript global variable) is set?
Don, when you save a work item with the client or server API, you can provide "Additional Save Parameter" - basically strings. There are some built in ones e.g. to create back-links. Another way to use them is to allow automation to cope with recursion. E.g. in an automation, you could save a work item which triggers the same follow up action again. You can use an additional save parameter to communicate the reason for the save to other participants e.g. to avoid to trigger any more subsequent saves.
Don, can you point me to information on RTC's use/support of JavaScript global variables? Specifically, I need to know if a JavaScript global variable can be set in a standalone Java application using the RTC SDK to access RTC and subsequently read in a JavaScript used by the Required Attributes For Condition and Read-Only Attributes For Condition preconditions.
The developer working on this reminded me that we use a SKIP_VALIDATION_ATTRIBUTE_NAME parameter to bypass attribute validation. The SKIP_VALIDATION_ATTRIBUTE_NAME parameter is described in RTC Enhancement 149021 Provide a way to bypass validation checks. In Enhancement 149021 we pointed out that the SKIP_VALIDATION_ATTRIBUTE_NAME parameter doesn't work for the dynamic read-only and required attribute validation done by the Required Attributes For Condition and Read-Only Attributes For Condition preconditions. I opened RTC Enhancement 209216 Need way to bypass dynamic read-only and required attribute settings when saving work item via the RTC/JTS Java API to address this limitation.
Geoff, regarding JavaScript global variables, I only learned it from studying the source code (using ?debug=true), and am pretty sure it works on the client side (browser). As long as the custom function is called, the defined variables will stay there during the life of the web page. Server side JavaScript is much harder to debug and trace, and I have little experience with what can be done or can't be done there.
It seems that your use case is way more complicated than I originally thought, so the global variable idea may no longer be feasible.