How to add fields to the main table instead of cstm table

Question

Maybe You Shouldn't

This is against standard best practices. The general reason is that if SugarCRM comes out with an update that happens to include a new field for this module, it'll overwrite what you already have and cause issues and/or data loss. It'll also be more difficult to tell that that this field is a custom one, which may make future customization from different developers/teams more difficult.

But You Can

The acceptable "but" in this situation is that you can't keep the database's fields_meta_data table under version control. Not with GIT, not with SVN - you just can't. So, if you're working in a multi-developer or multi-system environment where you do pushes using VCS, it's actually preferable to hand-code your vardefs and it can be done in a relatively upgrade-safe way. Here's how:

Add the portion of your vardef that Studio won't allow you to adjust into your first vardef file, e.g. /custom/Extension/modules/MyModule/Ext/Vardefs/myfield.php. For probably every field/data type, those vardefs are name, vname and type.

<?php
$dictionary['MyModule']['fields']['myfield']['name']='myfield';
$dictionary['MyModule']['fields']['myfield']['vname']='LBL_MYFIELD';
$dictionary['MyModule']['fields']['myfield']['type']='varchar';

Once that's created you can run a repair-and-rebuild (which will also help set up your database, something like alter table mymodule add myfield varchar(255)) and then go find the field in Studio. Adjust the length or audit values if desired, and re-save the field. Studio will create a new file, prefixed with "sugarfield_," e.g. /custom/Extension/modules/MyModule/Ext/Vardefs/sugarfield_myfield.php The contents of this file will vary more by datatype than our first file, but will include something like the following:

<?php
$dictionary['MyModule']['fields']['myfield']['audited'] = false,
$dictionary['MyModule']['fields']['myfield']['massupdate'] = true,
$dictionary['MyModule']['fields']['myfield']['duplicate_merge'] = 'enabled',
$dictionary['MyModule']['fields']['myfield']['duplicate_merge_dom_value'] = '1',
$dictionary['MyModule']['fields']['myfield']['merge_filter'] = 'disabled',
$dictionary['MyModule']['fields']['myfield']['calculated'] = false,

You should also create a language file at /custom/Extension/modules/MyModule/Ext/Language/en_us.myfield.php. Example contents for the language file:

<?php
$mod_strings['LBL_MYFIELD'] = 'My Awesome Field';

Extra Safety

So if the down-side of hand-coding all of your custom fields is that they could be easily overridden but an update (e.g. you created a field called "Marketo ID" and then Sugar provides one), how can we reduce the risk of that? The same way we reduce the risk when creating custom modules - just prefix everything with some standard abbreviation for your system or company. At my current employer, we all use tcx_ for Ticomix. In the past, we used psi_ for Profiling Solutions. If instead of calling your field myfield you were to call it tcx_myfield you've greatly reduced the risk of someone else creating a field of the same name. It's not impossible, but you're probably pretty safe.

Note that you do not need to add this prefix to the labels. LBL_TCX_MYFIELD can translate directly to "My Field" and you can very easily adjust the label in the future if needed.