Conditionally setting a field to readonly staus if not admin

I was happy to see that two-factor authentication has been added to v7.10 - thank you.

There is an issue in that the user can turn off two-factor authentication in their Profile settings. I could prevent access to the entire User module but I want the users to update their particulars - just not disable two-factor authentication.

So I set out to disable the two-factor authentication checkbox when a (regular) user viewed their Profile in Edit mode but allowed Administrators to still be able to edit the setting.

I do not want to hide the two-factor authentication field; I just do not want users being able to disable it.

I turns out the fix was relatively straight-forward functionally (i have it working - see below) but I don’t have the aesthetics I want so was hoping someone could help me with that.

To disable the user’s ability to change the two-factor authentication:

  1. If the file (or directory path to) /var/www/html/mgmt2gocrm/custom/modules/Users/metadata/editviewdefs.php does not exist,
cp -a /var/www/html/mgmt2gocrm/modules/Users/metadata/editviewdefs.php
chown www-data:www-data /var/www/html/mgmt2gocrm/custom/modules/Users/metadata/editviewdefs.php  
chmod 755 /var/www/html/mgmt2gocrm/custom/modules/Users/metadata/editviewdefs.php 
  1. edit the custom file to create a conditional readonly state for the checkbox
nano /var/www/html/mgmt2gocrm/custom/modules/Users/metadata/editviewdefs.php

Change the line

array(array('name' => 'factor_auth', 'label' => 'LBL_FACTOR_AUTH'),)

to be a multi-line entry with (you don’t need to make it multi-line but it is easier to maintain this way)

	'name' => 'factor_auth', 
	'label' => 'LBL_FACTOR_AUTH', 
	'customCode'=>'{if $IS_ADMIN}@@FIELD@@{else}{$fields.factor_auth.value}{/if}',
  1. Quick Repair and Rebuild

Like I said, this gives me the functionality I want - Users cannot change the setting for two-factor authentication but Admins can - but what the User sees when they go to the Profile Editing page is a 1 or a 0 instead of a checked or not checked checkbox.

Can someone show me how to edit the code so the checkbox still shows reflecting the actual status set for the user - but is still not editable - for users?

I am not sre, and I can’t try right now, but it’s probably easier to make the changes here:




Find out where the field is in one of those two files. Copy logic from other places in those files that checks if the user is an admin (probably $IS_ADMIN).

If he is, add an HTML attribute to the checkbox to make it read-only.

Thank you for the quick reply

I looked in
and even in

but found no reference to factor_auth in any of the files.

There were examples of using $IS_ADMIN so you may be pointing me in the right direction but …

I am not familiar enough with the syntax to try and create a factor-auth entry on my own.

If you do have a chance to take a look and do have suggestions for what code to add, I’d be willing to give it a try.

Thanks again.

Ok, having a closer look, it is defined here


It’s called factor_auth.

There are a bunch of fields there with customCode logic that seems to be what you need, try to copy it…

If you get it working, please share here how you did it. Thanks.

Yes, that is what I have been working with, but I did not want to edit the core code (it could be replaced in an upgrade) so I copied that file to


and did the edits shown above.

It does work, but it does not show a checkbox, it only shows a 1 or 0, representing Checked or notChecked

So what I am looking for help on is how to get the user’s edit view to show the checkbox but disable it so it cannot be edited, while allowing the Admin to edit it (that part I have done above)


I got it working but I am not sure if this is the most efficient way to do it so if anyone has any suggestions for improvement, feel free to advise.

I was most of the way there with what I had but just needed to change the formatting for the user scenario in the code so it would show the user’s checkbox status - disabled, but viewable as a checkbox .

Here is what I did - editing the custom directory instead of the core files to protect against regression during an upgrade

  1. as before if there is no directory or no editviewdefs.php entry in the custom directory for the Users module, create one
cd [the directory containing the suitecrm files]
mkdir -p custom/modules/Users/metadata/
cp -a modules/Users/metadata/editviewdefs.php custom//modules/Users/metadata/editviewdefs.php
chown www-data:www-data custom/modules/Users/metadata/editviewdefs.php  
chmod 755 custom/modules/Users/metadata/editviewdefs.php
  1. edit the editviewdefs.php file in the custom directory
nano custom/modules/Users/metadata/editviewdefs.php
  1. Replace the line
array(array('name' => 'factor_auth', 'label' => 'LBL_FACTOR_AUTH'),)

with a multi-line version (does not have to be multi-line but is easier to maintain if it is)

	 'name' => 'factor_auth', 
	 'label' => 'LBL_FACTOR_AUTH', 
	 'customCode'=>'{if $IS_ADMIN}@@FIELD@@{else}<div  style=\'visibility:visible\' disabled="true" id="factor_auth" ><input {if $fields.factor_auth.value == "1"} checked {/if} tabindex="0" enabled="false" id="factor_auth"  type="checkbox" class="checkbox" value="$fields.factor_auth.value" disabled="true"></div>{/if}',

(yes, a little more complicated than before …)

  1. Repair and Rebuild

Now, when the admin sets a User to use two-factor authentication, the user can see that they have it set but cannot edit the setting.

1 Like

I got it working - see previous post.

I am not sure if this is the best way to do it so if you have any suggestions for improvement, feel free to suggest.

For me, this will be the default setup for any SuiteCRM installation where I want to use two-factor authentication: Administrators being the only ones who can enable/disable two-factor authorization for users…

And if I do not want to use it, I probably still want this as the default.

I cannot imagine a scenario where an admin would set up a user for two-factor authentication and allow the user to disable it. Most (poorly informed and wanting the easiest login possible) users would likely disable it as soon as they realized they could. And that would leave the entire system exposed more than intended by the admin.

I do set the system up with strong password requirements (min length, upper case, lower case, numbers, special characters) but two-factor is still a very welcome addition to SuiteCRM; why neuter it by allowing users to disable it?

1 Like