Getting access to ID (uuid) in Layouts for debug?

As we’re beginning to do more work on API integration, does anyone know if its possible to get the web ui Layouts / Detail View to be able to show the ID (aka uuid) of a given object?

Hi,
it should be possible to just add the ‘id’ field to the UI (either by modifying the according file or by copying the id to another field that is usable in the studio).

But I personally never use these options, I just copy the id from the URL:
…/index.php?module=Accounts&action=DetailView&record=1ace9cba-bdca-8a75-e507-5de683df7ae6

2 Likes

Thanks for the fast follow-up – yes I guess the URL is a good backup option !

We’re also considering using them on documents for verification purposes cross-system – like turning them into QR-CODES and using them as a kind of “signature” so that we can confirm that the subject is the same individual. (Think of the use case where you have dozens of people with names like “Bob Smith” in your system…

The ID / UUID does not appear to be available as a field eligible to select and place in any “Layout”

What would it cost to have this made available? If not for edit at least for viewing?

Create a custom field and a workflow. The workflow should copy the id (on save) in the custom field if is empty.
-> Your custom field will be available in the studio.

The option using the .php files is easy as well - I just can’t provide proper examples atm.

I never tried it, but I believe you can edit the viewdefs of some view and add the id field directly there. It’s probably just blocked in Studio.

just added

array (
          0 => 
          array (
            'name' => 'id',
            'label' => 'ID:',
          ),
        ),

to custom\modules\Accounts\metadata\detailviewdefs.php:

2 Likes

To have ID field in studio. Make ID field as studio enabled by extending vardefs
custom/Extension/modules/Accounts/Ext/Vardefs/sugarfield.id.php

$dictionary['Account']['fields']['id']['studio'] = true;
Do quick repair & rebuild. Now you will have ID field in the studio,

3 Likes

In any module/Ext/Vardefs directory I find a file named vardefs.ext.php and at the top is has a comment that says:

//WARNING: The contents of this file are auto-generated

And after i added it and did the quick repair it wiped out the change.

Testing other suggestion above in a view – but even here it would likely get overwritten by module builder no?

It looks like you went looking in

custom/modules/Accounts/Ext/Vardefs/

and you should have looked in

custom/Extension/modules/Accounts/Ext/Vardefs/sugarfield.id.php

as instructed above.

The first is the output directory of the QR & R, the second is the input, where you should put your customizations.

1 Like

Was able to follow the example of hacking the sub-panel.

Will try the /Extension route next

Cheers!

1 Like

Okay next sub-question?

How do we get Module Builder access to it? Every time I update the underlying data model it wipes out the changes in the Views. I even tried setting the “sugarfield.id.php” owner to root/root in each Vardefs directory and read only but it’s getting deleted every single time…

The QR&R has input files, and it has output files. What you’re describing is typical of when you’re editing the wrong set of files.

You need to understand better which are which. One way to figure this out is: get a distinctive bit of text from the files that are being overwritten (output) and run some sort of “find in files” to go discover which other input file it’s coming from. If you edit things there, they should be stable.

For example, to find the string “findThis” in anything under custom dir (recursively), use

grep -irn findThis custom

$dictionary['Account']['fields']['id']['studio'] = true;

^^ that’s what I’ve been setting manually in the suggested sugarfield.id.php file

I’d just like to have the uuid available all the time for all the Modules in Module Builder.

It’s incredibly valuable (to me) in doing ETL operations among different systems. Basically I’m trying to migrate content out of a CMS and make SuiteCRM the backing System of Authoritative Record – and I need to flow the UUID from the CMS into SuiteCRM which I can do, but just want to be able to display it :slight_smile:

Exactly in which directory is this sugarfield.id.php?

If it’s an output file (gets overwritten) have you found the corresponding input file for it?

Based on your guidance above:

So I have been creating them manually in that directory – and Studio doesn’t overwrite them, Module Builder does.

It would be awesome if there was a global switch to make ID always available everywhere or just make it part of core and people can get access to it or not…

Ok, I get it now.

Just call your file something different. The extension mechanism doesn’t care about the name of input files, I think. It will just concatenate your file with Module Builder’s file and both will be compiled into the output file.

1 Like

Just to add a bit of wisdom: in case you have a conflict because both you and Module builder and trying to set a value for the same property, you can use the override scheme to make sure you get priority:

–> https://docs.suitecrm.com/developer/extension-framework/#_forcing_overrides

1 Like

I guess the overall issue I’m having is that Module Builder doesn’t recognize the ID field in a layout, but Studio does. And if I make a change to the underlying Module Fields and hit “Deploy” it’s irritating that it appears to wipe out the Vardefs directory entirely and recreate it, taking whatever file I deployed there along with it.

Again what is the rational for NOT making ID available universally in any Layout for any Module? Why hide it from users when it clearly has value to API writers :wink:

Hello,
I believe once you deployed the module, You should not deploy it again from module builder, Else it will wipe out all your changes and deploy again new files only.
So In ideal case, Once you deploy the module you should use Studio, Instead of Module builder.

For ID field. You should write changes of vardefs at Extension directory only so it will not overwritten by Quick reapir & rebuild.