I have a logical hook added after saving an activity, e.g. Call, Meetings. On my hook code, when I receive the module bean, for example I created a Call event for contact John, when it triggers the hook how do I know from what bean or module is the user associated with the activity? Account/Contact/Lead.
What I tried was checking for $bean->parent_type, but I found out that for activities with Contacts, it still return Account as parent_type, and I wouldn’t know what relationship bean I should load, if I want to get the email address for that recipient of the activity.
when running an on-save Logic Hook in calls/meetings.
I guess it depends what you want to do with the email address.
Also - the built-in Workflow technology is pretty powerful -that is code-free; a better choice than coding logic hooks in many situations: but it depends on what you want to happen on-save? You may already have ruled that option out?
Thanks for the reply! Sorry I just notice it. Actually I need to save the email and or any other data that belongs to that person in my custom database table to be use in other custom module. I haven’t check the built-in workflow, since I’m new to SuiteCRM, but I wonder if that is possible on my case.
If we are talking about specifically the Call module there are additional fields you can refer to.
So yeah, the first field to check is the parent_type + parent_id, you can do an immediate check on that to see if the module name = “Contacts” and do your code magic from there.
Then I would check the individual relationships between the activity module (Meeting/Calls etc) to the Contact itself. This will be in the relationship field contact_id. If that is empty then it doesn’t have a contact associated.
Have a look at the Call/Meeting vardefs and that can give you a good idea of what information it helps.
Then getting that Contact from the Call/Meeting contact_id is a matter of contact->email1 (in most cases).
Have you good reasons to have the same data (email address) in two places?
Usual good database practise is to have data in just ONE place. Not doing that causes lots of time wasting later: due to the dilemna 'which place has the correct data, now?! which can I trust?)
It sounds like you may want to slow down before coding your custom module; and
write down your ‘objectives’ for what users want to do. A non technical document: written in the style of User Stories (if you are familiar with Agile):
a user of type __
when they are doing task X
they want to be able to do Y
because …Z
It might need probably 2 or 5 or maybe 10 such Stories.
Potentially there would be feedback from the forum that is more focused to your specific objectives, if you posted that text here, for suggestions.