Uso dei colori nei reports (data driven colors)

Esempio di utilizzo dei colori associati ai dati nel report (data driven colors)

Recentemente ho realizzato dei report relativamente complessi (Tabelle, Gantt, Matrici) utilizzando i colori per identificare visivamente meglio e a colpo d’occhio i dati contenuti. L’obiettivo era colorare la casella in cui venivano visualizzati dei dati (numerosi e variabili) collegando univocamente i dati ad colore specifico, in modo tale che dati vicini risultassero sempre con colori diversi. E volevo utilizzare il minor effort possibile.

Per lo sfondo della cella ho utilizzato i colori web (es. AliceBlue, DarkOliveGreen, DarkMagenta, YellowGreen, ecc. ), che tutto sommato sono abbastanza differenziati tra loro e numerosi (140), e li ho associati ad un progressivo (da 1 a 140) Per il colore del testo ho usato semplicemente Black (#000000) o White (#FFFFFF), visto che l’obiettivo è la massima leggibilità del contenuto e quindi la massimizzazione del contrasto: su colori scuri uso il bianco e su quelli chiari il nero, e quindi il colore del carattere è in funzione del colore di sfondo o meglio della sua luminanza.

Per il calcolo della luminanza ho utilizzato le seguenti formule (diverse per il calcolo della luminanza oggettiva e percettiva):

Luminance (standard, objective): (0.2126*R) + (0.7152*G) + (0.0722*B)
Luminance (perceived option 1): (0.299*R + 0.587*G + 0.114*B)
Luminance (perceived option 2, slower to calculate): sqrt( 0.241*R^2 + 0.691*G^2 + 0.068*B^2 )

dove R,G e B sono le 3 componenti del colore. Si applica Black oppure White se la luminanza supera o meno una certa soglia (io ho scelto 160, avendo quindi in media più scritte bianche). Ho quindi memorizzato tutto in una tabella di database (“COLORS”).

Tabella Colors

Tabella Colors

La tale tabella può essere utilizzata in JOIN con quella dei dati in modo tale che la chiave di quest’ultima venga mappata in modo (più o meno) univoco con i colori:

SELECT * FROM CALENDARIO_CORSI cal JOIN COLORS c ON c.ID = (cal.ID % 140)+1

In realtà è la semplice funzione Modulo che effettua la suriezione; la probabilità che dati visualizzati in celle vicine abbiano lo stesso colore è molto bassa (circa lo 0.7%).

Cell properties

Cell properties

I dati e i colori (background e forecolor) così associati possono essere utilizzati nei reports prodotti direttamente nelle pagine web o con Microsoft SQL Server Reporting Services, assegnando i valori alle relative proprietà delle celle.

Report colorato

Report colorato

Il risultato, ottenuto con pochi sforzi (generata una volta per tutte la tabella dei colori), è sicuramente qualcosa di gradevole.

Riferimenti

Colori web (nomi e valori): http://www.w3schools.com/html/html_colornames.asp

Algoritmi per il caloclo della Luminanza: http://zoltanb.co.uk/how-to-calculate-the-perceived-brightness-of-a-colour/

Data Driven Colored Text for SSRS: http://www.mssqltips.com/sqlservertip/2612/data-driven-colored-text-for-reporting-services-reports/

Pubblicato in SQL Server, Web | Contrassegnato , , | Lascia un commento

Migrazione dei permessi Sharepoint tra farm

Allineamento dei permessi tra ambienti di Test e Produzione

Dopo aver sviluppato una soluzione sharepoint, conviene testare le funzionalità dei pacchetti wsp in un ambiente di test, che deve essere simile se non identico, ma comunque separato da quello di produzione.
Trascurando la topologia della farm, per effettuare dei test significativi, devono essere “abbastanza” identici :

  • i contenuti delle web application e delle site collection
  •  i permessi applicati sugli oggetti (siti web, liste e items)

Un modo molto semplice per allineare periodicamente i conentuti è quello di effettuare un restore (stsadm o sql) del backup del Content DB di produzione nell’ambiente di test

A seconda del “posizionamento logistico” reciproco delle farm sharepoint di test e produzione, si potrebbero riscontrare problemi autorizzativi e di visibilità da parte degli utenti di test:

Caso 1: le Farm vivono nello stesso dominio AD
L’ambiente di test è una diversa farm sharepoint ma che si appoggia allo stesso dominio AD
Dopo il restore dei contenuti i permessi e le autorizzazioni sono riportati correttamente, ma in generale i test funzionali sono di difficile esecuzione,  essendo coinvolte nei test le utenze di produzione.

Caso 2: le Farm vivono in domini AD diversi
L’ambiente di test è una diversa farm sharepoint che si appoggia ad un dominio AD creato ad hoc.
Con il restore dei contenuti i vengono riportati i permessi e le autorizzazioni, ma sulle utenze e sui gruppi di produzione e non su quelli di test
Per esempio, se i domini sono DOMAIN_PROD e DOMAIN_TEST,  nell’ambiente di test (dopo il ripristino), il sito WEB rimarrà collegato a utenze di DOMAIN_PROD e non di DOMAIN_TEST.

Per ripristinare i permessi collegandoli alle utenze del dominio di test basta utilizzare i comandi:
STSADM –o migrateuser -oldlogin -newlogin [-ignoresidhistory]
STSADM –o migrategroup -oldlogin -newlogin [-ignoresidhistory]

basta quindi disporre della mappatura vecchio/nuovo ed il resto, con un paio di righe di shell scripting, è un gioco da ragazzi…

#Esempio:
#in list.txt sono elencati i gruppi AD oggetto della rimappatura
 DOMAIN_PROD\GROUP1;DOMAIN_TEST\GROUPA
 DOMAIN_PROD\GROUP2;DOMAIN_TEST\GROUPB
#allora basta lanciare il comando (nella farm di test)
 for /F "tokens=1,2 delims=;" %%i in (list.txt) do stsadm -o migrategroup -oldlogin "%%i" -newlogin "%%j"

Caso 3: le Farm vivono in reti separate ma con nomi di dominio AD identici
E’ il caso di ambienti enterprise che replicano nell’ambiente di test non solo la Farm Sharepoint, ma topologicamente anche l’intera infrastruttura di rete.
In questo caso il test funzionale è molto significativo, visto che le utenze di test hanno la medesima configurazione e le medesime autorizzazioni di quelle di produzione.
Dopo il restore dei contenuti i permessi e le autorizzazioni sono riportati correttamente e sembrerebbe che non debba essere effettuata altra attività.
Ma in generale la differenza tra le utenze AD in test e produzione sta, non nel nome, ma nel SID (e nel GUID).
Sharepoint memorizza il SID nel profilo dell’utente e/o del gruppo e le archivia nel Content DB, per cui i permessi risultanti non vengono risolti correttamente, soprattutto quando si utilizzano nei permessi gruppi AD annidati (gruppi AD definiti in funzione di altri gruppi)

 

Dove sharepoint  memorizza il SID

Dove sharepoint memorizza il SID

Per ripristinare il puntamento ai SID corretti basta utilizzare ancora una volta i comandi

STSADM –o migrateuser -oldlogin -newlogin [-ignoresidhistory]
STSADM –o migrategroup -oldlogin -newlogin [-ignoresidhistory]

il parametro -ignoresidhistory deve essere omesso oppure valorizzato a False (così viene eseguita la verifica dei metadati della cronologia dei SID del nuovo utente per controllare se corrispondono al nome del vecchio utente.  Se il valore è “True”, la verifica dei metadati viene ignorata)

Di fatto così viene fatto un refresh dei metadati ed in particolare dei SID.
Basta quindi disporre della lista degli utenti e dei gruppi utilizzati e il resto è poi una cosa banale…

#Esempio:
#in list.txt sono elencati i gruppi AD oggetto del riallineamento
 DOMAIN_PROD\GROUP1
 DOMAIN_PROD\GROUP2
#allora basta lanciare il comando (nella farm di test)
 for /F %%i in (list.txt) do stsadm -o migrategroup -oldlogin "%%i" -newlogin "%%i"
Pubblicato in Sharepoint, Software, Windows Autentication | Contrassegnato , | Lascia un commento

Bravo Seba!

Bravo Sebastiano, è stata proprio una bella gara. Ci stai regalando delle belle emozioni, grazie…

Serie 5 dei 100 Dorso Esordienti B Maschi – 7 Meeting City of Lignano

Serie 6 dei 50 Stile Libero Esordienti B Maschi – 7 Meeting City of Lignano

Serie 3 dei 100 Rana Esordienti B M

Serie 7 dei 100 Stile Libero Esordienti B M

 

 

Pubblicato in Pensieri | Contrassegnato , | Lascia un commento