Sichbarkeitskontrolle durch den Benutzer/ Inhaltsersteller
am 29.07.2011 - 10:58 Uhr in
Ich versuche gerade Benutzern zu ermöglichen, die eigenen Inhalte gezielt für alle oder nur gewisse Benutzergruppen sichtbar zu machen. Aktuell habe ich da zwei Ansätze, würde aber mal gerne sehen, ob ihr bessere Ideen habt :)
Mein Ziel
Im Prinzip wird das System z.B. von Google+ mit Kreisen/ Circles vorgemacht. Die Benutzer sollen sich selbst Benutzer in Gruppen/ Kreise einteilen können und später eigene Inhalte für alle, eine oder mehrere dieser Gruppen sichtbar (und für alle anderen unsichtbar) machen können.
1) Mittels reference Modulen
Mit den Modulen reference, Node access user reference und Node access node reference lässt sich schon einiges machen. Hier stört mich lediglich, dass die Sichtbarkeit der "Master Node" sich auch entsprechend ändert und somit nicht nur die gewünschten Inhalte, sondern auch die notwendige "Master Node" sichtbar wird. Diese sollte möglichst nur der User selbst sehen.
Die "Master Node" entspricht dann der Gruppe des Users und die per reference verbundenen Nodes erhalten dann die entsprechend gesetzten Berechtigungen (View, Update, Delete).
2) Access By Term
Mit dem Module Access By Term können Rechte (View, Create, Update, Delete) anhand eines vergebenen Taxonomy Terms vergeben werden. Der Besitzer der Node vergibt Tags auf die eigene Node. Nur User, die ebenfalls mit diesem Tag versehen sind, können die Node dann noch sehen bzw. je nach Rechten bearbeiten oder löschen.
Das klingt erstmal genau nach der gewünschten Lösung in nur einem Module (was 3 neue Felder bei dem Inhaltstyp und auch den Usern notwendig macht), ABER!
Leider kann der User sich auch selbst den entsprechenden Taxonomy Term im Profil setzen und somit sich selbst(!) die Ansicht. oder gar Editier- und Löschrechte am Inhalt vergeben da die Taxonomy Begriffe global und nicht für jeden einzelnen User sind. Wenn das kein Konfigurationsproblem ist oder es keine andere Lösung gibt dies zu verhindern, dann fällt dieser Ansatz wieder raus.
Habt ihr hier noch Tipps oder andere Lösungsvorschläge? Auf OG würde ich hier gerne verzichten, hatte ich aber auch entsprechend getestet. Würde funktionieren, wobei die beiden oben genannten Lösungsansätze komfortabler für die Benutzer erscheinen und weniger kompliziert/ aufwändig.
- Anmelden oder Registrieren um Kommentare zu schreiben
Xeto schrieb Auf OG würde ich
am 29.07.2011 - 11:35 Uhr
Auf OG würde ich hier gerne verzichten, hatte ich aber auch entsprechend getestet. Würde funktionieren, wobei die beiden oben genannten Lösungsansätze komfortabler für die Benutzer erscheinen und weniger kompliziert/ aufwändig.
Ich persönlich finde OG geradezu prädestiniert für diese Aufgabenstellung ("die eigenen Inhalte gezielt für alle oder nur gewisse Benutzergruppen sichtbar zu machen."). Wenn ein Gruppen-Beitrag geschrieben wird, kann der User im Node-add-Formular mit einem Klick festlegen, für welche Gruppen der Beitrag gedacht ist. Wie sollte das denn noch komfortabler realisiert werden?
Drupal 7 Screencasts in deutsch!
Von der Funktionalität her
am 29.07.2011 - 11:52 Uhr
Von der Funktionalität her bietet OG genau das, was auch References da bietet. Das stimmt. Jedoch ist es wesentlich komfortabler z.B. Terms mit autocomplete deluxe/ active tags Widgets zu pflegen als mit einem einfachen OG multiselect Auswahlfeld. Ich habe auch keine Möglichkeit gefunden dieses einfache Auswahl-Widget bei OG durch etwas komfortableres zu ersetzen. Dazu sind die Rechte der Gruppen für den Gruppen-Admin viel zu umfangreich für meine Zwecke. Mir geht es lediglich um View-Rechte auf Inhalte verschiedener Hinhaltstypen, wobei der Autor des Inhalts seine eigenen Gruppen bestimmt und festlegt, welche die Inhalte dann auch sehen sollen.
OG würde ich vielleicht später trotzdem noch einsetzen, aber nicht für diese "Filterung" der Inhalte, sondern um "richtige Gruppen" zu realisieren, welche vom Gruppenadmin administriert und betreut werden.
Und im Vergleich zum OG-Module wäre meine Aufgabe mit Access by Term mit einem 10KB Modul (und evtl. ein zweites weil dieser Term nicht global sein dürfte...) erschlagen!
Kennst du vielleicht eine Möglichkeit für einen Taxonomy-Begriff die Nutzung auf die eigenen Begriffe zu beschränken? Wobei ich nicht sicher bin, ob das so einfach funktioniert in Verbindung mit dem Access by Term Modul...
Sollte die Variante mit ABT-Module nicht funtionieren, muss ich mir natürlich überlegen, ob ich über references (angenehmere Widgets, weniger Möglichkeiten) oder OG (sehr umfangreich und komplexer) zurückgreife.
Unabhängig vom Weg, der
am 29.07.2011 - 13:13 Uhr
Unabhängig vom Weg, der später gewählt wird...
Ist es möglich Taxonomy-Begriffe im Zugriff bzw. der Nutzung auf den Ersteller des Begriffs zu beschränken?
Es gibt
am 29.07.2011 - 13:29 Uhr
Es gibt http://drupal.org/project/private_taxonomy - allerdings nicht für D7.
Andere Module sind mir nicht bekannt. Falls Du da was Alternatives findest, gib bitte eine Rückmeldung.
Drupal rockt!!!
Ich habe in dem Zusammenhang
am 29.07.2011 - 14:03 Uhr
Ich habe in dem Zusammenhang auch schon länger gesucht und nichts passendes gefunden. Die Variante mit References funktioniert in der Form und basierd an dem Punkt auf mehreren Modulen und anstatt einem Taxonomy Term auf einer (Master) Node. Diese zu verstecken sollte vielleicht eher irgendwie möglich sein. Ansonsten ist der Weg unkompliziert und funktioniert.
(OG ist momentan außer Konkurrenz und bietet diese Möglichkeiten natürlich auch)
Möglicherweise wird das Access by Term Modul um diese Funktionalität erweitert, was für ein access control Modul sicherlich wünschenswert wäre. Wenn jeder User sich selbst die Tags hinzufügen darf, dann ist es lediglich als Filter und nicht zur Zugriffskontrolle geeignet...
Ich habe auch schon einen
am 02.08.2011 - 12:13 Uhr
Ich habe auch schon einen Punkt erreicht, an dem ich wieder zu OG tendiert habe, aber irgendwie hat mich das unter D7 noch nicht überzeugt. Für Inhalte in eine gewisse Hierarchie zu bringen bietet sich natürlich http://drupal.org/project/nodehierarchy an :) Da gibt es auch - anders als im OG-Modul bereits einen "Create Child content" Link ;)
Das ist natürlich kein Grund DIESES Modul anstatt OG zu benutzen, muss ich aber mal in Verbindung mit OG testen, da so vielleicht die Verwaltung der Gruppeninhalte angenehmer für die Mitglieder wird...
@Thoor:
Der User muss im globalen Node-add-Formular Inhalt erstellen und muss darin die Gruppe auswählen, in welcher er posten will UND muss gegebenenfalls auf private setzen, damit andere User die Inhalte nicht sehen... Das sind 2 Klicks und wird einer vergessen, sind die Inhalte nicht in der Gruppe und öffentlich.
Bei der Variante mit References darf man natürlich auch nicht vergessen die Gruppe (bzw. Kreise wie bei Google+, daran erinnert mich die Benutzung nämlich), aber das Auswahlen ist mit Autocomplete und ohne Multiselect Feld angenehmer.
In Schweden hat mal jemand
am 03.08.2011 - 09:56 Uhr
Es gibt eine ähnliche Funktion unter User Relationships (User relations). Dort gibt es ein Zusatzmodul mit dem man an siene Freunde schreiben kann und andere User den Beitrag nicht lesen können. Allerdings ist die Usability schlecht, da das Programm mit einem einfachen Node Access arbeitet, der vom Verfasser eingestellt werden muß. Auf der Drupal.org Website gibt es jemand, der es wohl geschafft hat, dass User die Option nicht ankreuzen müssen und der Node automatisch "geschlossen" ist.
In Schweden hat mal jemand einen Artikel geschrieben über die Frage, wie man OG nachbauen könnte. Vielleicht hat der Verfasser noch ein paar Anregungen.
http://nodeone.se//blogg/johan-falk/alternative-solution-to-organic-groups
@Thoor
Die Auswahl für unterschiedliche Gruppen ist m.E. nur dann konfortabel, wenn man es mit erfahrenen Benutzern zu tun hat. Es gibt für D6 noch ein Modul mit dem man diese Auswahl für User beschränken kann.
Danke für den Tipp und den
am 03.08.2011 - 11:48 Uhr
Danke für den Tipp und den Link. Der Artikel ist sehr gut und den kannte ich auch schon. Basierend auf dem habe ich erste Tests ohne OG gemacht ;)
Das in Verbindung mit nodehierarchy ermöglicht mehr oder weniger auch "Gruppenseiten/-inhalte" mit einem bequemen "Create Child Node"-Link auf der entsprechenden Seite. Leider gibt es mit dem node hierarchy Module noch Berechtigungsprobleme, da die User trotz der "Create child"-Berechtigung keine entsprechende Nodes anlegen können (außer der User hat grundsätzlich die Create node Rechte des Inhaltstyps). Zumindest kann der User entweder überall den Inhaltstyp anlegen oder gar nicht... Ich würde aber die Rechte gerne nur lokal in der eigenen Hierarchie und nicht global in der Seite vergeben.
Da schaue ich noch nach einer Lösung ;)
Aktueller Stand ist momentan
am 21.08.2011 - 10:26 Uhr
Aktueller Stand ist momentan folgender...
Access by term bietet im Pronzip die gesuchte Möglichkeit, arbeitet aber nicht mit privaten Taxonomy Begriffen pro User und bietet damit keine Zugriffskontrolle durch den Ersteller. Jeder User kann sich selbst die notwendigen Begriffe vergeben...
Da habe ich als Ansätze bisher nur private_taxonomy (D6) und community_tags (erfüllt die Anforderungen wohl nicht) gefunden, aber noch keine Lösung.
Nodeaccess_userreference ermöglicht die notwendige Zugriffskontrolle, jedoch ist es hier bisher noch nicht gelungen die "Kreise" (Circles bei Google+) vor den anderen Benutzern zu verstecken! Den nicht jeder User soll sehen, in WELCHEM Kreis er bei einem anderen Mitglied eingeteilt ist...
Hier habe ich aber die Hoffnung noch eine Lösung zu finden...
Vielleicht nutzt es, wenn man
am 21.08.2011 - 17:12 Uhr
Vielleicht nutzt es, wenn man sich noch einmal die Grundfunktion von OG überlegt....
OG ist letztendlich nichts anderes als dass ein User ein Forum anlegt und je nach Einstellung Lese-und Schreibrechte in diesem Forum vergibt.
Die "Mitglieder" werden angezeigt.
Ein weiteres Modul verschickt Infos über neue Beiträge.
OG sind erstmal Gruppen mit
am 22.08.2011 - 06:53 Uhr
OG sind erstmal Gruppen mit festen Mitgliedern und Inhalte, welche im Gruppenkontext gepostet werden können. Und von einem Forum für Gruppen reden wir mal lieber nicht. Das ist aktuell bei D7 immer noch nicht möglich. Dazu war unter D6 das zusätzliche Modul og_forum notwendig, welches schon dort mit Sicherheitslücken zu kämpfen hat und noch nicht portiert worden ist.
Für ein Forum heißt das dann, dass die Beiträge aller Gruppen im selbigen Forum sind, aber nur für die Mitglieder der eigenen Gruppen sichtbar sind. Das ist eher verwirrend, da irgendwann niemand mehr weiß, welcher Beitrag für wen sichtbar ist. Selbiges lässt sich auch mit References erreichen, ist dabei aber wesentlich komfortabler für den Benutzer.
Auch bin ich mir nicht sicher, ob die Gruppe vor allen Mitgliedern (auch den Gruppenmitgliedern) versteckt werden kann und die Inhalte für die Gruppenmitglieder dann trotzdem angezeigt werden können. Das ist der einzigste Punkt an dem die Alternative bei besserer Bedienbarkeit scheitert. Und ich wär mir jetzt nicht sicher, ob das mit OG besser funktioniert...
Und Features von OG aus D6 fehlen scheinbar in D7 noch komplett. Es gibt keine funktionierenden OG-Blöcke mit Navigation, Gruppeninformationen oder auch nur einem "Inhalt erstellen"-Link. Wenn man also die Grundfunktionalität sieht, bietet OG nicht mehr und ist dabei weniger Benutzerfreundlich... Gäbe es zumindest das og_forum Module, würde ich zumindest in dem Bereich einen Vorteil sehen.
Als kurzes Update. OG 7.2 ist
am 23.06.2012 - 16:14 Uhr
Als kurzes Update. OG 7.2 ist auf einem guten Weg. Damit kann man Beiträge mittels autocomplete deluxe und tag style komfortabel Beiträge an gewisse Gruppen posten. Damit wäre dies schonmal sehr schön abgedeckt. Was jedoch leider fehlt ist eine komfortable Möglichkeit oder ein Widget (z.B. ein Context-Menü beim User Avatar oder innerhalb einer View zum An-/Abwählen der eigenen Gruppen für diesen User) einen User zu einer oder mehreren eigenen Gruppen hinzuzufügen.
Da klemmt es auch momentan und scheint auch nichts auf dem Weg zu sein, was diese Lücke behebt.
Die OG Mitgliederverwaltung ist da eher unkomfortabel und unpraktisch, besonders wenn man dieses Feature mit G+ oder auch nur Facebook vergleicht.
Kreise/ Freundeslisten mit OG wäre natürlich zu bevorzugen, wenn man OG auch für sonstige Gruppen innerhalb der Seite verwendet. Auch weil man so dann an Freundeslisten UND Gruppen Inhalte teilen kann...
Die Alternativen Lösungen User_relationship (Admin definierte Listen), flag_friend (nur "eine" Freundesliste, keine User definierten Listen!) oder reference Module (viel Bastelei, was bei Updates sicherlich irgendwann Probleme macht) bietet nicht die gewünschte Grundfunktionen (mehere User erstellte Freundeslisten und entsprechender Sichtbarkeitskontrolle).
Access by Term funktioniert nicht für Benutzer gesteuerte Zugriffskontrolle, sondern ist für Admin-Benutzer gedacht. Zumindest waren eigene Tests mit ABT und z.B. private taxonomy nicht erfolgreich.
Sofern es ein schönes UI für die Mitgliederverwaltung bei OG 7.2 (User komfortabel und schnell eigenen Gruppen hinzufügen/ entfernen) geben würde, wäre das inzwischen meine erste Wahl!