The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
SalesLogix Function
Posted: 06 Jul 06 4:25 AM
|
fiogf49gjkf0d Hello everybody,
I'm planning to log every opportunity deleted by user. Is there anyone here can explain me where can i find the function that delete opportunity so that i can modify it.
I've try to find it, and found only two plugin script that might related with opportunity delete. They are opportunity management and global system. 
Thx b4, -Fajar |
|
|
|
Re: SalesLogix Function
Posted: 06 Jul 06 9:03 AM
|
fiogf49gjkf0d I do not think you can get at the code that does the deletes. I believe the deletes are handled by the DeleteItem function that lives in the SalesLogix.exe. The deletes are controlled from the "Standard Menu" menu strip.
What you can do is change the menu strip so it calls a custom script that front ends the calling of the deleteitem function. It the custom script you can log what you need, then call the DeleteItem function.
|
|
|
|
Re: SalesLogix Function
Posted: 06 Jul 06 9:29 PM
|
fiogf49gjkf0d thx Mr Frank, your idea is good enough. But there is one problem how can i know the item that deleted was an opportunity, not the account, contact person, or the other.
For that purpose, i'm using "stupid" way by using Application.BasicFunctions.CurrentOpportunityId If the item to be deleted is an opportunity, then the opportunityid <> "", else empty string.
Is there any "smarter" way?
thx again, -Fajar |
|
|
|
Re: SalesLogix Function
Posted: 06 Jul 06 11:30 PM
|
fiogf49gjkf0d The script that is called from the menu will need to sense which view it was called from. Here is a piece of code from a script that I used to break-in on the account delete process. You should be able to adapt it to break in on the Opportunity delete process.
Dim strResult Dim sCurrAccID Dim sCurrViewID
sub Main
sCurrAccID = Application.BasicFunctions.CurrentAccountID sCurrViewID = application.BasicFunctions.CurrentViewID
' Check to see if we were call from the account screen If sCurrAccID<>"" then If sCurrViewID=sCurrAccID then ' add your custom code here end if end if
' Call the delete item funtion Application.BasicFunctions.DoInvoke "Function", "Edit:DeleteItem"
end sub |
|
|
|
Re: SalesLogix Function
Posted: 10 Jul 06 9:31 PM
|
fiogf49gjkf0d Mr Frank,
It's almost the same with my previous idea, with a little bit different in the part of comparing the current view with the opportunityid.
Btw you forgot one thing, that after you called the DeleteItem function, the user can still cancelled the delete action. So I put the log code after I check that the current opportunityid is not exists anylonger in the table opportunity or in simple manner, the opportunity has been deleted.
Anyway, thanx for your quick response.
-Fajar |
|
|
|
Re: SalesLogix Function
Posted: 30 Jul 06 5:39 PM
|
fiogf49gjkf0d Shooting from the hip: A - Create a custom secfunction called: DeleteOpportunity B - Add a global (handler) script to grab it.. you could even return false to prevent the delete. OnBeforeFunctionExecute_DeleteOpportunity -- rjl |
|
|
|
Re: SalesLogix Function
Posted: 31 Jul 06 7:57 AM
|
fiogf49gjkf0d Fajar,
There is one other option - dependant upon your environs. You can add a trigger on the Opportunity Table itself. Grab the deleted Opportunity information and throw it to an archive table.
Unfortunately while this is a quick and effective method - it won't work well with remotes.
Carla |
|
|
|
Re: SalesLogix Function
Posted: 01 Aug 06 9:07 AM
|
fiogf49gjkf0d While nothing would happen when someone deleted an opportunity on a remote database, the trigger should kick in when syncing causes the host to delete the opportunity. So you would still end up with the information saved on the host. I don't know what Fajar is doing with the information, but if he is only using it as administrator, then the old opportunity information doesn't need to be in the remote databases.
The other problem with remotes is that if you want to save the ID of the person that did the delete, you might not have the proper context to do that when the host syncs the delete event.
|
|
|
|
Re: SalesLogix Function
Posted: 01 Aug 06 12:34 PM
|
fiogf49gjkf0d Good Point on the trigger! However, you could easily customize or other to grab that userID to take care of that issue.
c |
|
|
|
Re: SalesLogix Function
Posted: 09 Aug 06 2:46 PM
|
fiogf49gjkf0d (SQL) Triggers are fine for some things. However, SecFunctions and Global Script(Handlers) were designed specifically to build these types of hooks w/out resorting to using "unsupported" methods like triggers.
I use one trigger on every production SalesLogix (main db) we do: We install an "instead of Update" trigger to prevent the changing of the pingserver in the Systeminfo table. That is teh ONLY trigger we ever use.
-- rjl |
|
|
|
Re: SalesLogix Function
Posted: 10 Aug 06 8:15 AM
|
fiogf49gjkf0d Carla,
It can work but you would need to provide scripts to the remotes for them to run to add the trigger to the database. I did this a long time ago to add a SP to remotes. I'd have to dig up notes on this to remember.
Another method would be to connect to the remote database when they are on the network and add the trigger to the remote database through Query Analyzer. I've done this more often (we have only a few remotes here).
Oh, also if the remote logged into the network you could have a custom script that runs when they login instead of them running it themselves.
John G. |
|
|
|
Re: SalesLogix Function
Posted: 10 Aug 06 2:10 PM
|
fiogf49gjkf0d If you manually add the view to the remote you will need to remember to manually add the views every time you create a new remote database. |
|
|
|
Re: SalesLogix Function
Posted: 10 Aug 06 2:25 PM
|
fiogf49gjkf0d Frank,
You are absolutely correct. In our case here, we have few remotes and for some the views or SPs would never be used.
I was applying this to the above situation where a trigger was going to be added to the main database. The problem that was brought up was that the remotes would not have it then. The solution of having the trigger added via script or manually would be a one time thing for existing and any new remotes. Where as if it weren't done, NO remotes would have the trigger.
John G. |
|
|
|
Re: SalesLogix Function
Posted: 20 Feb 08 7:17 PM
|
Hi all
I have done some R & D on this and came to know that when ever you are deleting an account/contact/opportunity it is calling a script called global system where we can have a function onbefore delete account on before delete contact and so on . So we can write our own custom code over here so that this code will fire first and then delete item code will fire. IF we want to avoid of firing the delete item code we can avoid it. They did same for delete campaign.
Thanks and Regards mark
|
|
|
| |
|