3

We have a list with some fields hidden for normal users, but approvers have edit access to these fields. The list has been working fine with the new,edit, and view forms all working as expected for over a year. BTW, this is on a Sharepoint Online site.

Somehow, over this last weekend, although no changes were made to any of the forms, the New item form no longer works, but rather comes up with an "unable to display this web part" error. Interestingly, the edit and view forms still work with this functionality.

So, in doing some troubleshooting, I created a new item form for the list and confirmed that the new default form works fine. I then added in just the code for hiding a field and immediately the form came up with the "unable to display this web part" error.

Is this functionality no longer supported?

btw, here's the code I tested in the new form:

<xsl:if test="ddwrt:IfHasRights(16)"><tr>

<td width="190px" valign="top" class="ms-formlabel"><H3 class="ms-standardheader"><nobr>Entry Status</nobr></H3></td>

<td width="400px" valign="top" class="ms-formbody"><SharePoint:FormField runat="server" id="ff8{$Pos}" ControlMode="New" FieldName="Entry_x0020_Status" __designer:bind="{ddwrt:DataBind('i',concat('ff8',$Pos),'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Entry_x0020_Status')}" /><SharePoint:FieldDescription runat="server" id="ff8description{$Pos}" FieldName="Entry_x0020_Status" ControlMode="New" /></td>

</tr>

</xsl:if>

Also, quick note that I double-checked to make sure that there was no other field on the form with ff8 already. Another note: This is only an issue on Sharepoint Online. Sharepoint 2013 on-prem this still works fine.

Note 2: Is this methodology being depracated? Is there a better way of doing this?

TIA

Michael

5

Background

Unfortunately, SharePoint Online is notorious for this kind of things. They're updating something every now and then. I personally know about few situations when different javascript-based solutions stopped working because of minor changes to the page markup. So it helps to be consciously aware that such things can happen and will happen.

Also I have to say that although I was a big fan of XSLT in SP2010, XSLT is effectively dead in SP2013. There are several reasons for that, one being that CSR is used by default everywhere as the display engine now, and XSLT is thus not tested well, and even when SP2013 just released, there already were some new bugs in XSLT, and situation gets worse with time.

Now third thing to consider is that XSLT is not the correct place for doing permissions stuff. This always were so and continues to be so. XSLT is a formatting engine, nothing else. Meaning, that 3 rows of JavaScript or a simple REST query or a web service call or a search query - will fetch easily the columns you're trying to hide. Please be especially aware of that.

Options

Having said all that, I think you have two main options:

  1. Contact MS. If they accept that this is a bug and not a planned abandoning of this functionality, you might get your system working back after some time (several weeks or months, I would guess).
  2. Change implementation

Now if you're going with second option, you need then to decide, how this implementation is to be changed.

Here I can see, again, two main options:

  1. Hide columns using permissions (depending on your requirements, this might be not possible)
  2. Use CSR or other JS-based solution to hide the columns

Hiding columns using OOTB permissions

Although SharePoint doesn't have support for column-level permissions, sometimes it is still possible to use OOTB permissions to hide information in some columns.

Way to do it is to put columns that should be hidden into another list, and assign appropriate permissions to this list. And then add lookup columns into the main list, pointing to the restricted list.

Usually this works OK if you don't have many columns to hide and if you don't have too much data in the list. Also be aware that this possibly introduces some inconvenience for the users that will be changing the columns, as lookups only allow selecting items, but not adding them (although a simple CSR customization solves this - but it is still additional work).

So I want to stress one more time, that this solution is full of limitations and might not fit your requirements or your setup, but on the other hand, it is the only safe option if you're hiding some sensitive data and want them really hidden from everywhere.

CSR or other JS-based solution

Using CSR or JS is even less safe than using XSLT for hiding something, because in this case hiding happens client-side and all you have to do to fetch the hidden data is examine the page source code...

On the other hand, if you just need to hide some columns that are not relevant for certain users, but are not really sensitive, CSR or JS approach is absolutely OK.

But CSR or JS/jQuery? I would recommend CSR, because as I mentioned above, CSR is a bit more reliable, because it is now the default engine used for displaying almost all the data in SharePoint - including list forms, list views and search results.

Introductory articles about CSR in case you prefer this option can be found e.g. on CodeProject:

(Disclaimer: I'm the author of these articles)

Example for your case (here I'm hiding a column "AssignedTo" based on permissions):

SP.SOD.executeFunc("clienttemplates.js", "SPClientTemplates.TemplateManager", function() {
   SPClientTemplates.TemplateManager.RegisterTemplateOverrides({
       Templates: {
           Fields: {
               'AssignedTo': {
                   'EditForm':function(ctx) {
                       var hidden = ctx.FormContext.itemAttributes.EffectiveBasePermissionsLow & 16 != 16;
                       if (hidden)
                           return "";
                       else
                           return SPClientTemplates._defaultTemplates.Fields.default.all.all.UserMulti.EditForm(ctx);
                   }
               }
           }
       }
   });
});

(tested it and it works)

  • 1
    Andrey - this is exactly the kind of info I was looking for. Perfect! Thanks!!! – Michael Oh Jan 16 '15 at 19:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.