Differenze

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

--- relazioni_e_network [27/11/2014 12:45]
Leonardo Sonnante
+++ relazioni_e_network [27/11/2014 15:45] (versione attuale)
Leonardo Sonnante
@@ Linea 47: / Linea 47: @@
 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.
-==== 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à ====
-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à.
-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.
+La regola delle mutua eslusività ha inoltre le seguenti implicazioni:
-===== Gestione permessi =====
+  * 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.
-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 sulle relazioni =====
-  * admin
-  * new
-  * edit
-  * delete
-Il ruolo di Relation Administrator mette assieme tutti e quattro i permessi.
+^ PERMESSO ^ AZIONE ^
+| new| creare una relazione |
+| edit | modificare una relazione |
+| delete | cancellare una relazione |
+| admin | somma dei permessi precedenti |
+\\
+===== Permessi sui network =====
+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]]

Documentazione openDCN

Strumenti Utente

Strumenti Sito

Differenze

Strumenti Pagina