Wednesday, June 18, 2014

SharePoint - Spostare Document Set di grandi dimensioni

Per lo spostamento di Document Set da una libreria ad un'altra occorre tenere conto del contesto in cui si implementa la procedura di spostamento, in particolare se esiste la possibilità che i Document Set contengano documenti di dimensioni superiori ai 10 Mb.

Export/Import

In rete è la soluzione più consigliata, ma attenzione: per file di grandi dimensioni (superiori a 10Mb), funziona solo nel caso di Event Receiver (o Console Application).
Utilizzato in un Timer Job si riceve un errore decisamente incomprensibile, in fase di Export: "Unable to determine the identity of domain".
Questo messaggio ci ha fatto penare un bel po' ed è riferito ad una classe utilizzata dal package di gestione dello stream in fase di esportazione del Document Set (class IsolatedStorage).

//get Document Set Source
DocumentSet documentSet = DocumentSet.GetDocumentSet(itemToMove.Folder);
//get Target List
SPList targetList = web.Lists[docSetListTargetName];
//get content type id for target list 
SPContentTypeId contentTypeId = targetList.ContentTypes["Custom Document Set Name"].Id;
//export in a stream
byte[] documentSetData = documentSet.Export();
//get document set name
string documentSetName = documentSet.Item.Name;

//get folder target
SPFolder targetFolder = targetList.RootFolder;

//Assign all properties
System.Collections.Hashtable propertiesParent = itemToMove.Properties;

//Create new Document Set 
DocumentSet docSet = DocumentSet.Import(documentSetData, documentSetName, targetFolder, contentTypeId, propertiesParent, currentWeb.CurrentUser);

//then go to delete source document set


Folder.MoveTo

Utilizzando questo metodo viene spostato il Document Set con il suo contenuto, qualsiasi peso abbia, come fosse una Cartella (SPFolder) e successivamente, viene convertita in Document Set Content Type.

La cosa buona è che funziona anche per i Timer Job quindi senza problemi di size.

//get Document Set Source
DocumentSet documentSet = DocumentSet.GetDocumentSet(itemToMove.Folder);
//get Target List
SPList targetList = web.Lists[docSetListTargetName];
//get content type id for target list 
SPContentTypeId contentTypeId = targetList.ContentTypes["Custom Document Set Name"].Id;
//set Url of new Document Set in target list
string moveUrl = targetList.RootFolder + "/" + itemToArc.Folder.Name;
//move document set as folder
itemToMove.Folder.MoveTo(moveUrl);
//check new Document Set
SPFolder newDocset = currentWeb.GetFolder(moveUrl);
if (newDocset.Exists)
{
    //Update all fields from source
    foreach (SPField f in itemToMove.Fields)
    {
         if (!f.ReadOnlyField)
         {
              newDocset.Item[f.StaticName] = itemToMove[f.StaticName];
         }
    }
    //IMPORTANT: convert Folder to Document Set 
    newDocset.Item["ContentTypeId"] = contentTypeId;
    newDocset.Item["HTML File Type"] = "SharePoint.DocumentSet";                                                
    //then update
    newDocset.Item.Update();
}
else
{
   // Failed moving the docset or setting ... 
}

//no need to delete source Document Set


Tuesday, June 17, 2014

SharePoint - Il Check-Out e i Documenti Fantasma!

Lo scenario spettrale nel quale i Documenti scompaiono alla vista di tutti, compreso il System Account, ha una spiegazione (quasi logica) e anche una soluzione!

Il Cliente segnala l'impossibilità di salvare un nuovo Documento (nuovo), creato con Word, con un dato nome.
L'utente X accede alla Document Library su cui è impostato check-in/out per modifica.
Clicca su Nuovo Documento, apre Word, modifica il file e, per qualche ragione, NON esegue Check-in.
Chiude Word, oppure si pianta (non raro), o il browser va in errore (ancora meno raro), o qualsiasi altro motivo per cui non viene archiviato il file.

In questo scenario, gli altri utenti non vedono il documento. Nessuno. Solo l'utente X.

L'utente Y crea un nuovo file e lo vuole salvare, chiamandolo come il file creato (e non archiviato) dall'utente X.
MA riceve un messaggio: Non è possibile salvare il file perché l'utente X sta già modificando un documento con quel nome.

Il sistema dice che c'è quel file, ma non si vede e non possiamo sovrascriverlo né modificarlo perché lo fa già utente X. Neppure System Account lo vede, neppure con Power Shell..

L'utente X sembra l'unico che può vederlo.
L'utente X è l'unico che può cancellarlo.
L'utente X può risolvere il problema.

L'utente X è in maternità.

Microsoft ha previsto, fortunatamente (per loro), lo scenario descritto, fornendo la possibilità, nelle configurazioni della Document Library, di visualizzare i documenti che non hanno ancora una versione: ovvero sono stati creati, ma mai ne è stato eseguito un check-in.

Il Link Manage files which have no checked in version è abbastanza esplicativo.


Mostra i file non archiviati, senza versione:

Selezionando un documento e cliccando su Take Ownership of Selection, l'utente corrente ha la possibilità di prendere il possesso dei file, sostituirsi all'utente che non ha eseguito l'archiviazione, e modificare il file.


Risulta quindi, nella library, finalmente il file:



"SharePoint Mystery - The case of the missing documents" racconta la nostra storia
http://www.networkworld.com/article/2346678/microsoft-subnet/sharepoint-mystery--the-case-of-the-missing-documents.html