[TYPO3-german] Paid Membership Extension

[bernd wilke]

Am Mon, 06 Jul 2009 15:42:54 +0200 schrieb JoH asenau:

>> Problem: Das ganze kann so nicht im BE gepflegt werden, da das BE zwar
>> mn- Beziehungen mit eigenen Datensätzen unterstützt, aber keine
>> Zusatzinformation in diesen Datensätzen.
> 
> Seit wann?
> 
> IRRE macht da etwas ziemlich gut vor, was aber auch schon vor IRRE
> möglich war:
> Eine MM-Tabelle kann mit weitaus mehr Feldern bestückt werden, als man
> für die reine Verknüpfung benötigen würde und - und das ist das
> eigentlich Wichtige für die Zusatzinformationen - man kann sie genauso
> mit einem TCA versehen und editierbar machen wie "normale" Tabellen.
> 
> Wenn Du also in Deiner Tabelle die üblichen "enable fields" einbaust,
> kannst Du auch für eine MM Relation mit "Start/Stop" etc. arbeiten. Was
> Du daraus im Frontend machst, liegt ja sowieso beim PHP Code des
> jeweiligen Plugins. Sollte also kein Akt sein, damit eine befristete
> Aktivierung hinzubekommen.

das macht mich jetzt neugierig. kannst du das näher erläutern?

mal zum verständnis:
aktuell werden die Usergruppen (genauer deren uid) in einer 
kommaseparierten Liste im User-Datensatz gespeichert.

also zwei Tabellen:
user (felder: uid, pid, ... ,usergroups, ...)
usergroup (felder: uid, pid, ...)

hier bräuchte man erstmal zeitlich steuerbare usergroups. ist das 
machbar? selbst wenn die entsprechenden Felder existieren müssten auch 
die Corefunktionen zum Auswerten enable_fields() auf die usergroups 
machen.
die usergroups können dann zwar zeitlich gesteuert werden, das würde aber 
für alle user gelten und direkte Benutzer-individuelle usergroups sind 
nicht mehr vernünftig realisierbar indem man alle möglichen Inhalte für 
alle entsprechenden Gruppen erlaubt. [1]

bei mn-relationen gibt es drei Tabellen:

user (felder: uid, pid, ...)
usergroup (felder: uid, pid, ...)
user_mn_usergroup (felder: user-uid, usergroup-id)

daraus wird (soweit ich es weiß) beim handling ein join gemacht in dem 
nur die uid-felder des Relationen-Datensatzes in einer fixierten Art 
benutzt werden.

für eine zeitliche Begrenzung müssten jetzt start- und stop-felder in 
user_mn_usergroup existieren und auch überprüft werden.

in einem eigenen FE-Plugin kann ich natürlich alles selber abfragen.
d.h. aber dass ich den 'normalen' Gebrauch der access-Felder überall 
selber realiseren müsste.
Mein Idee wäre: sobald der user identifiziert und seine Daten geladen 
werden (das passiert ja bei jedem Seitenaufruf) klinkt sich eine Funktion 
(xclass?) ein und 'korrigiert' das usergroups-feld um die aktuell aktiven 
zugeordneten usergroups (enable_fields auf user_mn_usergroup)

aber wie wird das im BE gepflegt?
statt der selectbox  die ja nur 'enthalten' oder 'nicht enthalten' 
verwalten kann. muss jetzt für jede Verbindung auch eine zeitliche 
Begrenzung (Start- und Stop-Datum) pflegbar sein. 

kommt da dann IRRE?
so weit ich das verstehe wären das dann aber nicht mehr echte mn-
Datensätze, sondern unabhängige Datensätze, die vier Felder haben (die 
user-id entfällt zwar, dafür hat dieser mn-Datensatz aber eine uid, die 
beim user in ein neues Feld eingetragen wird. Dazu dann start und stop 
und (als selectbox) eine usergroup. damit müsste es dann realisierbar 
sein.
Da diese Datensätze nur in der (service?)-Funktion beim Laden des 
Userdatensatzes angefasst werden kann es eigentlich auch egal sein ob es 
echte mn-Datensätze sind oder eigenständige Datensätze, die 'zufällig' 
mit den Tabellen fe_user und fe_groups verbunden sind.

jetzt brauchen wir nur noch jemanden, der diese xclass-funktion als 
Extension bastelt. wer kennt sich da aus? ;-) 



[1] d.h. mit den kaskadierbaren usergroups wäre das eigentlich schon 
möglich.
man müsste nur passende usergruppen anlegen.

z.B.:
user1, user2, user3, ...
gruppe1, gruppe2, gruppe3, ...

um jetzt user2 zeitlich befristet in gruppe3 aufzunehmen müsste man einen 
Hilfsgruppe user2_gruppe3 anlegen, die zeitliche Befristung hat, die als 
Untergruppe gruppe3 enthält  und in der user2 eingetragen ist. Solange 
die Gruppe user2_gruppe3 aktiv ist gehört user2 auch zu gruppe3.

die eigentlichen Gruppen sind vermutlich nicht so viele, aber es können 
ja tausende von usern sein. Das würde sehr viele Hilfsgruppen 
erforderlich machen, was zumindest für die Pflege im BE ziemlich 
kompliziert werden kann. Vor allem weil diese Hilfsgruppen ja alle in der 
Tabelle mit den echten Gruppen untergebracht werden müssen. Da 
funktioniert dann auch die Selectbox für Usergruppen nicht mehr.



bernd
-- 
http://www.pi-phi.de/t3v4/cheatsheet.html