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

WB-Benutzer mit zeitlich begrenztem Zugang.

<< < (2/4) > >>

evaki:
Alles soweit richtig.
Doch haben die Anwender bzw. der WB-Admin Zugang zum Servermanagement (hängt wohl vom Hoster und dem Paket ab), welches individuell beschränkt konfiguriert werden kann, also wie WB selbst. Liegt ein vorgefertigtes Formular (Script) vor, das kriegt der "Server-Admin" noch hin, auch mal schnell die DB-Einträge (mit eindeutiger Bezeichnung z.B. der Gruppe) zu wechseln, womit es dann auch leicht für den WB-Admin zu nutzen ist.
Größere Bedenken kommen immer dann, wenns an den Core ran soll. Deshalb wahrscheinlich eher dieser Weg. Auch wenn Du ganz richtig liegst mit "bis ich das Script angepasst habe, habe ich per Backend drei Accounts eingerichtet und gelöscht." Dazu würde ich, wenns für mich persönlich wäre, auch neigen.
MfG. Evaki

Edit: @jacobi22: Hast mich aber soeben auf 'ne Idee gebracht. muß ich aber erstmal drüber nachdenken, obs nicht wieder was beklopptes ist. (Admin Tool)

Gast:
AdminTool war auch mein erster Gedanke, wenn da der Login nicht wäre. Mit dem AdminTool (ggf UserExtent etc aufbohren bzw erweitern) kann ich mit und ohne aktuelle Corefunktionen die Maske zum Anlegen, Einstellen und Löschen solcher Usergroups bereit stellen, inkl. Anlegen der DB-Felder, aber spätestens beim Login muß ich dann an der Core ran.
Schade, das Entwickler für die einfachen User keine Zeit mehr haben, um mal eine grundsätzliche Auskunft zu geben, ob so etwas in Planung ist oder nicht. Vom Programmieraufwand würde ich sagen, viel länger als eine Stunde dauert es nicht.

evaki:
Jepp, beim jetzigen späten Frühstück kam ich auch auf das Problem mit'm Login.
Aber auch die Frage nach der Methode der Deaktivierung stellte sich mir neu, zumindest wenn man zeitlich begrenzten und evtl wiederholten Zugang möchte, statt einfach nur zu löschen. Neue Tabelle fürs Tool und entsprechende Einträge tauschen (so mit Dummy un so) war der erste Gedanke. Aber da kommen bestimmt gescheitere Gedanken von Deiner und anderer Seite, zumals auch nur 'ne Assoziation war/ist.
Tja, und mit "viel länger als eine Stunde dauert es nicht." geht bei mir bekannterweise schon gar nicht, auch wenn mich das nicht davon abgehalten hat, mal ein oder zwei Module hinzubekommen.  :-) 
Bei meinen Fähigkeiten geh' ich möglicherweise beim 10ten in Rente  :-D
MfG. Evaki

Gast:
sag mal, was da für Hintergründe oder Notwendigkeiten bestehen.
Möchte man eine Online-Demo? (die gäbe es ja im Web)

DarkViper:
Oooch die Entwickler lesen schon mit... und machen sich gelegentlich sogar auch Gedanken über die Probleme der "kleinen User".  ;)

Die verschiedenen Ideen zu Einbindung solch einer Lösung hören sich im ersten Moment vielleicht einfach und verlockend an. Wenn man dann aber mal über alle möglichen Nebenwirkungen nachdenkt, kommt man recht schnell ins Grübeln.

Erst mal die größte Hürde:  Allgemeine Regeln für Addons (die schon seit mehreren Jahren so geschrieben steht).
Somit scheidet eine Lösung, die den Core verändert oder direkt schreibend auf seine Daten zugreift, schon mal aus.
Selbstverständlich kann jeder mit seiner Installation machen, was immer er/sie/es will. Da spricht absolut nichts dagegen. Kritisch wird es erst, wenn diese Lösungen weitergegeben werden.
Speziell zur Zeit, da wir laufend sehr viel im Core ändern. Unter anderem auch an der Datenbank. Da ist nie sichergestellt, dass eine 'invasive' Lösung von heute auch morgen noch funktioniert und nicht gar das ganze System zum Absturz bringt (Zeitangaben bitte wörtlich nehmen).

Ok, das waren erst mal die 'Bedenken'.  (N)
Jetzt aber auch ein wenig Erfreulicheres:  (Y)
Selbstverständlich ist eine Lösung des Problems möglich. Sogar noch weitreichender als bisher angedacht. Man braucht nur vorhandenes mit etwas Neuem sinnvoll zu kombinieren, dann klappt das problemlos(naja, fast). ;-)

Frage: Was ist im aktuellen WB eigentlich notwendig, um für einen User das Login zu unterbinden?
Antwort:  es muss nur ein einziges Bit in der Datenbank verändert werden. Das Feld  users.active muss von 1 auf 0 oder umgekehrt gedreht werden und schon ist es mit dem Login vorbei.
Bedingung: falls das `active` bereits auf 0 war, darf es auf keinen Fall verändert werden! (das ist der Fall, falls ein User gesperrt ist oder noch nicht freigegeben etc..)

Eine Lösungsidee:
Die Zeitsteuerung läuft grundsätzlich Gruppenorientiert. Dies Gruppen werden in der normalen Gruppenverwaltung angelegt. Der Gruppe muss nur zusätzlich das Recht an dem Tool "NameDesZeitTools" gegeben werden.
Es sind beliebig viele 'Zeitgruppen' möglich
Die user können ganz normal über die Userverwaltung den Gruppen zugewiesen werden.
Alle Mitglieder einer Gruppe werden gleichzeitig aktiv oder passiv geschaltet, wenn die Zeitsteuerung das für die jeweilige Gruppe vorgibt.
Die Zeitsteuerung wird als eigenständiges Admin-Tool angelegt, welches auch einen direkten Aufruf zum Triggern der Zeitsteuerung zur Verfügung stellt. Die Ansteuerung kann z.B. so alle 12 Std. durch einen externen Cron-Job-Server (gibts im Netz auch kostenlos als Service) erfolgen. WB selbst hat derzeit etwas derartiges noch nicht eingebaut.

Die Verbindung zum Core (users+groups-Tabelle etc.) erfolgt über eine kleine Schnittstelle, die wir zur kurzfristig Verfügung stellen können und bei bedarf auch aktualisieren.
So kann sichergestellt werden, dass Änderungen am Core etc. an dem Zeit-Tool unbemerkt vorbeigehen. Auch sonstige Upgrades/Updates hätten keine Auswirkung. Das Tool braucht sich auch um kein Login und nichts zu scheren.

Kurzfassung der Schnittstellenmetho den:
array getGroupsList() // liefert alle Gruppen die das Recht zur Zeitsteuerung haben [group_id=>n, name=>xyz]

bool  enableGroup(int $iGroupId)  // aktiviert die angegebene Gruppe
bool  disableGroup(int $iGroupId)  // deaktiviert die angegebene Gruppe

mehr ist nicht notwendig.  Wann welche Gruppe unter welchen Bedingungen ein-/ausgeschaltet wird, ist jetzt einzig nur noch Aufgabe des Tools. Das kann dann alles ohne irgendwelche Eingriffe in den Core erfolgen.

Falls sich also jemand an dem Teil versuchen will...  sollte ich es bald wissen, sonst schafft es die Schnittstelle nicht mehr in das nächste Release, das gerade vorbereitet wird.

have a nice Day...
Manuela

Navigation

[0] Message Index

[#] Next page

[*] Previous page