WebsiteBaker Support (2.10.x) > Hilfe & Support (deutsch)

WB-Benutzer mit zeitlich begrenztem Zugang.

<< < (3/4) > >>

jacobi22:

--- Quote ---Alle Mitglieder einer Gruppe werden gleichzeitig aktiv oder passiv geschaltet, wenn die Zeitsteuerung das für die jeweilige Gruppe vorgibt.
--- End quote ---

wäre das, was mir persönlich daran nicht gefallen würde, dann habe ich entweder ganz viele Gruppen mit z.b. unterschiedlichen Zeiten und vielleicht nur einem User pro Gruppe oder ich schließe mit einem Schalter alle User dieser Gruppe aus, unabhängig davon, ob der User XY schon aktiv war oder nicht

Ich würde da schon zu einem neuen Feld raten in der users-Tabelle mit einem timestamp zum ablauf. Ist der gesetzt, wird verglichen, ist er nicht gesetzt, gibt es Zugang. Der Aufwand wäre wesentlich geringer. Aber ich brauch es nicht, von daher...

evaki:
Mit den Zeitgruppen wird es m.E. übersichlich, wenn man das ausschließlich für z.B. Gruppen wie Demo, Gäste oder Autoren (für zu erstellende Beiträge) anlegt. So zumindest war meine vorläufige Einschätzung, da ich auch die Vorstellung hatte, daß man das ja nicht jeden Tag macht.

Sind aber, bei Redaktionen eher häufiger, Autoren die Akteure, kann es wie m.E. "Jacobi" richtig feststellt, schnell unübersichtlich werden.

Ich dachte an Gruppen(namen) (z.B. Gastautoren, Sport am W.ende) wegen der Übersichtlichkeit, bei denen aber jeder Autor zeitlich geordneten Zugang erhält. Hab' auch erst jetzt -Tschuldigung-  mal in die DB geschaut, und das Feld users.active gesehen. Was hält einen davon ab es unabhängig von einer Gruppe zu aktivieren/deaktivieren -unabhängig vom Programmieraufwand? Sind Änderungen in der Benutzerverwältung in Planung/Arbeit, die dann so ein Tool in kürzester Zeit wieder unbrauchbar machen, oder auch u.a. Auswirkungen auf Abfrage und Beschreiben der DB haben, eben auch unter Admin-Tools (deshalb auch Schnittstelle?)?

Fragen über Fragen, wenn man sich als Laie im fremden Terrain bewegt.

MfG. Evaki

DarkViper:
Die Ergänzung auf User ist kein besonderes Problem..  nur 3 kleine Methoden mehr in der Schnittstelle.

App. Schnittstelle: Wir sind ja gerade dabei das ganze System zu 'entflechten'. Endlos viele Querverbindungen und Abhängigkeiten aufzulösen, damit das Ganze als solches wesentlich einfacher zu warten und ändern geht. Da wäre es mehr als kontraproduktiv, wenn wir jetzt wieder Zusätzliche Abhängigkeiten zwischen Module und Core einbauen würden. Deshalb eine Schnittstelle nach außen, die aus Sicht des Moduls immer gleich bleibt, ganz egal wie sich die 'Blackbox' namens Core verändert.
Andererseits kann das Modul auch alles was selbst benötigt in seiner/seinen eigenen Tabellen speichern, ohne auf Core-Tabellen etc. angewiesen zu sein.
Wie im PC auch...  ich hab eine Busschnittstelle und da kann ich beliebige Zusatzkarten einstöpseln...

jacobi22:
nur kurz zu eurer Aktiv-Schaltungs-Idee: users.active == 0 bedeutet (wie oben schon gesagt) - der User ist ist noch nicht freigeschalten (manuell oder Aktivierungsmail) oder eben nachträglich bewußt gesperrt, Gründe: egal. Es muß dem Bediener des möglichen AdminTools nicht unbedingt bekannt und auch nicht erkennbar sein, ob User XY nun bewußt gesperrt wurde oder ob grade seine zeitliche Berechtigung abgelaufen ist. Ihn dann ohne Nachkontrolle einfach so per Mausklick freizuschalten, kann eine Menge Ärger bringen. Wäre nichts, was ich reinen Gewissens empfehlen würde.

Auf meine Frage nach dem Sinn gab es keine richtige Antwort. Ich meine, zu verstehen, das es sich auch nicht um einmalige Freischaltungen handeln könnte, sondern eher so etwas wie der Eingabe im ProCalendar (z.b. immer Montags, Mittwoch und Freitags, 20.00 - 22.00 Uhr für die nächsten 8 Wochen). Damit wäre die Sache dann schon komplizierter und wäre nicht mehr so umsetzbar, wie ich mir das mit der eher einmaligen Freischaltung dachte. Man kommt aber so oder so nicht um den Core drum herum, egal, wie das Kind nachher heißt, Entflechtung, geheime Schnittstelle, Core-Hack- irgendwo muß ich ja in den Login-Prozeß eingreifen

evaki:
>>Auf meine Frage nach dem Sinn gab es keine richtige Antwort.
Naja, hängt davon ab was man halt unter "richtig" erwartet. Die Vorgeschichte ist so, daß die Gründe für solche an mich herangetragene Ansinnen recht unterschiedlich waren, und die mir nun tröpfelweise wieder einfallen. Ich persönlich würde es nur für meine Demos brauchen. Und, - es handelte sich bei diesem Thema bisher immer um einmalige anlaßbedingte Freischaltungen.

>> irgendwo muß ich ja in den Login-Prozeß eingreifen
Wenn nicht aktiv (DB), dann kommste nicht (mehr) rein.

>>nur kurz zu eurer Aktiv-Schaltungs-Idee: users.active == 0
Ich habs so verstanden, daß nicht nur wg. Übersichtlichkeit die Sache gruppenorientiert gestaltet werden soll(te), da auch nur diese Gruppen für das Admin-Tool erreichbar sind bzw sein sollen. Wie und wo die Rechte hierfür vergeben werden ist für mich noch offen. Per dieser neuen Schnittstelle, oder gibts da noch andere Möglichkeiten?

MfG. Evaki

Navigation

[0] Message Index

[#] Next page

[*] Previous page