Gelesen-Markierung pro Benutzer abfragen - Wie geht das?

  • Moin,


    wie lautet die Syntax um die Gelesen-Markierung pro Benutzer abzufragen. Konkret: Ich möchte per Regel abfragen, ob eine Element von allen Benutzern gelesen wurde. Ist das der Fall, dann soll das Element erledigt werden. Derzeit kann man in dem Reglesystem jedoch mit den Standardmitteln nur abfragen, ob das Element generell eine Gelesen-Markierung enthält.


    Lieben Gruß

  • Hallo,


    über folgenden Code kann man Fragen, ob ein bestimmter Benutzer das Element gelesen hat:


    Code
    1. if Item.ReadUsers.IndexOf(<Benutzer-ID>) >= 0 then


    Man könnte den Codeblock in eine Quelltext Bedingung einfügen, dann kann man den Experten weiterverwenden.


    Wenn man die Benutzer-ID nicht kennt, kann man diese so ermitteln:


    Code
    1. Item.UserCache.GetIDByUsername('og')


    Der Code könnte für <Benutzer-ID> eingefügt werden.


    Wenn man dynamisch prüfen möchte, ob zum Beispiel alle aktiven Benutzer das Element gelesen haben, muss man etwas mehr tun:



    Ich habe mal eine GREYHOUND Regel angehangen, welche demonstriert, wie man soetwas mithilfe des Experten umsetzt. So hat man später die Möglichkeit komfortabel Gruppen zu setzen oder auch andere Regelknoten zu verwenden.

  • Hallo Oliver,


    besten dank für das Skript. Habe daraus schon wieder einiges gelernt.


    Bei der Umsetzung ist mir nun jedoch aufgefallen, dass es so noch nicht praktikabel ist. Das Problem besteht darin, dass eine Notiz in vielen Szenarien niemals von allen als gelesen markiert werden kann, da z.B. einigen Benutzen die nötigen Rechte fehlen. Erstelle ich eine Notiz für die BuHa, dann können nur ich und zwei weitere Kollegen diese Notiz überhaupt lesen. Da die anderen nicht drankommen, wird die Notiz niemals von der Regel als erledigt markiert.


    Wenn man die Möglichkeit hätte dynamisch abzufragen, wer überhaupt die Rechte besitzt dieses Element zu lesen, und das dann mit der Liste der ReadUsers gegenprüfen könnte, das wäre prima.


    Das bedeutet im Klartext: Wenn von allen Benutzern gelesen die dieses Element lesen können, dann.....


    :?:


    Lieben Gruß

  • Hallo,


    machbar ist das. Dazu gibt es Item.GroupCache. Man kann das Skript so erweitern:


  • Hi Oliver,
    ich bekomm es nicht hin. Hier die Regel wie ich sie jetzt angelegt habe:


    Wenn ich die Regel manuell auf die Notiz anwende, dann passiert mit der Notiz, die von beiden Geschäftsführern gelesen wurde, nix. (Die beiden GF sind die einzigen die Zugriff auf die Gruppe haben in der sich die Notiz befindet.)
    Wende ich die Regel auf den Filter an der mir die Notiz anzeigt ("interne Notizen"), dann bekomme ich eine Fehlermeldung wie folgt:

    Wenn ich an deinem Sourcecode rummache, dann ist das aber auch mehr Trial and error. Meine Pascal-Kenntnisse sind einfach seit meiner letzten Informatik-Stunde irgendwie wie weggeblasen. Wie kommts nur? Muss an meinem Alter liegen...


    Kannst du helfen?


    Ach noch was: Gibt es eine andere Möglichkeit als die. o.g. Regel zeitgesteuert laufen zu lassen? Der Nachteil daran ist ja, dass die Notizen dann nur einmal am Tag "aufgeräumt" werden. Lieber wäre mir so etwas nie "nach dem Bearbeiten", nur das eben das Angucken kein Bearbeiten ist.


    Lieben Gruß

  • Nachtrag:


    Das Logfile gibt etwas mehr zu dem o.g. Fehler her:


    0001C;2010-03-08 20:05:02,795;SQL-Error: Failed to execute SQL-Query: Duplicate entry '59-56-manual' for key 'unique'.
    0001C;2010-03-08 20:05:02,795; i_rule_r = 59;
    0001C;2010-03-08 20:05:02,795; i_filter_r = 56,
    0001C;2010-03-08 20:05:02,795; e_trigger = 1,
    0001C;2010-03-08 20:05:02,795; e_state = 2,
    0001C;2010-03-08 20:05:02,795;insert into filters_workflow set
    00018;2010-03-08 20:05:02,795;User "C19C62CD64C8E9566DE027B9191EF411-slammers": Failed to execute SQL-Query: Duplicate entry '59-56-manual' for key 'unique'.


    Lieben Gruß

  • Hallo,


    das mit dem duplicate Key ist garnicht gut. Wurde die Regel schon abgearbeitet, nachdem du sie manuell auf das Element angewendet hast (Queuestatus schauen)? Ich habe das Problem schonmal in den internen Bug-Tracker aufgenommen, benötige aber noch weitere Infos von dir. Eventuell kannst du das Problem nochmal reproduzieren?


    Die Regel ansich habe ich hier ehrlich gesagt nicht ausprobiert. Ich habe Sie einfach "from scratch" ins Forum getippt. Eventuell könntest du dir dort, wo "ReadByAll" auf False gesetzt wird, den aktuellen Benutzer, welcher das nicht gelesen hat mal ins Systemprotokoll schreiben. Dazu gibts auch einen fertigen Regelknoten, wo du dir den nötigen Quelltext dafür holen kannst.


    An den Benutzernamen kommst du über:


    Code
    1. Item.UserCache.GetUsernameById(<Benutzer-ID>)


    Viel Erfolg! :)

  • Was mich wundert ist die Uhrzeit. Gestern um Punkt 20:00 Uhr ging es los, also genau zu dem Zeitpunkt als die beiden Regeln "Papierkorb automatisch leeren" (so ziemlich die Regel die du auch hier in der Filebase hinterlegt hast) und "Spam automatisch löschen" zeitgesteuert loslegen sollten (und es auch getan haben). Die Regel "Spam automatisch löschen" ist übrigens eine Kopie der Papierkorb-Regel. Vielleicht gab es hier durch das Kopieren der Mail in Verbindung mit irgend einer Einstellung ein Problem? Ich hab auf jeden Fall das Gefühl das es damit etwas zu tun haben könnte.


    Kann ich die IDs der Regeln irgendwie rausbekommen?


    So aus dem Gedächtnis versuche ich mal die Erstellung der beiden o.g. Mails rekonstruieren:


    Die Papierkorb-Regel hier runtergeladen und in den GH importiert. Den Trigger auf Manuell und Zeitgesteuert gestellt oder kontrolliert. Den Filter "Papierkorb" im Filter-Tab ausgewählt (ich meine ich hätte ne Meldung "kein Filter gewählt" beim 1. Versuch des Speicherns gesehen...). Die Uhrzeit im Serienoptionen-Tab auf 20:00 Uhr Start und 00:00 Uhr Ende gewählt (warum eigentlich?). Die Seriendauer auf "Kein Enddatum" gesetzt.


    Dann das Ding gespeichert, dupliziert und im Expertenmodus wie folgt abgeändert:

    Wieder den Filter gesetzt auf den Filter "Spam-geprüft" (gleicher Filter wie von Hildebrand in diesem Forum empfohlen).


    Das war es, zumindest was die beiden o.g. Regeln angeht.


    Ich habe jetzt mal die Spam-Regel deaktiviert. Mal sehen was gleich um 20:00 Uhr passiert.

    Wurde die Regel schon abgearbeitet, nachdem du sie manuell auf das Element angewendet hast (Queuestatus schauen)?

    Keine Ahnung. Gefühlt schon, aber in die Queue habe ich nicht geschaut. (Da kam ich ja erst 40 Minuten später drauf, als sich auch bei simplen Test gar keine Regel mehr rührte. Wer weiß was zwischendurch alles passiert ist).

    Eventuell kannst du das Problem nochmal reproduzieren?

    Ich bin dran. (s.o.)

    Die Regel ansich habe ich hier ehrlich gesagt nicht ausprobiert. Ich habe Sie einfach "from scratch" ins Forum getippt. Eventuell könntest du dir dort, wo "ReadByAll" auf False gesetzt wird, den aktuellen Benutzer, welcher das nicht gelesen hat mal ins Systemprotokoll schreiben. Dazu gibts auch einen fertigen Regelknoten, wo du dir den nötigen Quelltext dafür holen kannst.

    Ich probier es mal. Melde mich.


    Lieben Gruß

  • nabend Oliver,


    also jetzt läuft alles irgendwie.


    Die Papierkorb-Regel legte punkt 20 Uhr los, während ich wie gebannt die Queue mit sekündlicher Aktualisierung mit mangels Blinzeln tränenden Augen beobachtete. Kurz ein paar Hundert wartende Aktionen bei der Regelausführung aufblitzen sehen, dann eine handvoll Elemente bei der Löschung aus der Indizierung beobachtet, das wars auch schon.


    Hab dan direkt die Spam-Regel für 2 Minuten später aktiviert. Da gab es aber wohl nix zu tun. Zumindest konnte ich nix sehen. Logfile ist ebenfalls sauber.


    Hab mich dann nochmal an die Notizen-Gelesen-Regel begeben. Die funktioniert jetzt auch (abgesehen von dem Benutzernamen in das Protokoll schreiben. Da erscheint zwar was, aber nicht der richtige Benutzer. Ich nehme an ich habe da aber nicht die richtige BenutzerID drin, weil ich nicht verstanden habe was du wolltest. Sollte in das Protokoll der Benutzer rein der noch nicht das Element gelesen hat?) Hier der aktuelle Code:


    Ich gehe davon aus, dass ich gestern mit der Regel keinen Erfolg hatte weil die Queue schon hing, und dass diese von Anfang an richtig war.


    Um dann zum ursprünglichen Thema zurück zu kommen und meine Super-Notizen-als-Gelesen-Regel zu Ende zu bringen:

    • Ich fänd es schön wenn man im Protokoll sehen könnte welcher Benutzer etwas noch nicht gelesen hat, am besten kommasepariert. Oder spricht da was gegen?
    • Nochmal die Frage von oben: Gibt es eine andere Möglichkeit als die. o.g. Regel zeitgesteuert laufen zu lassen? Der Nachteil daran ist ja, dass die Notizen dann nur einmal am Tag "aufgeräumt" werden. Lieber wäre mir so etwas nie "nach dem Bearbeiten", nur das eben das Angucken kein Bearbeiten ist.

    Wenn ich noch weiter forschen soll dann gib Bescheid. Und falls ich mir Sorgen machen sollte wegen des duplicate Keys dann sag mir auch Bescheid! Ach weiste was - sag mir auch Bescheid wenn ich mir keine Sorgen machen muss :)


    Ich werd dann jetzt mal nach Hause...


    Lieben Gruß

  • Hallo,


    das mit dem Regeltrigger beim ansehen ist so ein Problem. Ich glaube es ist auch etwas merkwürdig, wenn einem das Ding im selben Moment unterm hintern weggezogen wird... Man klickt drauf, ist am lesen, plötzlich wirds rot man drückt F5 und weg ist es. :)


    An dem duplicate key Problem haben wir schon was verbessert. Ganz sicher, ob es daran liegt/lag sind wir uns aber noch nicht. Auf jedenfall ist es jetzt noch ne kleine Spur besser. Mal schauen, ob das Problem nach dem nächsten Release auch noch auftritt. Dauert übrigens noch nen bissl, bis das kommt. Wir haben da doch allerhand zu testen.


    Im Protokoll die Benutzer einzutragen, welche das Element noch nicht gelesen haben, wäre Prinzipiell möglich. Man könnte auch ein benutzerdefiniertes Feld nehmen, dann hat man am Ende nicht 20 Einträge dazu im Protokoll, sondern immer nur den letzten Stand. Man dürfte dazu die Schleife, die prüft, ob es irgendjemand noch nicht gelesen hat, nicht sofort verlassen. Man könnte sich hier die Namen in einem String erstmal merken und dann zum Schluss in das benutzerdefinierte Feld schreiben.


    Auf jedenfall ne interessante Idee. :) Ich bin grade allerdings noch nen bissl eingespannt. Wenn du dich Freitag noch mal meldest, schaue ich mal, was man da so basteln kann.

  • Ich melde mich einfach heute schon mal, und du kannst ja morgen erst antworten :-)


    Mir geht es bei dem Trigger "gelesen" auch gar nicht darum diesen für das Erledigen einzusetzen. Da stimmte ich dir zu das es keinen Sinn macht. Aber ich könnte mir andere Spannende Dinge damit vorstellen. Um bei einem Beispiel mit den Notizen zu bleiben: Ich überlege eine Kennzeichnung "von allen gelesen" zu setzen. Dann kann derjenige der das Ding als letzter gelesen hat entscheiden ob es erledigt ist. Oder man triggernt damit eine Regel die eine Notiz zeitverzögert erledigt, damit sie einem eben nicht unterm "Hintern" weggezogen wird oder, oder, oder :-)


    Lieben Gruß

  • Hallo,


    würde es denn nicht reichen, wenn das aufräumen einfach einmal in der Nacht stattfindet? So schlimm es ist ja eigentlich auch nicht, wenn von 3 gleichzeitigen Unternehmensmitteilungen eine schon von allen gelesen wurde und deshalb noch nen paar Stunden zu sehen ist.


    Beim lesen findet in dem Sinne auch keine Bearbeitung statt (das Bearbeitet Datum wird ja auch nicht geändert).


    Wenn du mir deine jetzige Regel mal hier mit dran packst, dann kann ich ja mal die Ergänzung für das Benutzerdefinierte Feld dazu bauen. Interessiert mich ja auch brennend, wie gut das funktioniert. :)

  • Hi Oliver,


    anbei meine aktuelle Version. Irgendwie kann der GH aber mit meiner Syntax nix anfangen. Keine Ahnung warum. Vielleicht kannst du da ja mal Hand anlegen?


    Gedacht ist das ganze zumindest fürs erste als Zeitgesteuerte Regel, angewendet auf einen Filter "interne Notizen". In meiner Vorstellung ist das ein Ersatz für PostIts (für mich = kleine, hilfreiche aber nicht lebenswichtige Infos), nicht jedoch als Platz für z.B. Aufgaben! So habe ich es jetzt zumindest meinen Kollegen erklärt.


    Da die Regel zwischen "ohne Bearbeiter " und "mit Bearbeiter" unterscheidet, wäre dieser Vorschlag noch einmal zu prüfen.


    Ich denke man könnte damit die internen E-Mails zumindest etwas eindämmen. Im nächsten Schritt wollte ich versuchen über diese Notizen vieleicht auch das "zur Kenntnisnahme"-Problem anzugehen. Das geht mit der Erinnerungs-Lösung nämlich nicht wirklich gut. Wie vorhergesagt nimmt die Erinnerungen fast schon niemand mehr ernst.


    Lieben Gruß


    interne Notizen automatisch erledigen (beta).txt

  • Hallo,


    habe mal die Geschichte mit den Benutzern ergänzt, welche das ganze noch nicht gelesen haben.


    Du brauchst noch ein Benutzerdefiniertes Feld mit dem Namen "BenutzerUngelesen". Beschreibung kannst du vergeben wie du willst.


    Was in dem anderen Abzweigungsbaum genau geschehen soll, ist mir aber nicht so ganz klar. Wenn sich jemand Wochenlang nicht einloggt, dann so tun als ob gelesen? :)

  • Was in dem anderen Abzweigungsbaum genau geschehen soll, ist mir aber nicht so ganz klar. Wenn sich jemand Wochenlang nicht einloggt, dann so tun als ob gelesen?

    Ja, genau. Wir haben z.B. einen Buchhalter der sich nur ein mal im Monat anmeldet, der aber auch auf die für alle zugreifbare Gruppe "Verwaltung" zugreifen darf/soll. Die ganzen Notizen würden also dort rumliegen bis er sich einmal einloggt und alle gelesen hat. Die Wahrscheinlichkeit das eine allgemeine Notiz (also ohne Bearbeiter) nach einem Monat noch relevant ist ist sehr unwahrscheinlich. Außerdem müsste er alle Notizen auf gelesen setzen, was zusätzlichen Aufwand bedeutet. Das gleiche gilt wenn ein Kollege im Urlaub ist.


    Das andere ist ein Spezialfall. Ich habe z.B. jetzt schon einen Benutzer für Ingo angelegt, aber er hat sich noch nie eingeloggt, weil er derzeit keine Zeit hat mir die ganzen tollen Sachen zu programmieren die ich haben will ;) Daher diese zusätzliche Abfrage nach dem "überhaupt schon mal online gewesen?". In unserem Fall kann ich natürlich einfach den Benutzer löschen und dann anlegen wenn er sich das erste mal anmelden will, aber ich will das Ganze ja so stricken das die anderen hier das nachher auch nutzen könnten. Und in einem großen Unternehmen vergehen sicher schon mal einige Tage oder Wochen bis ein neuer Benutzer sich das erste Mal anmeldet. Das soll dann nicht alles blockieren. Macht ja auch nicht sooo viel Arbeit, oder?


    Ich guck mir deine Regel jetzt mal an


    Lieben Gruß

  • weil: Godmode = on


    Ich habe mal die Foreneinstellung angepasst.


    Bisher gibt es übrigens leider keine Möglichkeit an das letzte Logindatum eines Benutzers zu kommen. Die Info hat der Cache bisher nicht, weil sie für ihn nicht relevant ist.


    Ich denke es gibt da sinnvollere Möglichkeiten: Benutzern aus der Buchhaltung dürften diese internen Mitteilungen ja ohnehin egal sein, d.h. sie bekommen keinen Zugang für die Gruppe. Benutzer wie Ingo könnte man erstmal auf deaktiviert setzen. Somit sind sie schonmal raus. Wenn ein Mitarbeiter das Unternehmen verlässt, würde man ihn ja auch deaktivieren, weil man ansonsten sämtliche Zusammenhänge verliert (Systemprotokoll, Anmerkungen, wer hat was bearbeitet, etc.).


    Ich denke das sinnvollere Datum wäre hier der letzte Systemprotokoll-Eintrag / das bearbeitet Datum des Elements. Wenn das Element zum Beispiel schon 3 Tage offen rumliegt, dann erledige es trotzdem, auch wenn es ein Benutzer noch nicht erledigt hat. Man könnte dann z.B. auf Wunsch für diese Benutzer noch eine Erinnerung setzen, so dass sie das Element zumindest auf diesem Wege noch sehen können. Für alle anderen wäre es dann raus.


    Der Unterschied zwischen letzter Systemprotokoll-Eintrag und Bearbeitet am wäre hier, dass auch die geänderte gelesen-Markierung im Systemprotokoll vermerkt wird. D.h. erst wenn es 3 Tage garnichts mehr mit dem Element passiert ist, dann erledigen.

  • Ich glaube wir kommen einer praktikablen Lösung immer näher :-)

    Benutzern aus der Buchhaltung dürften diese internen Mitteilungen ja ohnehin egal sein, d.h. sie bekommen keinen Zugang für die Gruppe.


    Das ist bei uns kleiner Firma nicht so stringent durchzusetzen. Wir haben ja beispielsweise so gut wie alle unsere Kontakte der Gruppe "Verwaltung" zugeordnet. Nicht zuletzt deswegen soll der Buchhalter in diese Gruppe schon rein gucken dürfen.


    Benutzer wie Ingo könnte man erstmal auf deaktiviert setzen. Somit sind sie schonmal raus. Wenn ein Mitarbeiter das Unternehmen verlässt, würde man ihn ja auch deaktivieren, weil man ansonsten sämtliche Zusammenhänge verliert (Systemprotokoll, Anmerkungen, wer hat was bearbeitet, etc.).


    Yep, du hast Recht. Das macht Sinn.


    Ich denke das sinnvollere Datum wäre hier der letzte Systemprotokoll-Eintrag / das bearbeitet Datum des Elements. Wenn das Element zum Beispiel schon 3 Tage offen rumliegt, dann erledige es trotzdem, auch wenn es ein Benutzer noch nicht erledigt hat.


    Auch das finde ich einen guten Ansatz. Praktikabel ist dabei m.E. jedoch nur das Änderungsdatum des Protokolls.
    Ich habe den entsprechenden Regelknoten jetzt mal eingebaut.


    Mal sehen wie das jetzt so läuft.


    Lieben Gruß