Questo sito utilizza cookie anche di terze parti. Per avere maggiori informazioni e per negare il tuo consenso al l'utilizzo dei cookie clicca qui. Se prosegui la navigazione acconsenti all'utilizzo dei cookie.OK
  • salta al contenuto

Documentazione openDCN

Strumenti Utente

  • Entra

Strumenti Sito

  • Ultime modifiche
  • Informativa sui cookie
Ti trovi qui: start » relazioni_e_network

relazioni_e_network

Differenze

Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.

Link a questa pagina di confronto

Both sides previous revision Previous revision
Next revision
Previous revision
relazioni_e_network [27/11/2014 11:14]
Leonardo Sonnante
relazioni_e_network [27/11/2014 15:45] (versione attuale)
Leonardo Sonnante
Linea 10: Linea 10:
 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.\\ 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 ​però sono //mutualmente ​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.\\+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.\\
  
 ===== Network ===== ===== 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 ​del quale 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 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.+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.
  
 ===== Gestione relazioni ===== ===== Gestione relazioni =====
  
-In fase di creazione di una relazione, potranno inserirne, oltre al nome, una breve descrizione ​da utilizzare ​per indicare, ad esempio nelle [[devel:​personal#​attivita_recenti|Attività Recenti]], ​che una relazione del tipo in questione ​è stata avviata ​tra due utenti. Inoltre, potranno stabilire, oltre chiaramente alla simmetria, altre proprietà che riguarderanno tutti i network ​basati sulla relazione ​in questione: si tratta dell’eventuale approvazione obbligatoria ​e della possibilità di configurare ​la visibilità.+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. 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.
Linea 36: Linea 45:
 ===== Gestione network ===== ===== Gestione network =====
  
-La gestione dei network avviene sia nello spazio personale dell'​utente che attraverso ​i profili pubblici degli altri utenti.+La gestione dei network avviene sia nello spazio personale dell'​utente che attraverso ​il profilo pubblico.
  
-==== Privata ​====+==== Spazio personale ​====
  
 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. 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.
  
  
-==== Pubblica ​====+==== Profilo pubblico ​====
  
-Nel profilo/pagina principale dello spazio personale ​pubblico di ogni utente è visibile la Lista dei Network, con l’indicazione,​ per ognuno, del numero di componenti. C'è inoltre il riquadro Connessione esistente / Aggiungi ​**(spiega)**. Questo compare sia nella pagina principale dello spazio personale pubblico, sia nelle varie Liste di Membri che si possono aprire dalla Lista dei Network. ​Il Pulsante ‘Aggiungi’ è di fondamentale importanza, in quanto ​è il mezzo tramite il quale avviene la costruzione dei propri network. Nel momento in cui è stato chiaro che saremmo andati a realizzare un sistema che supportasse un numero non prevedibile di relazioni, ​la scelta ​più naturale è stata concepire questo comando come composto da un form di tipo select, attraverso il quale scegliere il tipo di relazione che si intende instaurare, ​e un pulsante per inviare la richiesta ​o effettuare ​l’aggiunta.+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 ​nella pagina personale ​di un iscritto. Nell’eventualità in cui clicca su tale pulsante, viene invitato ad effettuare la registrazione per portare a termine l’operazione.+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.
  
  
 ==== Mutua esclusività ==== ==== Mutua esclusività ====
  
-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.+Come detto in precedenza, le relazioni sono //mutuamente ​esclusive// ​cioè non si può essere contemporaneamente connessi allo stesso utente tramite due o più relazioni diverse. Questo implica che per far passare un contatto da un network all’altro,​ bisogna necessariamente eliminarlo dal primo network e poi aggiungerlo al secondo.\\ 
 +La mutua esclusività sussiste sempre tra tutte le relazioni simmetriche e tra queste e le relazioni asimmetriche,​ ma tra i network ​asimmetrici, invece, esiste solo quando questi sono nello stesso senso.\\ 
 +Ad esempio, se tra due utenti sussiste una relazione simmetrica e uno dei due decide che ne vorrebbe attivare un’altra, in base all'​esclusività ​egli deve innanzitutto annullare la prima relazione.\\ 
 +Se un utente ne //segue// un altro, quest’ultimo ​è libero di //​seguirlo//​ a sua volta. ​Se un utente ha una relazione asimmetrica verso un altro utente, questi ​può attivare un altro tipo di relazione asimmetrica verso il primo. ​In questa situazione ​infatti ​non c’è mutua esclusività. ​ 
 + 
 +La regola delle mutua eslusività ha inoltre le seguenti implicazioni:​ 
 + 
 +  * Il pulsante "​Aggiungi"​ non compare 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.  
 +  * Se un utente ha inviato una richiesta ad un altro utente, quest'​ultimo è obbligato nel caso provi ad aggiungere il primo, a decidere prima cosa fare della richiesta rimasta in sospeso.\\  
 +In questa situazione infatti, 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"​. Se l’utente inviasse a sua volta una richiesta all’altro,​ si genererebbe una situazione di richieste in sospeso //​incrociate//​ quindi vi è l'​obbligo di decidere se accettare o rifiutare la richiesta pendente proveniente da un utente, prima di attivare una qualunque relazione nei suoi confronti. L’utente in questa situazione visualizza comunque 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. 
 + 
 +===== Permessi sulle relazioni =====
  
-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.+^ PERMESSO ^ AZIONE ^  
 +| new| creare ​una relazione ​| 
 +| edit | modificare ​una relazione ​| 
 +| delete | cancellare ​una relazione ​| 
 +| admin | somma dei permessi precedenti | 
 +\\
  
-===== Gestione permessi ===== 
  
-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: +===== Permessi sui network ​=====
-  * admin +
-  * new +
-  * edit +
-  * delete+
  
-Il ruolo di Relation Administrator mette assieme tutti e quattro ​i permessi.+Essendo integrati nella gestione del profilo utenti ​i permessi ​sono presenti nella tabella Users
  
 +^ PERMESSO ^ AZIONE ^ 
 +|net_admin | gestire reti degli utenti |
 +|net_edit | modificare reti degli utenti |
 +|net_visibility | impostare la visibilità reti degli utenti | 
 +|net_add | aggiungere utenti ai network |
 +|net_remove | rimuovere utenti dai network |
 +|net_accept | accettare utenti nei network |
 +\\
  
 +[[la_gestione_del_menu|indietro]] | [[la_gestione_dell_area_personale| avanti]]
relazioni_e_network.1417083295.txt.gz · Ultima modifica: 27/11/2014 11:14 da Leonardo Sonnante

Strumenti Pagina

  • Mostra pagina
  • Revisioni precedenti
  • Puntano qui
  • Torna su
Ad eccezione da dove è diversamente indicato, il contenuto di questo wiki è soggetto alla seguente licenza: CC Attribution-Noncommercial-Share Alike 3.0 Unported
CC Attribution-Noncommercial-Share Alike 3.0 Unported Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki