Find computer name and domain using Powershell

Sometimes it’s useful to know the computer name and domain you are working on. More than once I had to google for these commands because I just can’t keep them in mind, so I decided to write a quick post as a reminder. The following are my favorites.

The first one returns the FQDN of the computer on the format whereas the second one returns a list of information about the computer such as NETBIOS name (that could be different from the DNS name), domain name, phisical memory, etc… You can also select single properties, changing the cmdlet this way:

That’s all. As I said before this was a quick one :)
– Riccardo

 

BCS database is in compatibility range

I know, this is a very well known “problem”, but every time I update a SharePoint 2013 farm I forget about it. So please forgive me, this is more like a self-reminder hoping to keep this topic in mind at least until the next update.

If you don’t know what I’m talking about, when you install an update (starting from March 2013 PU), you can find that one or more databases are “in compatibility range and upgrade is recommended“. Honestly I can’t tell why it happens, but the resolution is quite easy.  (more…)

SharePoint 2010 Modal Dialog Options: dialogReturnValueCallback

[UPDATE]

Barbara mi ha fatto notare giustamente un paio di imprecisioni nel javascript.

  1. Nel blocco seguente le note non sono commentate correttamente.

if(dialogResult == SP.UI.DialogResult.OK){
\ L’utente ha cliccato sul tasto Salva
} else{
\ L’utente ha cliccato sul tasto Annulla o ha chiuso la finestra modale
}

dovrebbero essere così

if(dialogResult == SP.UI.DialogResult.OK){
// L’utente ha cliccato sul tasto Salva
} else{
// L’utente ha cliccato sul tasto Annulla o ha chiuso la finestra modale
}

  1. Nella riga options.url = formUrl; c’è un errore di sintassi. formUrl era stato infatti definito con l’iniziale maiuscola, quindi: options.url = FormUrl;

Una precisazione infine su dove posizionare lo script. Non è necessario inserirlo nell’head della pagina. Tuttavia personalmente preferisco non avere script isolati nelle pagine, ma concetrare il più possibile  funzioni e stili in file esterni.

[/UPDATE]

In un progetto che ho seguito nelle scorse settimane ho avuto la necessità di personalizzare il comportamento di apertura e chiusura delle finestre modali di visualizzazione/modifica di una lista SharePoint.

Il mio obiettivo era gestire, oltre a dimensioni e titolo della finestra, il comportamento alla sua chiusura, eseguendo azioni differenti a seconda dell’azione che ha portato alla chiusura stessa: submit o cancel.

Prima Barbara (ottimo il suo post) poi Claudio mi hanno guidato sulla strada giusta, come sempre!

Nelle opzioni di apertura della nuova finestra (var options = SP.UI.$create_DialogOptions();) è possibile definire una funzione javascript custom che verrà eseguita alla chiusura (options.dialogReturnValueCallback = nomedellafunzione;).

Le funzioni che vengono utilizzate in questo modo accettano due parametri (dialogResult e returnValue). Sfruttando il primo di questi due parametri possiamo andare a controllare in modo molto semplice (dialogResult == SP.UI.DialogResult.OK) se l’utente ha effettuata il salvataggio dell’item o se ha chiuso la finestra / annullato l’operazione.

Facciamo un esempio “pratico”.

<a href=”javascript:ApriFinestraModaleConOpzioni(‘../editform.aspx’)>Modifica elemento</a>

Questo è un semplice link ad una funzione js, niente di nuovo, vero?

<script type=”text/javascript”>

function ApriFinestraModaleConOpzioni(FormUrl){
var options = SP.UI.$create_DialogOptions();
options.url = formUrl;
options.title = ‘Il titolo della nuova finestra’;
options.dialogReturnValueCallback = FunzioneDiUscita;
SP.UI.ModalDialog.showModalDialog(options);
}

// In questa prima funzione vengono istanziate le opzioni della nostra finestra modale. SP.UI.$create_DialogOption(); è l’oggetto che permette il “miracolo”;

function FunzioneDiUscita(dialogResult, returnValue){
if(dialogResult == SP.UI.DialogResult.OK){
\ L’utente ha cliccato sul tasto Salva
} else{
\ L’utente ha cliccato sul tasto Annulla o ha chiuso la finestra modale
}
}

// La seconda funzione non fa proprio nulla, è solo un esempio :)

</script>

A questo indirizzo trovate un approfondimento su tutte le opzioni disponibili nell’oggetto SP.UI.ModalDialog.showModalDialog,

http://msdn.microsoft.com/en-us/library/ff410058.aspx

mentre in questo trovate i possibili valori del parametro dialogResult

http://msdn.microsoft.com/en-us/library/ff409060.aspx

e ovviamente, ancora una volta, il post di Barbara

http://nonsolosharepoint.wordpress.com/2011/02/09/finestre-di-dialogo-sharepoint-2010/

Semplice e potentissimo, non trovate?

-Riccardo

Modificare file PDF in SharePoint

Prima cosa, intendiamoci, non sto postando una formula magica. Un requisito, anzi, IL requisito per modificare file PDF direttamente in SharePoint (ma non solo) è quello di avere installato sul client da cui accedete a SharePoint un editor PDF (Adobe Acrobat, Foxit PDF Editor, ecc…). Ho testato la procedura seguente sia con SharePoint 2007 SP2 (CU Febbraio 2010) che con SharePoint 2010. In ambedue i casi ho utilizzato una trial di Adobe Acrobat 9.

  1. Per prima cosa dobbiamo modificare il file DOCICON.XML (in drive:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATEXML) per aggiungere la proprietà OpenControl nel mapping relativo al PDF (es. <Mapping Key=”pdf” Value=”icpdf.gif” EditText=”Modifica in Adobe Acrobat” OpenControl=”SharePoint.OpenDocuments” />);
  2. Nelle impostazioni della document library suggerisco di impostare l’estrazione obbligatoria dei documenti per la loro modifica;
  3. In Adobe Acrobat modificare le impostazioni di apertura dei file pdf nel browser, considerando quanto segue:
    • Se abilitata, disattivare l’apertura nel browser dei file PDF e chiudere Acrobat. Aprite nuovamente il programma e riabilitate la gestione dei file pdf nel web all’interno del browser. Sembra che Acrobat durante queste operazioni attivi un ActiveX o non so bene quale altro controllo, per noi indispensabile;
    • Se non abilitata, abilitarla ora;
  4. Aprire un documento PDF per la modifica. IMPORTANTE! Ricordarsi di selezionare sempre l’opzione di utilizzo delle “Draft folder” personali;

Cliccando sul nome del documento posso scegliere se aprire il file nel browser in modalità read only o effettuare il check-out and edit per lavorare sul documento. Nei miei test ho notato quanto segue:

  1. Se sceglo l’opzione di modifica check-out and edit specificando di utilizzare la local draft folder posso modificare il file e salvarlo direttamente in SharePoint senza passaggi aggiuntivi;
  2. Se scelgo l’opzione di modifica check-out and edit senza specificare l’utilizzo della local draft folter, ricevo un errore e non sono in grado di salvare le mie modifiche;
  3. In un file già estratto, cliccando sulla voce “Modifica in Adobe Acrobat” (dal menù contestuale di un file PDF) e seleziono la voce “Use local drafts folder”, posso modificare e salvare il file correttamente;

Come ho detto in precedenza ho effettuato questi test sia su SharePoint 2007 che SharePoint 2010 (non mi aspetto alcuna differenza con WSS e SPF anche se non l’ho testato direttamente). La procedura è identica, l’unica attenzione da porre in SharePoint 2010, se volete aprire i file PDF in sola lettura nel browser, è quella di cambiare le impostazioni di gestione dei file nel browser (Browser file handling) da Strict a Permissive. Questa impostazione è applicabile a livello di web application.

– Riccardo

Trasformazione di stringhe in XSLT

In generale gestire la trasformazione di una stringa, sia in linguaggi client side che server side, è una cosa semplice. Non è però così  immediato farlo all’interno di una data view via XSLT.

Gogolando ho trovato un template XSLT (qui) che permette in modo molto semplice di trasformare “mele” in “pere” o, citando casi più probabili “&” in “%26”. Eccolo qui:

<xsl:template name="replaceCharsInString">
<xsl:param name="stringIn"/>
<xsl:param name="charsIn"/>
<xsl:param name="charsOut"/>
<xsl:choose>
<xsl:when test="contains($stringIn,$charsIn)">
<xsl:value-of select="concat(substring-before($stringIn,$charsIn),$charsOut)" disable-output-escaping="yes" />
<xsl:call-template name="replaceCharsInString">
<xsl:with-param name="stringIn" select="substring-after($stringIn,$charsIn)"/>
<xsl:with-param name="charsIn" select="$charsIn"/>
<xsl:with-param name="charsOut" select="$charsOut"/>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$stringIn"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>

Il template si richiama, dove serve, passando tre parametri: la stringa originale, la stringa da sostituire, la stringa corretta.

<xsl:call-template name="replaceCharsInString">
<xsl:with-param name="stringIn" select="string(@iltuoTitolo)"/>
<xsl:with-param name="charsIn" select="'&amp;'"/><!-- ATTENZIONE, la stringa &amp; è inclusa tra apici singoli '&amp;' -->
<xsl:with-param name="charsOut" select="'%26'"/><!-- ATTENZIONE, anche questa stringa è contenuta tra apici singoli '%26' -->
</xsl:call-template>

Un aspetto interessante di questo template è che può essere utilizzato anche per gestire la presentazione dei campi di lookup a selezione multipla, trasofrmando un elenco di stringhe separate da punto e virgola in quello che volete (es. un elenco puntato/numerato). Per fare questo è necessaria una piccola modifica al template, giusto per inserire nell’output il codice HTML corrispondente alla nuova formattazione.

Un’altra trasformazione che spesso viene richiesta (per scelta o per forza vista l’estrema fantasia di editors e contributors… :)) è quella da maiuscolo a minuscolo o viceversa. In questo caso non è necessario utilizzare un template custom, è sufficiente creare due variabili e utilizzare la funzione OOTB translate. Ecco come fare (lowercase to uppercase, per gestire il processo inverso invertire la posizione delle due variabili nella funzione translate).

<xsl:variable name="vLowercaseChars_CONST" select="'abcdefghijklmnopqrstuvwxyz'"/>
<xsl:variable name="vUppercaseChars_CONST" select="'ABCDEFGHIJKLMNOPQRSTUVWXYZ'"/>
<xsl:variable name="normalizedChars" select="translate(@ilvostrocampoqui, $vLowercaseChars_CONST , $vUppercaseChars_CONST)" />

Una pecca di queste tre righe è quella di non prevedere la possibilità di inserire caratteri intermedi con uno stile diverso, come ad esempio una maiucola dopo un punto. Se qualcuno ha scritto un template per gestire questo aspetto è il benvenuto su queste pagine ;)

– Riccardo