Skip to main content

Show\Hide columns in the SharePoint default list forms

Here are two cases that I face in the daily work with SharePoint which I find very common and would like to provide some technical details.

1. Hide Yes\No column
If you want ho hide an Yes\No column inside content type, surprisingly you find that you can't.

Or to be more specific, the SharePoint interface won't allow you to do it.
I'm not sure why is that limitation but тхис is technically supported by SharePoint.
Here is a JavaScript that modifies the column visibility. You just need to run it with user who have appropriate rights.

var context = SP.ClientContext.get_current();
var siteContentTypes = context.get_web().get_contentTypes();
// add the GUID of you ContentType
var myContentType = siteContentTypes.getById("0x010100185E5E735545B942852F513AEB77B51C");

var fieldLinks = myContentType.get_fieldLinks();
context.load(myContentType);
context.load(fieldLinks);

context.executeQueryAsync(
    function (sender, args) {

        var listEnumerator = fieldLinks.getEnumerator();
        while (listEnumerator.moveNext()) {

            var field = listEnumerator.get_current();
            //Add here the internal name of your column
            if (field.get_name() == "DTSIsApproved") {
                field.set_hidden(true);
                //field.set_required(false); // OR make the column reuqired 
                myContentType.update(true);
                context.load(field)
                context.load(myContentType);
                break;
            }
        }
        context.executeQueryAsync(
              function (sender, args) {
                  console.log("Column is updated!")
              },
             function (sender, args) {
                 console.log("Error:")
                 console.log(args)
             });
    },
     function (sender, args) {
         console.log("Erro:")
         console.log(args)
     });


2. Show one column in the Display Form, but hide it in the Edit Form
One well described method in the blog posts is to use JavaScript or css to hide the column in the Edit\New form. This approach works but has a huge disadvantage.
In case you have Document library and the users open the file with the Office client (Word, Excel, ...) the column will be visible!

The correct way to hide column in New or Edit form is to use the column's settings ShowInEditForm, ShowInDisplayForm.
Here is a JavaScript that modifies these settings:

var context = SP.ClientContext.get_current();
var list = context.get_web().getList("/sites/demos/Docs");
var fileds = list.get_fields();
var myColumn = fileds.getByInternalNameOrTitle("DTSIsApproved");
context.load(list);
context.load(fileds);
context.load(myColumn);
context.executeQueryAsync(
    function (sender, args) {
        if (myColumn) {
            myColumn.setShowInDisplayForm(true);
            myColumn.setShowInEditForm(false);
            myColumn.setShowInNewForm(false);
            context.executeQueryAsync(
                  function (sender, args) {
                      console.log("Column is updated!");
                  },
                 function (sender, args) {
                     console.log("Erro:")
                     console.log(args)
                 });
        }
        else {
            console.log("column is null:")
        }
    },
     function (sender, args) {
         console.log("Error:")
         console.log(args)
     });



PS: Your feedback is highly appreciated.

Comments

Popular posts from this blog

ClientPeoplePicker in SharePoint 2013

Start using SharePoint 2013 I noticed that the way for selecting people or groups is changed. The new way is simple – just ‘Enter name or email address’ without any icons for ‘Check Names’ or ‘Browse’. I guess that the PeoplePicker is changed but NO. PeoplePicker sitll has the same functionality as before. There is a new control called ClientPeoplePicker . How to use it: 1. Add this references <% @ Register TagPrefix ="wssawc" Namespace ="Microsoft.SharePoint.WebControls" Assembly ="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> 2. Add the following control declaration       < wssawc : ClientPeoplePicker          Required ="true"          ValidationEnabled ="true"          ID ="peoplePicker"          runat ="server"          InitialHelpText =" <% $Resources:wss,aclinv_PickerIntialHelperText %> "          VisibleSu

Error: A duplicate field name "xxxx" was found

Soon I have some experience with migrating solution from SharePoint 2010 to SharePoint 2013. The migration was on 3 steps. First one was just to copy the custom fields, content types and list definitions from the old VS 2010 project into a new VS 2012 project for SharePoint 2013. Looks like pretty simple task but ….. The problem:  Error “ A duplicate field name "xxxx" was found ” when the feature for provisioning the fields and content types is activated. The solution: Review the field definitions and make sure no field has Name property equal to some of the ‘reserved’ values. Explanations: In SharePoint 2010 there was no problem to have these fields as a definition of custom fields: < Field     Type = " Note "     ID = " {893FB9BC-2DA4-4451-A1D1-88010CDC6A08} "     Name = " Description "     StaticName = " Description "     DisplayName = " Description 1 "     Required = " FALSE "     MaxL

Using SharePoint Attachments' controls with elevated security

The scenario:  Create custom forms for Add/Edit/Delete items to a list which is not accessible by the regular users. The forms should support working with attachments. The problem: The default SharePoint controls don’t work if the current user doesn’t have access to the list items. The solution: Use custom code for generating the SharePoint default HTML so the out-of-the-box javascript works correct. Explanations:  The scenario occurs when some list need to be hidden form the users. The list has broken security inheritance and users can't navigate directly to it. Working with its fields requires crating web warts or application pages with appropriate controls on them and server-side code running under elevated privileges. The issue here is that the OOTB (out-of-the-box) controls for Attachments don't work if the user doesn’t have access to the related list item. The OOTB controls are: AttachmentsField , AttachmentUpload , AttachmentButton . There is a lot of code