Hi all! My latest scripting effort comes as a result of the 2010 –> 2013 migration from one of my customers. We should all know about the migration process (database upgrade, then site upgrade) and it was after the site upgrade that they were being informed that their QuickEdit options were disabled in *some of* their custom lists. Now this phenomenon has been discussed and talked about in many other blogs:
The request was multi-fold:
– Is there a way we can detect which lists will experience this problem?
I have not, as of yet, determined what causes this in some lists and not others, but for the purposes of this work we checked any custom list that had been upgraded to the 2013 UI.
– Is there an automated way we can correct it rather than manually navigating to each list?
So just to refresh the issue… In your 2010 environment, users could use Datasheet View to modify custom lists and it looked like this:
As long as the site remains in 2010 mode after upgrading the content database to 2013, the functionality remains and is still available. However after upgrading the site to 2013, then Datasheet View is replaced by QuickEdit and in some cases (as with my customer) is disabled:
You will also notice that the nice HTML5 UI is no longer here either.
To be 100% transparent, I didn’t do all the research on this issue. I simply provided the resultant script to fix it. What my customer found was that the issue affected all 2010 custom lists and after executing the site upgrade, the JSLink from their View had been set to ‘null’ or ‘empty’. In order to correct the issue, what they had to do was reset JSLink on their view to ‘clienttemplates.js’.
I’ve attached the script to this blog post, but the core of the logic is around enumerating through each list and each view of each list to check the value of JSLink. The script also have a report-only function – which is the default. If run in report-only mode, then no changes are made and only a list of the views and their corresponding JSLink values will be output.
The parameters for the script are:
Url – this represents the url of the web, site, or web application that you want to scan; Required
Scope – this represents the scope of the scan and can be one of the following: web, site, webapp; Required
Repair – this represents whether you want to repair the views that are found; Optional; default value is $false