Weil's so schön war - Benutzergruppe darf nur eigene Themen sehen/lesen

  • Ähm, das Problem ist das die ThreadPage-Klasse eine PermissionDeniedException wirft, sobald canReadThread nicht vorhanden ist. Die müsste ich ja unterbinden, damit ich die Seite anzeigen sofern ein Recht ala canReadOwnThread vorhanden ist. Ich hoffe das war verständlicher ^


    Korrigiere mich @norse ich falsch liegen sollte ;)

  • Wahrscheinlich müsste man für so eine Umsetzung anders denken, als das Permission-System derzeit denkt.


    Also denken wir einfach mal "anders".


    Ich komme in ein Thema wenn ich die Berechtigung canReadThread habe. Manipulieren kann ich diese aber nirgendwo, sodass es einfluss auf bspw. die ThreadPage hat. Also müssen wir die Berechtigung so lassen.


    Was ist, wenn wir eine Berechtigung einfügen, welche heißt canOnlyReadOwnThreads. Von dieser machen wir es nun abhängig, ob er das besagte Thema aufrufen kann, sollte diese Berechtigung true sein und man sich in einem fremden Thema befindet, wird vom Plugin (!!!) eine PermissionDeniedException geworfen. Ist diese Berechtigung false, aber canReadThread == true kann man jedes Thema lesen


    Klingt kompliziert, scheint aber der einzigste weg zu sein.

  • Ich habe leider gar keine Ahnung vom Programieren, aber wirklich schön zu sehen dass sich hier einige den Kopf darüber zerbrechen und ich hoffe es kommt eine passable Lösung dabei raus. Danke auf jeden Fall schon mal für das "Brainstorming" und die Versuche! Ich bleibe gespannt dran...!

  • Also, das von Josh ist so auf jeden Fall umsetzbar... Kann das auch gerne machen, da der Aufwand nicht sehr groß ist, ABER:


    Meiner Ansicht nach ist die Lösung keine schöne. Auf Anhieb sehe ich zwei Gründe:

    • Das Plugin setzt etwas um, was sich der eigentlichen Rechtematrix des WCF entzieht. Heißt ein gewährtes Recht überschreibt ein verweigertes was in dem Plugin genau anders rum wäre. (Kann nur eigene Themen lesen überschreibt Kann alle Themen lesen) Das bringt uns auch schon zum zweiten Problem
    • Sobald der Benutzer in einer Gruppe ist, die das Recht Kann nur eigene Themen lesen hat (egal ob über die Gruppen Rechte direkt oder über das Forum selbst), kann er eben auch nur noch die eigenen Themen lesen, egal ob eine andere Gruppe etwas anderes sagt.
  • Also, das von Josh ist so auf jeden Fall umsetzbar... Kann das auch gerne machen, da der Aufwand nicht sehr groß ist, ABER:


    Meiner Ansicht nach ist die Lösung keine schöne. Auf Anhieb sehe ich zwei Gründe:

    • Das Plugin setzt etwas um, was sich der eigentlichen Rechtematrix des WCF entzieht. Heißt ein gewährtes Recht überschreibt ein verweigertes was in dem Plugin genau anders rum wäre. (Kann nur eigene Themen lesen überschreibt Kann alle Themen lesen) Das bringt uns auch schon zum zweiten Problem
    • Sobald der Benutzer in einer Gruppe ist, die das Recht Kann nur eigene Themen lesen hat (egal ob über die Gruppen Rechte direkt oder über das Forum selbst), kann er eben auch nur noch die eigenen Themen lesen, egal ob eine andere Gruppe etwas anderes sagt.

    OK, letzteres wäre natürlich problematisch. Hat jemand eine Idee wie man das lösen kann bzw. mal ganz naiv gefrafgt: Kann/würde Woltlab hier helfen? (...aber bitte nicht erst mit 4.2!) Ich glaube es ist ja durchaus deutlich geworden dass solch eine Funktion für viele Kunden sehr wichtig wäre.

  • Naja, das letzte Problem könnte man natürlich durch ein weiteres Recht lösen: "Kann alle Themen lesen, trotz der Einstellung "Kann nur eigene Themen lesen"".


    Ob das sinnvoll ist, wage ich aber mal zu bezweifeln.

  • könnte man natürlich durch ein weiteres Recht lösen

    Was ich mehr als unschön finde.


    Kann/würde Woltlab hier helfen?

    An der Stelle sind sie die einzigen die das können ;)


    Ich würde mir eh wünschen an viel mehr Stellen des WCF/WBB ohne weiteres eingreifen zu können. Leider können selbst Kunden nicht bei der Entwicklung des WBB mitwirken :(

  • Vielleicht müsste man einfach mal einen Vorschlag im entsprechenden Bereicht erstellen.


    Ein Event in Zeile 132 der ThreadPage würde ja, theoretisch, schon reichen, denn dann kann man das Thread-Objekt austauschen und dort dann die canRead()-Methode überschreiben.

  • Du kannst über die entsprechende API (ACL und userGroupOptions) weitere Berechtigungen hinzufügen.


    In diesem besonderen Fall geht es ja nur darum, die canRead()-Methode zu üeberschreiben, was nicht oft vorkommt, dass man das braucht.


    Die ThreadList solltest du aber bspw. ohne Probleme austauschen können, bevor die Objekte gelesen werden und alles andere auch (nur bei den Benachrichtigungen bin ich mir nicht sicher), aber ich glaube das haben @TimWolla und @Max mit ihrem Plugin Beiträge anonymisieren schon vorgemacht.

  • Ist ja alles schön dass sowas mit 4.2 kommen soll, leider wird WBB so immer unbrauchbarer wenn die wichtigsten Funktionen immer erst mit der x.2 Version kommen denn dann ist es kein weiter Weg mer bis WBB 5 und der Spuk fängt von vorne an. WBB ist ein gutes System, aber was nützt es mir wenn ich viel Geld für eine Version ausgebe, dann nochmal für die Updates draufzahle um es letztendlich erst Monate/Jahre später produktiv einsetzen zu können. Ich denke für die Jungs von Woltlab wäre das kein großer Aufwand das mit einem kleinen Patch einzubauen, oder eben wenigstens den Code so vorzubereiten dass die Community Coder was basteln können.


    Eben diese hier disskutierte ist eine kleine Funktion welche aber die Einsatzmöglichkeiten des WBB extrem steigern würde.

  • Ist ja alles schön dass sowas mit 4.2 kommen soll, leider wird WBB so immer unbrauchbarer wenn die wichtigsten Funktionen immer erst mit der x.2 Version kommen denn dann ist es kein weiter Weg mer bis WBB 5 und der Spuk fängt von vorne an. WBB ist ein gutes System, aber was nützt es mir wenn ich viel Geld für eine Version ausgebe, dann nochmal für die Updates draufzahle um es letztendlich erst Monate/Jahre später produktiv einsetzen zu können. Ich denke für die Jungs von Woltlab wäre das kein großer Aufwand das mit einem kleinen Patch einzubauen, oder eben wenigstens den Code so vorzubereiten dass die Community Coder was basteln können.



    Eben diese hier disskutierte ist eine kleine Funktion welche aber die Einsatzmöglichkeiten des WBB extrem steigern würde.

    Sehe ich genauso. @Alexander Ebert