- Firstly, when you print the form, all the hidden fields will be printed out too. Now you can simply hide the print button too, but this can be overcome in the same way as the next bullet point.
The second option is to create a child entity that hangs off the entity that the sensitive fields live on and then to move these sensitive fields to this new entity. This will allow you to use the Crm out of the box security on this child entity. This will work fine, but it does mean that each record you create, you'll have to also create a child record, which can be a pain.
For this example, I will use the account entity, and assume a new bankaccount field is the sensitive field.
I create the bankaccount field on the account form and show and hide it based on whether the user is in the "Manager" security role (note that determining the security role of a user is covered by other blogs and out of scope for this entry, if anyone needs more information, email me).
Next I create a new entity called bankaccount, and create a 1:N relationship with account. This entity only has one field, "bankaccount". Assign security to this entity so that only users in the "Manager" security role can use it (read, write, create etc) and no one else can see it.
Now, onCreate of an entity, if the bankaccount field is filled in I create a bankaccount record that hangs off the account entity. Also in this plugin I clear the value of the bankaccount field on the account form, so it is essencially empty. Note that you may even put something like "bank account hidden" as the bankaccount in in the plugin.
So now when a user opens this new account and does not have rights to see the bankaccount details, the field is both hidden and empty, so even if they do try and unhide it, it won't show the correct value.
Finally, if a user has rights to see the bank acount, use a crm soap call (also covered on blogs elsewhere, and is similar to retrieving the user role, email me if you need more info) to retrieve the bankaccount from the child record and populate the field accordingly.
Now you could also create an onUpdate plugin to compare the account.bankaccount field with the bankaccount.bankaccount field and update the bankaccount.bankaccount accordingly.
This was rather hard to explain, so feel free to post questions and I'll answer them.