We already provided the url to customer however did not help to fix, any alternative steps will be helpfull.
what URL are you using? There are a few different ways to get to a record...
below is the url, removed the server name, could you please list the steps how this can be achieved.
removed the server name
Well...breaking it down
This is your web server
This is your context
This is telling it you want to open a form
opening the form
Setting the Mode to Modify
Here, we are setting specific fields on the form 'SHR:LandingConsole'
And Here, is just the cache ID, that we can ignore.
So, based on that breakdown, I would say that there is workflow on the SHR:LandingConsole that uses the values being passed in to tell it to open HPD:Help Desk form with a qualification of %271000000161%27%3D%22INC000001158502%22, which un-encoded = '1000000161'="INC000001158502"
So....with this, I would say that you aren't actually opening the incident directly, you are using existing workflow on the Landing Console to open the incident for you...so, what you will need to do is add an additional &F into your existing URL, providing the proper field ID and value to the landing console, and then likely modify the workflow that's firing on the landing console to pass your new field onto the destination form appropriately.
Does that help any?
It is possible, but it is a bit more complicated as he is trying to do 2 things at the same time.
1. Find an existing record for modify in a window open action
2. Send data to that opened window
One way is to use an EVENT (and the Run Process of PERFORM-ACTION-SEND-EVENT) so the child form (HPD:Help Desk) can get a value from the in-memory data of the parent form.
Another option would be to push the data you want into a temp form (using the ID of the target form as a key) so upon opening of the child form (HPD:Help Desk) you can do a set fields action to pull the data.
A 3rd option is to use a global field. (Set the data into a global field and you can then grab it after opening of the record in HPD:Help Desk)
Thanks LJ and Fred for your replies. Sorry for the delay in my response, I am just getting to coding this now.
So far, with your suggestions, I have modified the URL that hits the Landing console to include a F post as follows:
This is properly setting the new field on the SHR:LandingConsole form.
Next I have written an active link on the SHR:LandingConsole form that runs after the hpd:help desk form is loaded into a view form which does the following:
PERFORM-ACTION-SEND-EVENT # InteractionIsTrue
I also wrote an AL on the HPD:Help Desk form to capture the event, but its not working. It runs on EVENT and the runif is as follows:
$EVENTTYPE$ = "InteractionIsTrue"
In the AL logs I see the AL on the landing console run, but the AL on the help desk form fails the runif for some reason.
I am starting to think this has to do with the view field the landing console uses to open the inline form.
Any help is appreciated.
I agree, forms inside view forms don't act exactly like normal forms do...
So...I think your problem is that the window opened in a view is not considered a 'child' window per se...so...looking at some stuff, you might be able to send it, instead of to #, try keyword $LASTOPENEDWINID$...not guaranteed that it'll work (because it's not really a window)...but you can at least give it a try.
Thanks LJ. I will give anything a try at this point. Let you know how it goes after the flush.
In fact....one MIGHT be able to consider the fact that # doesn't trigger an event on a form in a view field as a 'bug'...one might be able to argue that it IS a child window, and the fact that you can't reference it as such in event workflow is a bug....so....I would actually open a ticket with BMC regarding that and see what they have to say about it
And that's why I tried the #, as a catch all test. I tried with your suggestion ($LASTOPENEDWINID$) with no luck. I see it in the logs sending the event, but the runif on helpdesk is still failing.
PERFORM-ACTION-SEND-EVENT ARRoot1452617743314 InteractionIsTrue
I've opened another issue with BMC, will see what they have to suggest.
So...the active link is showing as an event being triggered to the window....that's at least a step....that means that the fire event is occurring....now...to help figure out what is going on....
So...if the run-if qualification is failing, add an 'else' action that gives you a message prompt telling the you values for all ef the event keywords, so you know what event data is being sent....from that you should be able to tailor your run-if properly
Just for a test use * to send the event to all windows (to see if the form in the View field will see it)
Worst case would be to use the temp form idea (push data to a temp form and have the child form go look for that data)
Sorry my bad, the AL was executing on window loaded also. Removed that, cache flush underway. I dont think the event is being sent to the help desk form.