Way to gather intermediate data from user during action?
![]()
Is there a means of gathering data from the user in a work item during the course of executing/saving an action in a process configuration?
I'm not, of course, talking about the obvious case of issue the action, user enters data and saves. This is more related to the fact, during the save of an action, we need to do a query based on an attribute that was altered, parse the results and present choices to the user to select, and proceed on with that action with the choices made. Here is what we currently have.
At some point after 2, but before 3.b above, we need to - Query RETAIN based on Component attribute (we can do this in our plug-in code). - Parse RETAIN results into attributes for selection. (We would like to use dynamic enumerations when they are available (Story 95178), but may just use plain text attributes until that time.) - Use the selections during the primary action invoked within the Work Item Save Participant (3.b.i). (This will have to be a manual cut/paste from text attributes, until we can potentially use a calculated value provider on the dynamic enumerations.) I have a few ideas, but unsure how valid any of them are, or if I'm missing something obvious. 1) I'm not sure if I can implement something in the Work item Save ADVISOR, or if we'd need another type of new advisor defined, and possibly added prior to the Attribute Validation in the Team Configuration, Operation Behavior? I dont know if there is a way to do the query / pause and gather the user selections at this point? 2) We have this function in our CQ implementation, which utilizes an action button. This is available prior to step 2 above. Is there something similar available in an RTC process configuration? Something that could possibly invoke our plug-in functions to do the query? This is a manual process from the user to trigger this, but at least it is during the intended action. I thought of some klugy way, possibly with some sort of boolean attribute, a dependency on that in the selection attributes that get populated, and a calculated value provider. But I dont know if the provider script can access our plug-in code to do the query and process the results. I see there is limited capability within the script. 3) Our least ideal / least desired option. We are currently implementing a form of modify-only actions. I was contemplating a type of this action that the user would have to explicitly execute prior to step 1 above. This would go through steps 1-3 above for this "modify" action to query / gather / select the intermediate info. THEN the user repeats the process explicitly for the main action it is intended for. The 3rd option is undesireable for us because its a manual preliminary step, disjoint from the main action. It is different from the RETAIN action we are modelling. (Users familiar with the RETAIN function would need to learn how to do this extra step, which goes against what we are trying to accomplish.) Also, this extra step only applies to a certain action (or 2). We would need to "un-do" some of the work if an entirely different action was to follow. It is possible, but not the neatest solution. Any recommendations are appreciated. |
3 answers
![]()
That would be interesting to see implemented. I'll follow this topic. Sorry I can't really help you with this, but I think that functionality would be useful.
I think calculated attributes might be the best way to accomplish that. Once the user fill the attributes you need to perform a query, you call an attribute provider (automatic trigger) to present choices to the user to select. |
![]()
Thanks Eduardo.
I've been thinking about this for a while, and considered it more after posting this. I think I realize the Advisor isnt the place for this. As I've witnessed, updating attributes from our plug-in code called within the Advisor/Participant doesnt seem to show up for the user (often have to do a manual refresh AFTER a save is completed). Use of calculated value scripts does appear to display changes as they are made. So it does appear we may need to use some sort of provider script approach. I think there are a couple of hindrances currently with a script. We couldnt use one based on the "key" attribute change (ex Component), since that kicks off the provider on a character by character change (we would potentially be doing queries on partial Components; dont know when "end of input" occurs). So I may need to use an alternate attribute, such as the boolean I mentioned (really simulating a button of some sort). Also, I believe access beyond provided work item attribute access is limited or non-existent in the script. I may have to study that more. I'm kinda chasing my tail in circles over this at this point. Just confirmed with our lead developer that the modify action option is really far less than ideal. |
![]()
Just wanted to add that we are waiting to see how RTC implements Story 95178 to handle the querying/data gathering as well as the enumeration population.
|
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.