Yeah the template's just for dropdown. Sorry, have I completed thrown this off track by not reading your first post properly where you said RequestedFor (raise user) !! And I've jumped straight in at Raise User. You might have to scrap everything I've said, I can now clearly remember us having issues with Requested By & Requested For as the way we work it's not a manager requesting for a user it can be Joe Bloggs requested for 10 different branches and we have no way of being able to manage that within Servicedesk using a manager/user relationship so we sort of bypassed that functionality.
Sorry - again!!
So I've just loaded up an 7.4 OOTB DB and tested that and that doesnt work either.!!
I must be missing someting big time here then. I could see templates working for a CI as those templates in the OOTB are setting the Catalogue Heirarchy attribute value so yep that would do it but very hard coded.
Is that what you mean when you say it populates in the OOTB then?
I want it to pick the catalogue heirarchy for the CI it just plonked on the form that I selected.
So I'd disagree that the OOTB works OOTB as all I did was create a "generic" service CI, publish it and test.
See the Request Type field is blank.
The OOTB has this BOCR
Now that I come to think of it, my memory might be failing me in my old age, but one of the reasons I know this works is because I once did a remote control session to show you it working on my environment with your database restored. We felt it must be something environmental but we checked all the patches applied etc and they were identical. You were one of the customer's that I mentioned above where when I went to investigate it not working....it suddenly started working! In fact it is not my memory as I have found the case number which I've looked at but all I could say was that it wasn't working in your environment, it was in ours, we remoted on to your system for you to show us, and it worked. We agreed to leave it at that as there was little else then that we could then investigate as we couldn't replicate any fault.
The first step might be to get your database onto a different environment again to prove that it isn't design related. It seems like you've done quite a bit of investigation of this now, have you logged a support case? It may be that we need to do some tracing.
I've tested about every combination I can think of this weekend (should be in the pub instead!!) and on 2 different environments and the customers DB and the OOTB it both do the same.
My experience is that the Business Object Copy Rules (BOCR) are not firing when the Request form is populated as it opens from the Service Catalogue screen. I've tried this on 7.4 and 7.5. They do however subsequently fire if I reselect the raise user field manually on the form but that's too late. Fields do populate via templates OK then so I can set a static Catalogue Heirarchy value but I want the one for the CI selected from the Service Catalogue and short of creating loads of CI's its's not going to do what I want.
So if people can confirm the BOCR do fire normally when populating (which is hardcoded functionality in SD) from the Service Catalogue page then that must be my problem to solve.
Can you other guys/gals out there confirm yours do do this and if so I'll log a support call on this one as I'm otherwise out of ideas. I've IISREST until my fingers have bled!!
I've just removed the heirarchy object from the window because of this behavior. I just didnt have the time to really investigate it and try to troubleshoot it any further. I wonder if some of the object filters you setup as part of the upgrade are having an effect on the copy rules.
As far as I know this is still happening to me. I can put it back on the window tonight and re-test.
As I mentioned I can get exactly the same in teh OOTB 75 database so whatever is causing is something at source rather than something I've added subsequently. I've logged a case with Suppoort to see if they can confirm this.
Just to confirm on this thread for anyone who is on the edge of their seats waiting ;-) There's been some more investigation of this here (Jenny and I). The copy rule will not trigger when the request window is first opened. It will however, trigger on saving the request window so you could have the catalogue hierarchy field as read only on the end user window perhaps.
When I had seen this working on a previous database with Julian and on OOTB, there had been templates applied which were copying in the catalogue hierarchy when the window loaded. Sorry to have misled you on this!
Just an another little note on this, I found that you can filter the catalogue hierarchy list based on the Request - CI requested - Catalogue Hierarchy runtime value. This would mean that if an end user wanted to pick a value they would only see the category for the CI that had populated on the form in the category tree. Unfortunately though I found that the filter will not autopopulate the catalogue hierarchy even though only one matching value is found. I suspect that this is because it is a category rather than a reference list.
Thanks Karen, I thought I was going bonkers was about to check-in to rehab.
Are we in enhancement request territory here and are you aware of any ER to vote against?
Glad we avoided that!
There isn't a ER already for this no. I wonder if perhaps some people have just removed this from the End User window as was mentioned in a previous post. I wasn't sure I understood why it needs to be populated on the window on load when the user hierarchy is mainly for locating things within the catalogue (which the End User has just come from) or perhaps for reporting / filtering off (but you can get to it off the CI requested relationship anyway). It would be useful if you can add some information about why you wanted it populated when the window loads as that would be very helpful to Product Management.
We can also suggest that we remove it off the OOTB End User window if it's not really needed.
I tend to agree on the Catalogue Hierarchy issue albeit as you say it should also be removed from the OOTB to save confusion. I'll probably use NEW/UPDATE views to allow it to be seen on reopen as at least the copy rules do fire on the CREATE/save event.
That said I also wanted to have other copy rules firing too as the form opens which I think would be the main driver behind any ER.
For example again in the OOTB window field that gets populated when the form opens via the hard code is the RaiseUser field which has the label of "Requested For". The adjacent field with label "Requested By" field is blank. I wanted a copy rule to make this the same as the Raise User field on open as 99.9% of the time that's the case. Also is it just me or does it seem the wrong way around to anyone else because if I press the "Add to Cart" button in the SC then surely it should fill in me as the "Requested By" user....
That sounds like a good ER.
I've not tested this but in theory you could perhaps have a filter which filters the Requested By by the Raise User on the form and so autopopulates the field for you. You would then need a boolean tickbox set as default to False which could be named "Tick to alter Requested By" and then have this as a condition of your filter so that by ticking the box the end user is able to select from a list of users.