This project has moved. For the latest updates, please go here.

Using SPUtility with Document sets and additional Javascript CSOM code

Dec 17, 2014 at 3:56 PM
Hello Kit, your nightmare from Italy is here again :-)
This time my goal is more ambitious, involving:
  • my "Clienti" (customers) list/custom content type with all his fields, both inherited from "Contact" and custom ones.
  • a "Controparti" (counterparts, opponents) list/content type, derived from "Contacts"
  • a custom content type ("Pratica", holding every document produced for the specific lawsuit) based on "Document set" with these custom columns:
    Cliente (lookup on Clienti list)
    Controparte (lookup on Controparti list)
I need to fill these "underscored" fields with values from the corresponding (without the _) field of the specific selected item of list "Clienti".
This should be accomplished using Javascript CSOM, querying the list, isn't it?
But... there is a big "but" before taking this step.
Creating a new "Pratica" (document set on steroids) it seems that there's no way to customize with web parts the "new document" form: under Library/Customize library/Web parts there are choices to customize "default display form" and "default edit form", so I cannot hide nor set readonly the "underscored" fields during the "create" phase (nor adding custom code to query the Clienti list).
Of course I can modify the "default edit" inserting my webpart, but it's somewhat counterintuitive for the users "you should create the Pratica ignoring these _ fields, and immediately after you should edit it and save without any modifications".

Have you ever messed with Document sets in the past? From a preliminary search, it seems that I need to add custom contents on _layouts/15/ folder to flank the standard NewDocSet.aspx (I wonder if it's possible at all on Office 365).
Dec 18, 2014 at 12:14 AM
Correct me if I'm wrong but isn't the first step to upload the document to the library? This is why you won't have a "NewForm" to edit.

After uploading the document, the user would need to edit the document's properties (EditForm) which is where your code would be running.
Dec 18, 2014 at 1:33 AM
Edited Dec 18, 2014 at 2:36 PM
The problem is occurring at "document set" level, when creating a new Pratica object.
I've used the words 'there's no way to customize with web parts the "new document" form' but I should have written "... New item", sorry.
I'll try using a Pratica2 custom content type with only two custom columns (lookups for Cliente and Controparte), "forwarding" to the contained documents the Cliente column.
After this, I can create a MyDocument custom content type, with every field needed to the JavaScript code to work.
At "document" level, you already provided me with a tool that can help me to hide & fill the fields... :-)

EDIT I'm having issues with this setup, I've opened a support call to Microsoft.
Dec 19, 2014 at 1:40 AM
Edited Dec 19, 2014 at 1:48 AM
Ahh I see what you are talking about now (first time experimenting with document sets!). I think you are correct, since the NewDocSet.aspx page is under layouts, I don't see any way to customize it or add web parts to it which means you won't be able to add SPUtility.js to the form.

Edit: Since you can't customize the form, maybe you can create your own UI and create the document set using the JavaScript API. Take a look at the code here: How to create a Document Set using SharePoint REST Interface
Dec 19, 2014 at 4:12 PM
Edited Dec 19, 2014 at 7:24 PM
Hmm... this code doesn't explain how to attach custom columns to newly created Document Sets... maybe I'll stick with the approach at document level only.
Thanks however for having found that one!

EDIT: this approach (section "Use the List View Web Part") seems interesting!

BTW, I'll soon post here my mixed code for handling the complex form for documents inside "Pratica-like" document sets.
I hope this evening, if it works at least at third tentative :-)