A few months back I shared a simple example that demonstrated said simplicity quite well through a customization of the search popup windows. Let us take a look at another equally simple and useful modification.
This time around we are going to look at something just as easy, but serving a completely different purpose.
In this scenario we will assume that we have a need to create a read-only field, one that cannot be edited via the SugarCRM interface. This is helpful for scenarios where records may contain important data that should not be changed by any user. A good example of this is financial data from external systems, such as your ERP solution.
Because this data is coming from another system, it is usually input into SugarCRM by means of a link or other programmatic approach that eliminates the need for the user to actually enter the data by editing the record.
Allowing users to manipulate the values would create the potential for faulty analysis. For example, if one of the values relates to a customer's outstanding balance, a user could accidentally (or purposely) increase or decrease it, in turn misleading the next person that views said record. Hence the value of using a read-only field.
Converting a field into a read-only field is quite simple. Read on to see the step-by-step instructions.
To begin with, let us select a field. For our example we will pretend we have created and will be using a custom field named "member_status_c" which already exists on the Edit and Detail view screens. It holds one of two values: current and expired and is part of the Contacts module.
Converting it into a read-only field is quite simple.
First, create a new PHP file and name it vardefs.ext.php and add the following code to it:
<?php
$dictionary['contact']['fields']['member_status_c']['type'] = 'readonly';
?>
Save the file and place a copy of it in the following folder:
<sugar root>/custom/Extension/modules/Contacts/Ext/Vardefs
Lastly, you need to instruct SugarCRM to apply the settings by means of a repair operation. To complete the process:
- Login as an Admin level user
- Click Admin > Repair > Quick Repair and Rebuild
- Select Contacts in the Modules list and click Repair
Congrats! Simple, no?
For those of you that may have attempted to use this and experienced problems,I recently realized that the text value of 'readonly' must be in lower case or this customization will not work on case-sensitive operating systems like Linux.
ReplyDeleteApologies for the oversight and any frustration it may have caused you.
I've corrected the article accordingly.
can't we do this thing just for role's so that other can view that details.& imp. thing is this all can be done simply by using studio.
ReplyDeleteYes, you can do it via roles but only if you have a commercial version of Sugar. Said functionality doesn't exist in Community Edition. Thanks for bringing up that point as it is worth noting.
ReplyDeleteAngel,
ReplyDeleteI have a custom/Extension/application dir but no /custom/Extension/modules. I created the modules (all the way down to Vardefs) and created vardefs.ext.php, but nothing happened. I am using 6.4.2.
You don't say whether or not you performed a repair, as described in the post. Did you?
DeleteI am unable to get this to work. I am trying to make the Lead Source and a custom field that I created read only. Both are in the Leads Module. I have created the php file as above and have placed it in the directory as above. I have done the quick repair and rebuild although it just repairs and I am not given the opportunity to check the Leads field. Also I have tried 'Leads', 'leads', 'Lead' and 'lead' for the module. What am I missing? Thanks for any help you can give me.
ReplyDeletePerhaps you have a spelling or casing error. I used this for my vardefs.ext.php and it worked:
Delete$dictionary['Lead']['fields']['lead_source']['type'] = 'readonly';
Note that I did get an error during the rebuild which I didn't get a chance to investigate, but it does ultimately convert lead_source to read only.
I have an already existing custom field in oppportunities, called "proforma_emitida_c". At custom/Extension/modules/Opportunities/Ext/Vardefs, there is an already existent emty file called "sugarfield_proforma_emitida_c.php". I added to it: $dictionary['opportunities']['fields']['proforma_emitida_c']['type'] = 'readonly'; made a quick repair and rebuild (I can't choose the module because it's CE) and nothing happens.
ReplyDeleteAnyway, what I am looking for is a way of making the field conditionally not editable. So the final need would be something like: if ($bean->proforma_emitida_c) $dictionary['opportunities']['fields']['proforma_emitida_c']['type'] = 'readonly';
Could something like this be made thru logic_hooks ?
It should be $dictionary['Opportunity']['fields']['proforma_emitida_c']['type'] = 'readonly';
DeleteYou can't do that via a logic hook as they are more for interaction with data versus the UI. Depending on the desired workflow, you might be able to do it via a custom Edit view.
Hello,
ReplyDeleteI'm working on SugarCRM 7.2 and I'm trying to make the account_code_c read-only for in-line edit. I tried the solution provided above but it didn't work. I Also tried ['readonly] = true instead of ['type'] = 'readonly', but the in-line editing was no longer possible. Could someone help me with this? Thanks.
The example is applicable to pre-7.x releases only. For 7.x, there is a different technique you can use.
DeleteSimply add the attribute 'readonly' => true to the field you wish to make read-only, within the metadata file that corresponds with the view you wish to effect. For example, record.php for the RecordView or list.php for the ListView.
This comment has been removed by the author.
ReplyDeleteWhen you insert a file inside Extension framework, actually the file name doesn't matter, since is it compiled in another file when you use QR&R.
ReplyDeleteAlso, found that if you define the 'type' =>'readonly' of field inside the metadata/editviewdefs.php, it has the same effect. In this case, the same should be performed in metadata/quickcreatedefs.php in order to have the field readonly in both views. Sometimes this is useful.
Good points.
Delete