QFQ

threadId¶

Überschneidet sich stark mit dem existierenden grIdGroupList. Dort werden die Nachrichten schon zusammen gruppiert und ausgegeben. Ich hab das Gefühl es erzielt das gleiche Resultat je nach Anwendung.

Es wird eine Gruppe erstellt für die Rueckfrage an den Antragsteller, ID = 60
Und eine Gruppe für Rueckfrage zum Vize-Dean, ID = 61

Die jeweilige Gruppe wird dem jeweiligen Chat im Formular über Parameter konifguriert.

Personen die zu der zweiten Gruppe gehören sollten (z.b. Dekanat, Vize-Decan) oder der ersten Gruppe (Dekanat) bekommen die GroupId als Property zugewiesen.

Im Falle von Rückfrage an den Antragsteller wird im Formular des Antragstellers einfach folgendes gesetzt:

grIdGroupList = 60
grIdCreatorGroupList = 60 #Um den Access aufzuheben kann einfach die gleiche ID wie bei grIdGroupList angegeben werden. Somit bleibt dieser parameter multifunktional.

Wird der Chat mit der konfigurierten Gruppe geöffnet, so wird zuerst geprüft ob die eingeloggte Person diese Gruppe als Property besitzt (grIdCreatorGroupList, wenn nicht: readonly und 'No access to chat'). Falls ja dann werden die Nachrichten mit der gleichen grIdGroupList angezeigt und es kann selbst eine Nachricht verfasst werden.

Die grIdThread führt nach meinem Verständnis zum gleichen Ergebnis, es werden mehrere Nachrichten zusammengeführt und so ausgegeben.

Mit grIdThread würde es so aussehen:

grIdThread = 60

Keine Gruppenbeschränkung, werden alle Chat Nachrichten mit dem gleichen grIdThread angezeigt.

grIdThread = 60
grIdGroupList = 60
grIdCreatorGroupList = {{SELECT GROUP_CONCAT(prop.xId) FROM Person AS p, Properties AS prop, Ggroup AS grPropertyCategory WHERE p.id = prop.pId AND prop.catId = grPropertyCategory.id AND grPropertyCategory.reference = 'mef_bef_misc_property_group' GROUP BY p.id}}

Mit Gruppenbeschränkung, falls nicht in Gruppe dann nichts anzeigen und Access vermeiden. Ansonsten alle Chat Nachrichten mit dem gleichen grIdThread anzeigen.

Die threadId wird vom ersten Chat record übernommen. Nach dem der aller erste Chat record gesetzt wird braucht es ein erneutes UPDATE statement um die threadId bei dieser anzupassen (unschön). Bei allen daruaffolgenden ist es kein Problem mehr.

Fazit:
-------
Als Resultat würde ich das ganze so anpassen dass die Parameter grIdGroupList und grIdCreatorGroupLIst nur für die Logik der Kontrolle des Access verwendet wird.

threadId wird nicht vom User selbst sondern automatisch durch die selektierten Chat Records gesetzt.
Die richtige Zuweisung an Gruppen erfolgt über grIdThread (Was ebenfalls Ggroups oder dergleichen sein werden)