You’re offline. This is a read only version of the page.
Announcements
Hi,
I have written some JavaScript that triggers on an opportunity's OnSave event, in a nutshell it checks for open activities on the opportunity and cancels the save if there are none.
It's working great except for the fact that closing an opportunity as won or lost also triggers the OnSave event. Using GetSaveMode returns a value of 1, which is exactly the same as if a user had clicked the save button.
How can I determine that it was the opportunity close button that was clicked and not the save button?
Thanks,
Robin
*This post is locked for comments
Is there any value in getFormContext().data.entity.attributes.getByName("actualclosedate").getValue() as your javascript is triggered? (that code is definitely missing something - its stolen from the first piece of code I have to hand which is some minified r9 code).
Sorry if my explanation was not clear enough.
I am not suggesting to override the OOB dialog box. This is what I am doing in my system:
Scenario 1: Do not allow users to Close an Opportunity unless a PO has been created.
On click of 'Close as Won', my custom script checks if the PO field has a value.
If no value is found, the user is prompted to create a PO.
Scenario 2: In case the PO field has a value, then call the internal functions which show the OOB close as win/lost dialogs
Robin - In your case, instead of checking for PO field, your function will be doing a check of the open activities.
Let me know if you need more details.
Thanks, I've tried that and there's nothing I can see in the event source or the data being saved that can differentiate between the buttons, as you say it's a save followed by a status change
Those buttons open up the opportunity won and opportunity closed forms within a modal dialog box which are currently not customisable.
Ben - Why wouldn't the customization of those buttons never work?
What exactly were the customization that you were doing at that point?
Agree on the risk of a later release changing all the internal function names.
The risk with 2 is that a hotfix will be released that reverts that code back to standard behaviour.
Equally from the experiments I've seen conducted on customising those buttons I've never seen them work. The last time anyone suggested customising those buttons we ended up hiding them and creating custom ones that triggered custom business workflows that asked the appropriate why did we lose or how did we win questions.
Hi Robin,
How about doing the following?
1. Assume that the function you call in the OnSave is 'checkForOpenActivities'.
2. Modify the OOB 'Close as Won/Lost' button to call a custom javascript function, which then calls the checkForOpenActivities function.
If open activities are not found and all is good, then call the OOB function (just launches the modal pop-up window) in this piece of code.
So basically, what I am suggesting is that you do the required checks and depending on them, show the pop-up to the user.
A closed opportunity is (from memory) a record save request followed by a status change request - I say from memory as it's perfectly possible (from 2016 onwards if I remember correctly) to perform both functions in a single save request by including the statuscode within the update.
Hence the only way you could identify whether the save is a simple save request or a closure request would be to check what fields are being updated and if actualclosedate has a value in it then it likely to be a closure rather than a save.
Hi,
Thanks, but it appears the save event is triggered before the close event so the status is still at 0 when my script runs
Hi Robin,
Can you put a condition like below to check the status as close/won :
if(status == 1)
//do something
#1
André Arnaud de Cal...
294,095
Super User 2025 Season 1
#2
Martin Dráb
232,866
Most Valuable Professional
#3
nmaenpaa
101,158
Moderator
Share
Report
All responses (
Answers (
