You need to sign in to do that
Don't have an account?
VisualForce page being passed odd parameters by "New Event" standard button
I'm having some issues with a standard button on the Related Activities List on our Opportunities page.
The "New Event" standard button is overridden to point to a custom VisualForce page. However when the button is clicked and the request to that VF page made, there are a string of URL parameters attached which are causing some problems.
It seems the Id of the Opportunity is being passed as a "whatId" parameter which is good and makes sense. But the Id of the Parent Account is being passed as the "whoId"?? This is causing validation problems when the parameters are used to prepopulate the new event page and it's is saved (can't have non-contact/lead in whoId field).
I could ignore the weird whoId in the custom VF page when it's redirecting to the new event standard page, but I'd rather understand how the standard "New Event" button is getting it added to its action URL in the first place.
Here's the markup for the standard New Event button taken from the source code of the standard Opportunity page:
<input value="New Event" class="btn" name="event" onclick="navigateToUrl('/setup/ui/recordtypeselect.jsp?ent=Event&retURL=%2F006L0000002EAvn&save_new_url=%2F00U%2Fe%3Fwho_id%3D001L0000003cSD6%26what_id%3D006L0000002EAvn%26retURL%3D%252F006L0000002EAvn','RELATED_LIST','event');" title="New Event" type="button" />
Note the
who_id%3D001L0000003cSD6
bit. This is where the Parent Account Id is being inserted into the request URL as the "whoId" parameter. But as far I can tell, there's nowhere to control this behaviour and it appears to be standard.
Can anyone please help? Am I missing where the URL parameters of a standard button can be customised. Or is this a weird bug?
Thanks,
Ray
I must admit I've never noticed this before. Unfortunately there's nowhere to control this type of behaviour. The fact that the id doesn't actually populate the field when it goes to the standard page indicates that SFDC is doing some sort of checking against the id type, and I'd imagine you are going to have to replicate that. It does look like a bug - probably a side effect of the button having to apply to pretty much any standard or custom object - but I guess from the SFDC point of view it doesn't have any affect on the standard behaviour.
All Answers
I must admit I've never noticed this before. Unfortunately there's nowhere to control this type of behaviour. The fact that the id doesn't actually populate the field when it goes to the standard page indicates that SFDC is doing some sort of checking against the id type, and I'd imagine you are going to have to replicate that. It does look like a bug - probably a side effect of the button having to apply to pretty much any standard or custom object - but I guess from the SFDC point of view it doesn't have any affect on the standard behaviour.
Thanks Keir. I'll just filter out non Contact/Lead Ids in the VF page.
Cheers,
Ray