How to use Note module parent_type field in Tasks

SuiteCRM Forum - English Language SuiteCRM General Discussion
1

I want to use the parent_type field used in Notes in the Tasks module:

I read the instructions on how to create a new field:

https://docs.suitecrm.com/blog/creating-custom-field-types/

But since the field already exists in the system, it seems like the wrong way to go.

Thanks!

2

If it already exists, don’t create it. Just add it to the views in Studio / Layouts.

You probably want the Detail view only, not the Edit view, as editing that field can mess up the database, unless you add some code for validations etc.

1 Like
3

Thanks, pgr. I missed it somehow. Here is my dilemma, I am importing data from Salesforce that had two of these fields, WhoId and WhatId. Well, SuiteCRM only allows one of these fields, is there a good reason why that is and can it be overridden without breaking something?

My current plan is to put all the What Ids in the parent_type as there is more diversity. The Who Id field I can mitigate with two relate fields, one for Contacts and one for Leads, and then programmatically distribute, but it just seems janky. I would like to be able to have two parent_type fields and just increment the fields in the table with a number just like the relate field.


$ ./sfcsvparser_v2.py -f Task.csv -m Tasks -d |grep "Walk: WhoId" |awk '{ print $3 }' |sort |uniq -c
   7462 Contacts
    221 Leads
$ ./sfcsvparser_v2.py -f Task.csv -m Tasks -d |grep "Walk: WhatId" |awk '{ print $3 }' |sort |uniq -c
   2788 Accounts
     20 Opportunities
     78 props_Listings
      4 props_Properties
    974 props_Proposals
    173 props_Spaces

Also, how can I keep the drop down fro parent_type current with custom modules? Can I change the list used on the backend?

4

You could use a single “flex relate” field that can link both to Leads and Contacts. The current, existing field in Notes (that uses parent_id and parent_type) is likely a field of this kind, also.

I am not sure what the behaviour is for new modules, and custom modules, please try it to see for yourself (then tell me :wink: )

I don’t think Flex relate fields are meant to be handled directly by users. Normally their value would come from previous context - if you are creating the Note form a Lead record, it will get automatically related to this record, and the appropriate parent_type will be set.

1 Like
5

Also, about your data: do you have many “crosses” between the two kinds (what, who)?

I mean: many cases where both the what and the who are filled? Or maybe if one is filled, the other is blank? This would be a great help in simplifying your data before importing.

1 Like
6

Hi pgr,

Thanks for the reply. I might be misunderstanding dynamic dropdown, so please correct me if I am wrong, but my understanding is that DD is showing a second dropdown list relative to the first list (parent) selected. What I want is what SugarCRM calls a Flex Relate:

From what I can tell, parent_type is a Flex Relate field. You select a module name and the you can then search for fields in that module. It is not clear in my example above, but the WhoId and WhatId field values are SuiteCRM object IDs with the module name as key names. If there is a way to use DD with only a parent list that selects a flex field relative to the parent, that would be great.

I tried cloning the parent_relate field and that did not work, so I assume this is a designed limitation.

As for your second point, unfortunately there is overlap, most records have both a who and what, and this prevents me from merging.

7

I read in our documentation that “only one flex relate field is allowed per module”. But our documentation seems broken in that part, it’s mixing “flex relates” with “dynamic dropdowns”, I’ll have to fix that.

If you take a step back - maybe it’s better not to migrate all the data from SalesForce, or not migrate it in the same way. If you can simplify,

  • get rid of one of the entities, convert some leads to contacts (so you can just have a simple relationship to contacts), maybe its a better solution.

  • or even convert some of that information into non-editable fields, think of it as just “some text from the legacy system”.

  • or just make two separate straightforward relationships to both modules and fill that in

It will fit the SuiteCRM model better, and so might be a better option going forward. But only you can know if this makes any sense, it depends on the understanding of the data, which I don’t have.

Of course, this is open-source so everything is possible. If you really need “whats” and “whos” you can custom code it.

1 Like
8

Thanks

Since all of these are record IDs for different modules, it would be best if I could have two parent_type fields. I was interested in why the system only allows one per module since SF allows at least two.


...
Walk: WhoId: Contacts - 3f3660c9-a0ab-fcf2-0cd7-5d2e1375acc6
Walk: WhoId: Contacts - 3f3660c9-a0ab-fcf2-0cd7-5d2e1375acc6
Walk: WhoId: Contacts - 3f3660c9-a0ab-fcf2-0cd7-5d2e1375acc6
Walk: WhoId: Contacts - 3f149abc-552d-113b-e8f0-5d2e14a34974
Walk: WhoId: Contacts - 3e011c09-d987-aba5-eb27-5d2e139977e0
Walk: WhoId: Leads - 3e22ca3d-90da-d38d-4f44-5d2e39aeeeeb
Walk: WhoId: Contacts - 3f63baaf-cbd4-ae8a-6597-5d2e1451cb69
Walk: WhoId: Contacts - 3f63baaf-cbd4-ae8a-6597-5d2e1451cb69
Walk: WhoId: Contacts - 3f63baaf-cbd4-ae8a-6597-5d2e1451cb69
Walk: WhoId: Contacts - 3f63baaf-cbd4-ae8a-6597-5d2e1451cb69
Walk: WhoId: Contacts - 3f63baaf-cbd4-ae8a-6597-5d2e1451cb69
Walk: WhoId: Contacts - 3f63baaf-cbd4-ae8a-6597-5d2e1451cb69
Walk: WhoId: Contacts - 3f40fc80-9104-c2cf-d79e-5d2e14392a18
Walk: WhatId: props_Listings - 3f72ddc3-933a-ee8d-1bc5-5d3095edda66
Walk: WhatId: props_Listings - 3f72ddc3-933a-ee8d-1bc5-5d3095edda66
Walk: WhoId: Contacts - 3f50a6d3-710a-5507-2062-5d2e14f67268
Walk: WhoId: Contacts - 3f221d6b-b507-0c31-79db-5d2e137edd40
Walk: WhoId: Contacts - 3f221d6b-b507-0c31-79db-5d2e137edd40
Walk: WhoId: Contacts - 3f3b0a3f-f959-c2f5-1001-5d2e14e04ef0
Walk: WhoId: Contacts - 3f3b0a3f-f959-c2f5-1001-5d2e14e04ef0
...

I do not have time to modify the source at this time, but it seems like there is no blaring reason as to why I should not change the setting to allow two parent_type fields in a module. So for now, I am going to use the default parent_type for WhatID and create two relate fields for WhoId, one for contacts and one for leads.

If anyone has any additional thoughts or background about the parent_type field, that would be great if you can share.

9

My guess is that the limitation is with Studio, not with anything “deeper” than that.

Studio probably just creates two fields “parent_type” and “parent_id” for every Flex relate, and avoids any further complexity.

You can try changing the field’s names to something else (manually, in the vardefs) and you will probably have no problem having two Flex relates. But I am just speculating here, I never tried this.

1 Like