locked
Dynamics CRM 2011 - Making Case Description Field Read-Only After Initial Creation of New Case RRS feed

  • Question

  • Our business has a need to make the Description field on the Case entity be systematically locked down to prevent edits after the initial creation and saving of a new case. The field needs to be editable during intial case creation (in order to manually populate this field on create) on the case form but not editable after that initial save.
    How can this be best accomplished? Will a web resource containing javascript - that would theoretically make the case description field read-only upon the OnSave event of a new case - be the best solution? Any thoughts, input, and suggestions would be appreciated.
    Tuesday, July 5, 2011 6:02 PM

Answers

  • Hi,

    Making a field read via JScript on a form is not the proper solution (even user with very low technical skills can press F12 form keyboard to bring developer tools and change the ReadOnly field property easily), user can even use cretae workflows to update the field data (or programmatically the loop hole will be always open). The complete solution is to restrict the access via Field Level Security and it gives more flexible way to maintain access rather then making it readonly via JScript checks.

    Ideally what should you do is to create new Description Field and remove the system Description field from the form and if any system report use the system description field then simple cretae a new workflow on Create and Update (with option checked: Automatically Deleted Completed Jobs) to set the system field from a custom field (so both fields will have description)

    I hope this anwers your question.


    Jehanzeb Javeed

    http://worldofdynamics.blogspot.com
    Linked-In Profile |CodePlex Profile

    If you find this post helpful then please "Vote as Helpful" and "Mark As Answer".
    • Proposed as answer by Jehanzeb.Javeed Friday, July 8, 2011 4:42 PM
    • Marked as answer by kspicer Friday, July 8, 2011 4:46 PM
    Friday, July 8, 2011 4:42 PM

All replies

  • Hi

    Yes, your best bet would be to use a JS on the onsave event of the form to make the field read only. So after the first save the field becomes read-only, and every subsequent save the field remains readonly. Make sure the field is editable when designing the form, so it is editable on form load.

    the otehr option would be to check the field on the Form Load and if it is filled in, make the field Read Only. this will ensure that the field can be filled in, even if the case was accidently saved, without filling in the field.

    Workflows will not work, plugins will but would be an overkill.

    Thanks and Regards

    AniMandal

    http://xrmadventures.wordpress.com/

     

     

    • Proposed as answer by AniMandal Wednesday, July 6, 2011 7:07 PM
    • Marked as answer by kspicer Thursday, July 7, 2011 12:51 PM
    • Unmarked as answer by kspicer Thursday, July 7, 2011 5:31 PM
    Wednesday, July 6, 2011 7:07 PM
  • Hi AniMadal,

    Thanks again for your helpful reply; that makes perfect sense and we will move forward with pursuing that option. One additional question I have is, what about the possibility of using the field security profile? I realize that field level security is not possible for managed (system) fields and as such we would have to create a custom description field to use field level security.  Field level security can be more flexible and allow different security roles to have different properties for the field in question and it applies to every place the field exists, but it requires adding a custom field and hiding a system field. JS is a quick workaround, but it potentially only applies to one form or area of the system and could limit the ease of maintenance and could also slightly affect performance.

    What is yours or Microsoft's opinion on the best solution out of these 2 options? Use a web resource with JS to customize the system or add a custom field and use the out-of-the-box field level security (field security profiles)?

    Thursday, July 7, 2011 5:19 PM
  • Hi,

    Making a field read via JScript on a form is not the proper solution (even user with very low technical skills can press F12 form keyboard to bring developer tools and change the ReadOnly field property easily), user can even use cretae workflows to update the field data (or programmatically the loop hole will be always open). The complete solution is to restrict the access via Field Level Security and it gives more flexible way to maintain access rather then making it readonly via JScript checks.

    Ideally what should you do is to create new Description Field and remove the system Description field from the form and if any system report use the system description field then simple cretae a new workflow on Create and Update (with option checked: Automatically Deleted Completed Jobs) to set the system field from a custom field (so both fields will have description)

    I hope this anwers your question.


    Jehanzeb Javeed

    http://worldofdynamics.blogspot.com
    Linked-In Profile |CodePlex Profile

    If you find this post helpful then please "Vote as Helpful" and "Mark As Answer".
    • Proposed as answer by Jehanzeb.Javeed Friday, July 8, 2011 4:42 PM
    • Marked as answer by kspicer Friday, July 8, 2011 4:46 PM
    Friday, July 8, 2011 4:42 PM
  • Thank you Jehanzeb for your response. We appreciate your input and have a better sense of where to go from here.

    One final question / suggestion is this: Is there a reason that managed system fields (such as description) cannot have field level security? I would suggest that Microsoft look into enabling the option for field level security on all fields if possible as a potential change request or system update.

    Tuesday, July 12, 2011 6:21 PM