Node Access auf Grundlage von Taxonomy-Zuordnung bei Usern

ist sicher ein guter Ausgangspunkt. In der Familie gibt's eine ganze Reihe von Modulen, am besten mal ein bisschen in den "Related Modules" stöbern.

http://drupalmodules.com/module/taxonomy-access-control

Hallo Frank,

danke für den Tipp. Ich werde diese aus Ausgangspunkt für meine Suche nutzen. Leider kommt gerade dieses Bodul nicht in Frage, da bei mir MS SQL als DAtenbanksystem läuft.

Michell.

http://drupal.org/project/sqlsrv

Keine Ahnung, ob das was hilft ...

Oder das hier: Drupal 7 for Windows+IIS+MSSQL now available

Hallo Frank,

danke für den Hinweis. Unser Drupal läuft auf IIS und MSSQL überraschend schnell und stabil. Es gibt kleinere Probleme mit der Datenkonvertierung (ISO vs. UTF) die wir aber in den Griff bekommen und wir müssen beim Anlegen von Datumsfeldern das ISO-Format auswählen. EInzig das von dir empfohlene Modul weisst ausdrücklich darauf hin, dass es nicht für MS SQL gemacht ist. Aber es lässt sich ja vielleicht anpassen.

Danke.

Michell.

nur der Vollständigkeit halber:

http://drupalmodules.com/module/taxonomy-access-control-lite
http://drupalmodules.com/module/access-by-term
http://drupalmodules.com/module/taxonomy-simple-access

Ich glaube Access-By-Term bringt mich weiter. Die ersten Ansätze sind ziemlich viel versprechend.

Michell.

Nur interessehalber: Sollten nicht alle SQL-Abfragen vom DB-Layer von Drupal korrekt umgesetzt werden, d.h. wenn Drupal selber mit der Datenbank-Konstellation läuft, sollten das doch auch alle Module - sofern sie auch die korrekten Funktionen verwenden, oder?

• http://drupal.org/developing/api/database
• http://api.drupal.org/api/drupal/includes!database!database.inc/group/database/7

Grundsätzlich hast du recht. So sollte es sein und es wäre wünschenswert.

Allerdings scheinen nicht allzuviele User DRUPAL auf MS SQL zu nutzen. Daher gibt es hier (auch im Kern) noch ein paar Bugs.
Wie gesagt, funktioniert Datum nur im ISO-Format, bei Gleitkommazahlen hatten wir Probleme mit dem Feldtypen und ab DRUPAL-Kern 7.8 hat sich dann wieder ein Fehler in den Platzhaltern für erweiterte WHERE bzw. HAVING-Klauseln eingeschlichen - plötzlich haben keine Filter mehr funktioniert. Auch die neueste (stabile) Views-Version hat ein Problem damit, die Feldgröße für den Titel in der Updateroutine zu ändern.

Vielleicht liegt es einfach nur an fehlenden Testumgebungen für Entwickler. Wir sind ja auch selber schuld wenn wir eine Nischen-Datenbank (MS SQL) nutzen...

Trotz allem bin ich dennoch extrem positiv überrascht wie reibungslos es läuft. Ich hätte mit wesentlich mehr Problemen, speziell innerhalb von Modulen gerechnet.

Michell

Hihu,

ich habe ein ähnliches Problem (darum mache ich jetzt kein extra Thread auf):

Gibt es so etwas auch z.b. für Boolesche Felder? Also ich will da eigentlich nur ankreuzen "Öffentlich" bzw. "Nicht Öffentlich".

insbesondere auch, weil ich vermute, dass es bei Christoph um eine generelles Zugriffsszenarion geht.

Dennoch eine kurze Denkanregung: Drupal hat drei eingebaute Benutzergruppen: Gäste (nicht registrierte/nicht angemeldete User), registered User (angemeldete und registrierte Benutzer) und Administrators.

Diesen kann man Lese- und Schreibrechte auf unterschiedliche ContentTypes geben.

Wenn du mehr willst, nimm content_access und ACL.

Danke für die Anregungen. Ich denke, das reicht mir schon. :)

...hierzu dann gleich nochmal eine kleine Nachfrage von mir:

Wenn ich für verschiedene Bücher verschiedenen Benutzergruppen Schreibrechte einräumen will, wie kann ich das bewerkstelligen?
Wenn es also Bücher zu den Themen PHP, Java, HTML u.s.w. geben soll und in das Buch PHP sollen Benutzer A und B, in das Buch Java Benutzer X, Y und Z schreiben dürfen.

Dies scheint mit Bordmitteln nicht zu funktionieren, es sei denn ich würde den Inhaltstypen Buch clonen. Was mir aber dann bei 20 verschiedenen Büchern eher als umständlich erscheint.
Gibt es für diese Problematik vielleicht ein Modul?

Danke.

Michell

sonst findet hier keiner das Thema.

"Books" sind in der Hinsicht wirklich etwas haarig. Wenn du wirklich deine Benutzergruppen streng trennen willst, solltest du überlegen mit Organic Groups zu arbeiten. Dann käme vielleicht so was in Frage: http://drupalmodules.com/module/og-book-inheritance