Webseite mit hierarchischer Struktur

Hallo,

letztlich habe ich das gleiche Problem, auch wenn es bei mir um die Homepage einer Schule geht, in der ich einzelne Bereiche für unterschiedliche Fächer voneinander abschotten möchte. Ich habe schon versucht mit "node hierarchy" und "content access" eine Einschränkung aufzubauen, was prinzipiell auch gelingt, aber es ist noch nicht wasserdicht (z.b. können Benutzer doch noch irgendwie Seiten an anderen Stellen im Menü einhängen) und ziemlich unhandlich (jede neue Seite muss erst mal vom Autor für den Rest seiner Gruppe freigegeben werden).

Hier macht sich störend bemerkbar, dass in Drupal Nodes und Menü völlig getrennte Dinge sind. Wir versuchen irgendwie die Struktur eines Menüs auf die Zugriffsrechte für Nodes zu übertragen, das kann eigentlich gar nicht gehen ohne zugleich die Gleichberechtigung der Nodes zu durchbrechen (denn die könnten ja überall in mehreren Menüs stehen).

Im Augenblick zweifle ich leider daran, ob das gewünschte mit Drupal überhaupt realisierbar ist... Das kommt davon, wenn man gewohnte Strukturen (in meinem Fall von Typo3 und Redaxo) auf neue Systeme übertragen möchte.

Hallo,

bei mir taucht genau das gleiche Problem auf. Wie kann ich User beim Anlegen von neuen Seiten auf bestimmte Menüpunkte beschränken.
Hat hierfür schon jemand eine Lösung ? Ich denke das Problem müsste ja auch schon früher aufgetreten sein.

Vielen Dank

Ich habe mich jetzt einen Tag lang mit verschiedenen Ansätzen auseinander gesetzt, aber keiner taugt so recht.

• Mit Node_Hierarchy lassen sich Hierarchien von Nodes automatisch aufbauen, dabei können auch gleich Menüpunkte mit erzeugt werden. Mit NodeAccess kann man dann einschränken, wer an welchen Nodes rumpfuschen darf, in Kombination ist das schon ganz brauchbar. Allerdings lässt sich damit kaum verhindern, dass der Benutzer Nodes ohne übergeordneten Menüpunkt erzeugt, die dann auf der obersten Menü-Ebene erscheinen...
• Mit Books gibt es ein in sich geschlossenes Strukturierungssystem, mit BookAccess lässt sich wieder einschränken wer an welchem Buch rumbasteln darf. Allerdings muss man dann damit leben, dass die Buchinhalte nicht automatisch im Menü erscheinen, bzw. ein eigenes Menü bekommen - die Navigation wird unschön durchbrochen.
• Mit Taxonomien lässt sich ebenfalls eine Struktur anlegen, die sich in ein Menü überführen lässt. Allerdings ist es mir nicht gelungen, daraus sinnvolle Zugriffsrechte abzuleiten.

Unterm Strich muss ich leider sagen:

Drupal bietet phantastische Möglichkeiten, lässt sich leicht erweitern und ist dabei elegant und schnell. Aber es setzt entweder sehr kooperative Anwender voraus oder schränkt sie sehr stark ein. Die Trennung von Inhalt und Darstellung geht hier sehr weit (wie man es sich von einem CMS ja wünscht), aber während für Inhalte sehr feine Rechte vergeben werden können steht man bei der Navigation recht alleine da.

Das ist schade, denn für Firmen, Behörden und Vereine ist es oft wichtig, die Organisationsstruktur auch in der Navigation abzubilden, und kooperatives Verhalten kann dort leider nicht bei allen Benutzern vorausgesetzt werden.

Meine gestrige Suche war zwar sehr umfangreich, aber die schiere Masse an Drupal-Modulen war wohl doch zu groß. Eben bin ich, nachdem ich mein Problem im vorigen Kommentar erst genauer erkannt habe, nochmal auf die Suche nach "menu"-Modulen gegangen und dabei auf "Menu Subtree Permissions" gestoßen, das scheinbar genau das macht, was ich brauche, nämlich Benutzer nach Rollen auf einzelne Submenüs zu beschränken.

Ich werd's für mich austesten und ggf. meine Lösung (oder mein Scheitern) erläutern!

ich habe es nun mit dem Modul "Menu Subtree Permissions" versucht. Bei der Aktuellen Version für D6 hatte ich aber kein Glück, hier wurde der Menüpunkt zum verwalten der Rechte des Menüpunkts nicht angezeigt.
Ich habe dann eine Version gefunden mit der es wohl funktioniert, auf folgender Seite http://drupal.org/node/329079 (menu_stp.zip)
Nun werde ich mal weiter testen.

Die Version, die mir als erstes begegnete, lies sich zunächst gar nicht installieren (da waren noch Debug-Ausgaben drin, die die Seite unnutzbar machten). Ich bin auch gerade auf der Suche nach eine lauffähigen Version, und meinerseits dankbar für jeden Hinweis. :-)

Okay,

mit der von dir verlinkten Version klappt es nun so wie ich es brauche. Ich bin nebenher auch noch auf eine Variante "menu advanced permissions" gestoßen, mit der das für ganze Menüs geht, beides zusammen wäre ein richtig feines Modul. Aber zumindest arbeiten einige Leute dran, das ist gut.

Zusätzlich zur Einschränkung des Menüs setze ich noch "nodeaccess" ein, damit die Besitzer der Seiten anderen Mitgliedern der gleichen Gruppe auf einfachem Weg Bearbeitungsrechte zuweisen können. Schöner wäre natürlich, wenn es ein Modul gäbe (vielleicht habe ich es nur noch nicht gefunden?), mit dem die Rechte generell nicht Benutzer-, sondern Gruppen-basiert verwaltet würden, oder sich die Bearbeitungsrechte sogar aus den Zugriffsrechten im Menü ableiten liesen!

anstatt "nodeaccess" nütze ich momentan das "Content Access" Modul mit freischaltung der "per content node access control" des Inhalts Typs.
Ich denke das ist ähnlich, hier lassen sich dann auch die Rollen zuweisen.
Trotzdem werde ich dann aber das "nodeaccess" auch nochmal antesten.

Content Access verstehe ich offenbar nicht richtig - oder es leistet nicht, was ich brauche.

Ich möchte, dass ein Benutzer für neu angelegte Seiten einstellen kann, wer sie bearbeiten darf, am liebsten nicht (nur) Personen- sondern (auch) Rollen-bezogen. Noch schöner wäre es, wenn automatisch aus der Position im Menü heraus eine "Bearbeiten"-Rolle abgeleitet würde, so in der Art "wer eine Seite an diese Stelle im Menü hängen darf, der darf dieses Seite auch sonst verändern". Das würde die Seiten-Rechte mit den Menü-Rechten zusammenführen und eine sehr elegante Einheit ergeben.

Vlt. lässt sich ja das menu_stp dahingehend ergänzen...

Im Augenblick suche ich übrigens noch nach einer Lösung, mit der Node-Besitzern die publish/unpublish-Funktionalität zugänglich gemacht wird, aber eben nur für ihre eigenen Nodes oder meinetwegen als Teil der "edit"-Rechte dann Rollenbasiert. Die beiden Module, die ich dafür gefunden habe (publishcontent und content_unpublish) passen beide nicht ganz, das eine bietet nur einen generellen "publish"/"unpublish" Recht für alle Nodes, nicht nur die eigenen, und das andere lässt zwar nur die eigenen "unpublish"en, aber wie kann der Benutzer sie wieder öffentlich machen? Vorerst bleibt als nur der Weg, Seiten aus dem Menü zu nehmen, womit sie aber z.b. in google-links weiterhin zugreifbar bleiben. Dafür muss es doch einen Trick geben?

Aufgrund der Diskussion zu Menu Subtree Permissions habe ich auch dieses Modul aktiviert. Ich sehe zwar rollenbezogene permissions für die Menüs aber wo wird ergänzt und geändert?

Übersehe ich was?

Die rollenspezifischen Rechte werden auf der Einstellungsseite des jeweiligen Menüpunktes eingetragen und gelten dann für diesen und alle Unterpunkte.

Hallo Leute,
ich weiß zwar nicht, ob das jetzt für alle von Euch hilfreich ist und ich beziehe mich jetzt mal primär auf den Thread-Beginner.

Ich glaube der Menü-Anasatz und auch Book und Taxomomie usw. ist in diesem Fall zu sehr Content-Bezogen und statisch.
Eine soziale Organisation über Menü-Strukturen und Access-Module klingt nach einer Hilfs-Konstruktion die man vielleicht bei weniger flexiblen CMS nutzen muß.
Ich sehe hier vor allem eine Möglichkeit des Social Network, in dem zusammen Content gepflegt wird, wofür Drupal viele nette Werkzeuge parat hat.

Das ist ein Super-Einsatz-Bereich für Organic Groups. Jede Sportart wird eine Gruppe. Mit OG User Roles kann es Redakteur-Rechte nur innerhalb einer Gruppe geben wie z.B. Volleyball-Redakteure.

Es kann auch noch "globale" Gruppen für Gemeinsamkeiten wie z.B. die Organisation des gemeinsamen Sportfestes usw. geben. Aber man muß ja auch nicht die gesamte Website mit OG organisieren.
Trainingszeiten, Wettkämpfe und Bilder können globale Content-Typen werden, die dann jeweils den Gruppen als Gruppen-Content zugeordnet und verwaltet werden können.
Wenn es Inhalts-Typen (oder Vereins-Aktivitäten) gibt, die nur in einer oder wenigen Gruppen (Sportarten) Sinn machen, dann kann mit og_content_type_admin die Verwendung bestimmter Content-Typen für einzelne Gruppen spezieller eingestellt werden.

Wie sich der Content dann in Menü-Strukturen usw. darstellt ist eine andere Sache, die aber auch lösbar ist. So lassen sich z.B. auch mit Pathauto URL-Pfade Gruppen-orientiert generieren und mit Views Gruppen-Inhalte als dynamische Menüs anzeigen.
Mit Date und OG_Calendar lassen sich auch Gruppen-Termine voneinander trennen usw. Die Möglichkeiten von Organic Groups sind sind sehr umfangreich.
Ich organisiere damit sogar meine private Website, um private Inhalte einer privaten Gruppe von Benutzern zum Lesen zu geben usw.

Viel Erfolg,
Carsten

--
paratio.com e.K.: Qualität-im-Internet.de

Hallo zum Zweiten,

Also eine Möglichkeit, die ich sehr praktisch finde und das Menü-System nur teilweise nutzt geht so:

• Die Website mit dem Primary-Menü in Haupt-Bereiche unterteilen.
• Für jeden Website-Bereich einen einzelnen Content-Typ nutzen (z.B. auch Blog) oder neu definieren.
• Mit Views dynamische Untermenüs anzeigen lassen.
• Mit MenuTrails den übergeordneten Primary-Link-Eintrag auf active setzen, wenn ein Content-Type aktiv ist

Mit diesem Verfahren "landen" automatisch Nodes eines Typs (die ein Nutzer mit entsprechenden Rechten anlegen darf) automatisch im Unter-Menü eines Hauptpunkts und der Benutzer benötigt gar keinen Zugang zum Menü-System. Mit Views und diversen anderen Werten (wie z.B. Weight oder CCK-Feldern), auf die Views zugreifen kann, kann man das Menü dann dynamisch ordnen lassen (auch abhängig seiner organischen Gruppe, siehe oben).

Ein Nachteil hat meine Lösung noch:
Das "Views-Menü" setzt den aktiven Node noch nicht auf "active" (als CSS-Klasse). Da gibt es zwar ein Feature-Request bei Views. Aber das Feature gibt es eben noch nicht. Ich habe mein Active-Trail zwar mit PHP in Griff, aber noch kein Modul zur Weiter-Verwendung durch andere draus gebastelt. Ich will da allerdings noch ein paar andere Probleme mit lösen, die mir häufiger in meinem Menüs begegnen.

Bis dann,
Carsten

--
paratio.com e.K.: Qualität-im-Internet.de

Warum erstellst Du dann nicht ein Haupmenü wo Du die einzelnen Bücher von jedem Bereich verlinkst? Das Hauptmenü dürfen sie nicht ändern. Die Bücher aber schon.
So hast Du beides: ein Menü was die User nicht ändern dürfen und darunter trotzdem die Bücher welche die jeweils zulässigen User ja ändern können.
Oder habe ich hier zu einfach gedacht?