function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
rayjguyrayjguy 

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&amp;retURL=%2F006L0000002EAvn&amp;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

Best Answer chosen by Admin (Salesforce Developers) 
bob_buzzardbob_buzzard

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

bob_buzzardbob_buzzard

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. 

This was selected as the best answer
rayjguyrayjguy

Thanks Keir.  I'll just filter out non Contact/Lead Ids in the VF page.

 

Cheers,
Ray