how can I safely remove fields I don’t need from the code? (or comment out)
For example, these address fields in contacts
I have many more custom modules that I created, but when creating, I chose the wrong template and as a result, I got a lot of unnecessary fields in the module.
They really get in my way when working with MySQL
If I go to /module/contacts/contacts.php
and delete or comment those lines:
public $primary_address_street;
public $primary_address_city;
public $primary_address_state;
public $primary_address_postalcode;
public $primary_address_country;
public $alt_address_street;
public $alt_address_city;
public $alt_address_state;
public $alt_address_postalcode;
public $alt_address_country;
can i get rid of these fields?
I would like to ask for any tips or guides how can I clear the system of standard fields that I do not use?
Of course, I know that there are many fields that the system needs, but if I created my custom module and made a mistake in choosing a template, then I received many unnecessary fields, for example, fields with information about the company, although my module is not for the company.
I am actively using these modules now and I can not recreate them. I would like to just delete a few unnecessary fields from MySQL first of all, but I understand that I must first do this in the system or they return after quick repair and rebuild.
I strongly advise against this approach for the core modules.
The changes need to be done in the vardefs, and then let the QR&R (also running the queries generated at the end) fix the database.
For your custom modules, I guess you can do this.
For the core modules, you should just remove them from the views. Don’t worry about the database and phpMyAdmin, when you finish the imports and the initial work, you won’t be spending that much time in there (hopefully).
What will happen if you remove core fields is that you will find out (much later, in some cases), that you broke functionality in other unexpected places in the program. It will make your system unstable in unpredictable ways - not good.
@pgr thank for reply
I think I will only clear my custom modules. Could you tell me the exact path where I can delete or comment out unnecessary fields? The put above is it?
because in the vardefs.php I did not find anything
I have a module that class extends Person when creating, I indicated it by mistake now I understand that I do not need its additional fields and class extends Basic would suit me. so I’m trying to remove fields with an address, for example, are not needed here.
But this does not work, these fields are still in the database and in the studio.
However, if I change class extends to Basic it works well for me.
I would like to know if you have any other way to remove these fields? and is it safe to just change the class here?
require_once('include/SugarObjects/templates/company/Company.php');
class wrk_Work_Experience extends Company //Here I can change to Basic
{
public $new_schema = true;
public $module_dir = 'wrk_Work_Experience';
public $object_name = 'wrk_Work_Experience';
public $table_name = 'wrk_work_experience';
public $importable = true;
public $id;
public $name;
public $date_entered;
public $date_modified;
public $modified_user_id;
public $modified_by_name;
public $created_by;
public $created_by_name;
public $description;
public $deleted;
public $created_by_link;
public $modified_user_link;
public $assigned_user_id;
public $assigned_user_name;
public $assigned_user_link;
public $SecurityGroups;
public $wrk_work_experience_type;
public $industry;
public $annual_revenue;
public $phone_fax;
/* public $billing_address_street;
public $billing_address_street_2;
public $billing_address_street_3;
public $billing_address_street_4;
public $billing_address_city;
public $billing_address_state;
public $billing_address_postalcode;
public $billing_address_country; /* I delete these
btw I could not find there these fields:
public $primary_address_street;
public $primary_address_city;
public $primary_address_state;
public $primary_address_postalcode;
public $primary_address_country;
public $alt_address_street;
public $alt_address_city;
public $alt_address_state;
public $alt_address_postalcode;
public $alt_address_country;
The main goal, why I need to delete or hide this field, is my desire to find in the future a tool for direct editing of the database (something better than phpmyadmin) and unused fields will interfere with this
Of course, I understand that these are system files, but I only use accounts and contacts modules in suitecrm, the rest of the modules are my custom ones.
anyway, I could return the deleted fields at any time
My guess is that there is a filed type address that handles all those different address parts. But I don’t know, I didn’t go and check,
It seems to me that you are working against the architecture. Do you really think it’s a good idea to tweak classes and then go for direct database access? Why? This might complicate your life at some point in the future…
The main reason for this is the need to import big data, import via the interface becomes impossible if the data is more than 30-50k. it’s incredibly long. For example, I can easily import 1-2 millions record via Mysql with csv using load data…
Note that importing from the user interface is not the only alternative to using the database directly.
Consider this approach, an import script:
This approach really helps with the interconnected nature of CRM data. You need not just to add records, but to set relationships and security records.
Sure I researched about suitecrm records data structure.
I usually prepare the data import according to the structure of suitecrm. split into two tables (_cstm), fill id,user_id and so on. It works really well for me
Making large import like this guide works very well for me
btw about your import script. Can i use it for import about 200-400k records? maybe 1-2M?
And will it works only for Contacts?
My script is very specific and it can’t be used unless you adapt it to your needs. You can use similar logic to load any kinds of Beans.
About the really big imports: the script loads everything into an array in memory before doing its work. That is a shortcut, and is not adequate for huge amounts of data. But it shouldn’t be too hard to change that to make it load in chunks.
Working from Beans is extremely less performant than using direct loads in the database. But sometimes performance is not the most critical factor, and that kind of script can work really well to let you sensibly use conditions and arrange the data inside the CRM at the same time you’re importing it.
That was my use case - not that many rows (~3k), but each row needed to be handled with conditions and turned into 3 or 4 different beans in the CRM.
