How do we make default fields required in CE 5.0a?

[jspencer]

How do we make default fields required in Sugar CE 5.0a? I could do it fairly easily in 4.5.1 by editing a few key php files in the module folder, but now that everything is rearranged in 5.0 I can't figure it out (I'd rather spend my time customizing the system...)

Can someone on the Sugar staff at least point us to the files needed to edit since you haven't replied my request to make it possible using studio?

[jspencer]

Oops, just looking through my subscriptions and guess I already posted this question last year (seems so long ago ). Nobody replied so I forgot I already asked and since this should be pretty important to everyone guess it doesn't hurt to double post...

[cjohnston]

How do we make default fields required in Sugar CE 5.0a? I could do it fairly easily in 4.5.1 by editing a few key php files in the module folder, but now that everything is rearranged in 5.0 I can't figure it out (I'd rather spend my time customizing the system...)

Can someone on the Sugar staff at least point us to the files needed to edit since you haven't replied my request to make it possible using studio?

1st of all to not modify the core code which may be overwritten with an update I suggest putting module modification into m{root}/custom/modules/{module_name}

Depending on the module you would add the following array value as seen underlined to the vardefs.php file and place it in the custom modules directory

 'lead_source' =>
  array (
    'name' => 'lead_source',
    'vname' => 'LBL_LEAD_SOURCE',
    'type' => 'enum',
    'options'=> 'lead_source_dom',
    'len' => '100',
	'audited'=>true,
	'comment' => 'Lead source (ex: Web, print)',
	'required' => 'true',
    'merge_filter' => 'enabled',
  ),

You would then change the database to not allow null values because otherwise you'll get an error when you rebuild or repair your Sugar installation.

There are other modules such as the Accounts module which has an array at the bottom in the file field_arrays.php
'required_fields' => array('name'=>1,'account_type'=>1),

although this change did not make the field required and I am not sure why. It seems not all modules are "built the same"

[jspencer]

I'm giving it a try, but there was no existing custom/modules/accounts/vardefs.php file. Your instructions were for 5.0, correct?

Assuming so, I did try to copy the existing account vardefs.php file from the regular module folder and replaced everything after the beginning comment paragraphs and before the last >? with a modified version of your suggestion. It doesn't seem to have worked.

Should your code be the only thing in the vardef file? Or will this method not work for accounts?

Is there something else I need to do, your instructions were a good start but left a few things a little vague (but thanks for trying, I really appreciate the pointers!)

One more question, will just changing the vardef or field_array files also add the * to the editview for the module? In the old 4.5.x hacks you had to edit the editview.php file (which doesn't exist in 5.x) to include that marker...

I had also already found and tried editing the field_arrays.php but got the same thing as you, it didn't make a difference...

[cjohnston]

Yes this applies to version 5 and is found to work int the Leads module
I misspoke with the directory which you place the custom pile in as seen in these instructions

https://www.sugarcrm.com/wiki/index....Customizations

To not modify the core code and ensure your changes are not overritten by an update
1) Create the directory {sugarCRMroot}/custom/modules/{module_name}/Ext/Vardefs replacing the module_name with the exact module for which you want to require a field
2) Copy the vardefs.php file from the {root}/module/{module_name} directory for which you are going to change into the newly created custom module directory in step 1 and change the file name to vardefs.ext.php

3) add the array item 'required=>true to the field you want required

4) rebuild the vardefs cache using 'repair' in the admin interface

If this is successful then you will see the red astrisk next to the required field

[cjohnston]

4) rebuild the vardefs cache using 'repair' in the admin interface

Interesting part about this is that you actually need to lock out the apache user from modifying the directory because it will inherently overwrite the contents when running the rebuild vardefs cache by deleting the newly created file vardefs.ext.php

[jspencer]

Ok, finally got time to try this out. I need to make additional default fields required in several of the included modules, so for this example I edited the Accounts module to make account_type required. Here's what I've observed.

1) I edited /modules/Accounts/field_arrays.php and changed the bottom required_fields array to:

'required_fields' => array('name'=>1, 'account_type'=>2, 'industry'=>3),

Doing only this step didn't change a thing (even after rebuilding the vardefs cache) so I removed the change.

2) I edited /modules/Accounts/vardefs.php and added the following after the closing ), of parent_id

'account_type' => array (
'name' => 'account_type',
'vname' => 'LBL_TYPE',
'type' => 'enum',
'options' => 'account_type_dom',
'len' => '25'
'required' => true,
'audited' => true,
'comment' => 'The Company is of this type',),

After saving the file I tried to create a new account and the * was there in editview and it wouldn't let me save without selecting an item from the dropdown (the first item was blank).

3) I ran Clear Vardefs Data Cache in the admin/repair. This automatically noticed that my database needed to be updated and did it for me (it set account_type to 'not null').

NOTES:
I decided to edit the original vardefs.php file instead of messing with the vardefs.ext.php for the following reasons:

* In step two the field definition for the 'account_type' was NOT in the vardefs.php file even though it was a "factory default" field. I figured out how to duplicate it and added my 'custom' version to the file and everything still works, but does anyone know where it was originally defined and why it wasn't in the factory vardefs.php file?
* As you observed the ext file isn't really "upgrade safe" unless you lock it down using file permissions.
* Won't using permissions to lock the file break future studio edits??
* Won't locking the file cause rebuilding the vardef using the admin repair process to fail??
* If a future upgrade includes a new vardef.php file, does the update automatically try to rebuild the custom vardefs which will erase your changes (or if you lock the file won't the update fail)??

OK sugar team, care to comment on my possibly faulty observations?