Questo strumento consente di abilitare le funzionalità di “social networking” all'interno di openDCN

A differenza dei più diffusi social network site, openDCN consente di definire le relazioni tramite le quali gli utenti possono stabilire un contatto reciproco, cioè entrare in relazione appunto.

Tramite la pagina Gestione → Relazioni è possibile configurare quante e quali relazioni mettere a disposizione degli utenti, e con quale nome, di che tipo, cioè simmetriche o asimmetriche, ecc.

Le relazioni sono mutuamente esclusive cioè un utente non può essere contemporaneamente legato alla stessa persona da più di una relazione. Questa assunzione genera diverse conseguenze sui meccanismi di gestione dei network.

I network personali degli utenti possono essere considerati come dei gruppi personali. Cioè ogni insieme di membri con cui un utente è in relazione può essere visto come un gruppo di cui quell’utente è “amministratore”. In quanto tale, egli ha a disposizione alcune operazioni effettuabili su di esso. Ogni network deve espressamente far riferimento ad una delle relazioni precedentemente configurate. Pertanto, ogni singolo network è identificato da due elementi: l’utente owner e la relazione in gioco. Nel caso delle relazioni asimmetriche, però, non bastano owner e relazione ad identificare un network: infatti, per ogni relazione asimmetrica ci sono due network, quello in entrata e quello in uscita. Bisogna quindi identificare, per ogni network di questo tipo, un senso. Le operazioni effettuabili dall’owner sui due network non sono le stesse: egli non può, ad esempio, decidere chi inserire nel network in entrata, cioè di quelli che lo seguono.

I network non vanno visti come gruppi da creare, bensì come gruppi già esistenti da “popolare”. Ogni utente ha a disposizione un network non appena viene creata la relativa relazione e può gestirlo decidendo chi inserire o rimuovere da esso. In una certa misura può anche stabilire a chi mostrarli.

Le opzioni configurabili per una relazione sono:

• il nome
• la descrizione che viene usata per indicare che è stata avviata
• simmetria (definisce se è simmetrica o asimmetrica)
• il nome dei membri del network in entrata
• il nome dei membri del network in uscita
• il nome dei membri del network in uscita (prima persona)
• l'eventuale approvazione obbligatoria
• la configurabilità della visibilità

L’approvazione è sempre obbligatoria per le relazioni simmetriche: nel momento in cui una persona vuole aggiungerne un’altra ad un proprio network simmetrico, deve necessariamente ricevere l’approvazione di quest’ultima. Per i network asimmetrici, di norma, non è così. Questa opzione, se selezionata, fa sì che, per quella particolare relazione asimmetrica, sia ugualmente necessaria l’approvazione della persona che si intende seguire. Si tratta di una modalità che garantisce un controllo maggiore rispetto alla sola possibilità di rimuovere qualcuno dal network dopo che vi si è aggiunto. Dovrebbe essere chiaro che, per le relazioni simmetriche, questa opzione non è deselezionabile.

Per quanto riguarda la configurabilità della visibilità dei network, le opzioni sono due: o la si rende possibile oppure no. Nel caso in cui la configurabilità non sia possibile, il default sarà quello di mostrare a tutti, anche agli utenti non registrati, i membri dei network interessati. La pratica comune, nel mondo dei social network sites, è quella di mostrare sempre le liste di contatti. OpenDCN adotta un approccio diverso, che garantisce maggior flessibilità di utilizzo: qualora si volesse garantire all’utente un maggiore livello di privacy, questo è possibile. Nel caso si decida di farlo, agli owner dei network in questione vengono rese disponibili le seguenti opzioni:

• Visibile a tutti;
• Visibile solo agli utenti loggati;
• Visibile solo ai membri di un qualunque network dell’owner;
• Visibile solo ai membri del network stesso.

In ogni caso, l’aggregato dei network (ovvero il quantitativo numerico di membri) è sempre visibile a tutti.

La modifica di una relazione può riguardare descrizione, approvazione e visibilità, ma non nome e simmetria. Queste due proprietà, infatti, costituiscono l’essenza di una relazione: cambiarle vorrebbe dire snaturare la relazione stessa.

La gestione dei network avviene sia nello spazio personale dell'utente che attraverso il profilo pubblico.

La sezione Gestione Network dello spazio personale contiene l’elenco di tutti i network (corrispondenti ovviamente alle relazioni esistenti). In esso l'utente può, quando possibile, impostare la visibilità delle reti. Inoltre, può accedere da qui alla sezione di gestione di ogni singolo network. I network in entrata e in uscita delle relazioni asimmetriche sono visualizzati separatamente. Nella sezione di gestione è possibile visualizzare l’elenco di tutti i membri, più, quando si tratta di una relazione soggetta ad approvazione, le richieste in entrata o quelle in uscita (entrambe, nel caso delle relazioni simmetriche). Per ogni membro si può visualizzarne il profilo pubblico, così come lo si può rimuovere dal network. Si possono accettare o rifiutare le richieste in entrata, così come si possono annullare le richieste in uscita che non abbiano ancora ricevuto risposta.

Nel profilo pubblico di ogni utente è visibile la Lista dei Network, con l’indicazione, per ognuno, del numero di componenti. C'è inoltre il pannello “Gestisci relazione” contenente il pulsante “Aggiungi” (presente anche nelle varie Liste di Membri che si possono aprire dalla Lista dei Network). Tale pulsante è il mezzo tramite il quale avviene la costruzione dei propri network e consente la scelta della relazione che si vuole stabilire e l'aggiunta al network o l'invio della richiesta.

L’utente non loggato, che comunque non può avere un suo pannello a disposizione, ha la possibilità di visualizzare il pulsante “Aggiungi” che compare nel profilo di un iscritto. Nell’eventualità in cui clicca su tale pulsante, viene invitato ad effettuare la registrazione per portare a termine l’operazione.

Come detto in precedenza, le relazioni sono mutualmente esclusive. Non si può essere contemporaneamente connessi allo stesso utente tramite due o più relazioni diverse. Questo implica che per far passare un proprio contatto da un network all’altro, bisogna necessariamente eliminarlo dal primo network e poi aggiungerlo al secondo. Nel caso si volesse farlo senza aver prima rimosso l’utente dal primo network, l’azione viene impedita. A questo punto, però, è bene spiegare meglio come abbiamo inteso l’esclusività. Ad esempio, se tra due utenti sussiste una relazione simmetrica e uno dei due decide che ne vorrebbe attivare un’altra, in base a quanto detto finora egli deve innanzitutto annullare la prima relazione. Meno automatico è decidere come regolare in tal senso le relazioni asimmetriche. Se un utente ne segue un altro, quest’ultimo deve essere libero di seguirlo a sua volta. Non solo: se un utente ha una relazione asimmetrica verso un altro utente, questi potrebbe voler attivare un altro tipo di relazione asimmetrica verso il primo. Gli sarà permesso di farlo? La risposta che ci siamo dati è ‘sì’: in questa situazione non c’è mutua esclusività. In altre parole, essa sussiste sempre tra tutte le relazioni simmetriche e tra queste e le relazioni asimmetriche. Tra network asimmetrici, invece, esiste solo quando questi sono nello stesso senso.

Per risolvere il problema dell’esclusività, abbiamo pensato di non far comparire il pulsante ‘Aggiungi’ quando un utente è in relazione simmetrica o asimmetrica uscente con un altro utente. Quando invece non c’è alcuna relazione, oppure c’è una relazione asimmetrica dall’owner dello spazio che si sta visualizzando verso il visitatore dello stesso, allora in quel caso compare il pulsante. Ma non è finita qui. Dobbiamo considerare anche i casi in cui ci siano di mezzo non relazioni già stabilite, ma richieste di relazione non ancora approvate. Se un utente ha inviato una richiesta ad un altro utente, questi può fare lo stesso oppure gli è impedito? La politica adottata è quella di obbligare il secondo utente, nel caso provi ad aggiungere l’altro, a decidere prima cosa fare della richiesta rimasta in sospeso. In questa situazione, chi ha inviato una richiesta non ancora approvata è come se avesse già attivato una relazione; di conseguenza, se visita lo spazio dell’altro, non può visualizzare il pulsante. Al suo posto, visualizza il nome della relazione per la quale sta aspettando risposta e lo stato pendente di questa; come nel caso di una relazione già stabilita, c’è il pulsante per rimuovere. Solo annullando la richiesta, egli potrà di nuovo avere a disposizione il comando per l’aggiunta. Allo stesso modo, una richiesta in sospeso verso l’utente che sta visualizzando lo spazio personale del mittente della richiesta è, da questo punto di vista, assimilata ad una relazione asimmetrica già stabilita. L’utente, quindi, visualizza il pulsante ‘Aggiungi’. C’è però una differenza. Se l’utente inviasse a sua volta una richiesta all’altro, si genererebbe una situazione di richieste in sospeso incrociate non semplice da gestire. Abbiamo preferito, dunque, una politica che forzi a decidere se accettare o rifiutare la richiesta pendente proveniente da un utente, prima di attivare una qualunque relazione nei suoi confronti. Come dicevamo, l’utente in questa situazione visualizza il pulsante ‘Aggiungi’, però, se lo preme, viene reindirizzato al pannello di Gestione network e invitato a decidere della richiesta in attesa. Una volta che l’avrà fatto, si ritroverà in una delle situazioni standard descritte in precedenza.

A parte il permesso per visualizzare i network degli altri, che, come abbiamo visto (non l'hai ancora spiegato), è gestito internamente al modulo, gli altri permessi sono stati creati nel contesto di gestione dei permessi già esistente (Permissions). Per quanto riguarda la gestione delle relazioni, sono stati inseriti in Relations Api i metodi permissionGetObjects(), permissionGetActions() e permissionGetRoles(). Tramite questi metodi, integrati nel meccanismo di Permissions, è possibile assegnare permessi sia sulle relazioni nel loro insieme, sia prese singolarmente. Le azioni sulle quali è possibile assegnare permessi sono:

• admin
• new
• edit
• delete

Il ruolo di Relation Administrator mette assieme tutti e quattro i permessi.