LBS19000649 - EDOMI LBS Notification

[starwarsfan]

Hallo miteinander

Wie zuvor schon mal geschrieben, setzt das voraus, dass die Version gepflegt wird

OK, verstehe. Also ich hätte da keine Schmerzen dabei, dieses Feld auf geeignete Art und Weise zu forcieren. Also bspw. ein numerisches Pflichtfeld daraus zu machen. Wenn dann die Entwickler einen neuen Baustein hochladen, muss die Version geändert werden. Dabei sollte aber eine einfache Änderung der aktuellen Versionsangabe ausreichend sein, damit ggf. auch ein Downgrade ermöglicht wird, wenn sich eine neue Version als fehlerhaft erweist und die vorherige Version wieder im Downloadportal zur Verfügung stehen soll.

Wegen des "update-triggers" habe ich noch mal nachgelegt. Das last_update eines Bausteins wird nur noch geändert, wenn:

• Freigabe erteilt oder gesperrt wird
• Modultext sich ändert
• Version sich ändert
• sich zusätzliche Dateien ändern

Super, vielen Dank!

Wie Alfred geschrieben hat, in edomi habe ich keine Version zum Vergleich. Erst wenn die Version ein offizielles Attribut eines LBS ist und in der edomi DB ist, kann man das auswerten. Im Moment ist Version im Php Code komplett dem Entwickler überlassen und hat nichts mit der Version im DL Portal zu tun. Wenn die Version im LBS ein Pflicht Attribut wäre und beim Hochladen ins Verwaltungsportal automatisch übernommen werden würde, dann wäre das möglich. Aber dann sollte es vielleicht eine Funktion von edomi sein und nicht ein LBS.

Stimmt, da bin ich ganz bei Dir. Sollte man ggf. mit gaert abstimmen, ob es Sinn machen würde, ein entsprechendes Attribut bei den Community-LBS einzuführen.

[AScherff]

Falls das Thema Versionierung weiter verfolgt wird, sollte man ein Konzept haben/machen. Momentan wird in der Datenbank nur der aktuelle LBS geführt. Es gibt keine Versionen. Somit ist auch ein downgrade nicht möglich. Versionen sind aktuell "kunterbunt" von 0.1, 0.1alpha, 0.1beta bis 0.1.2

In einer der letzten Rev. habe ich alle Zeichen ausser 0-9 und . (Punkt) verbannt.

Ich persönlich bin für eine 3stellige Versionsnummer mit Revision 1.0.0 (Rev. 48) . Wobei, da kein Versionierungstool eingesetzt wird, man wohl auf die Rev. verzichten sollte.

Weiter muss man überlegen, welche "Version" im Downloadbereich vorgehalten wird und wie man ggf. an frühere Versionen kommt. Sowie: wann? und wo? speichere ich ältere Versionen und woran erkenne ich das zweifelsfrei.

[starwarsfan]

Falls das Thema Versionierung weiter verfolgt wird, sollte man ein Konzept haben/machen.

FullAck. Erstmal abwarten, was gaert dazu schreibt.

[Winni]

Hallo jonofe ,

wäre es möglich einen Ausgang zu spendieren, der A2 und A3 zusammenfasst und eine Spalte mit einen Flag enthält, was neu bzw. geändert ist?
Klar kann ich mir einen eigenen Baustein dazwischenschalten, aber ich denke in deinem Baustein wäre es wohl besser aufgehoben.

Hintergrund: Ich sammle die Meldungen und lasse sie mir in der Visu anzeigen, bis ich sie bearbeitet habe und Lösche dann die bisher aufgelaufenen Einträge. Natürlich ist mir eigentlich bekannt was ich bereits verwende und was neu ist... schöner wäre es trotzdem
LBS.png

Danke für den Baustein !

[jonofe]

Hallo jonofe ,

wäre es möglich einen Ausgang zu spendieren, der A2 und A3 zusammenfasst und eine Spalte mit einen Flag enthält, was neu bzw. geändert ist?

Ist jetzt in v0.2 des LBS enthalten (Ausgang A5).

Ich bin allerdings nicht ganz sicher, ob es genau das ist was du meintest. Oben schriebst du zuerst: "was neu und was geändert ist" am Ende aber "was ich verwende". Das sind zwei unterschiedliche Dinge. In v0.2 ist neu/geändert als Status an zweiter Stelle enthalten. Nicht aber der Status "genutzt/installiert/nicht installiert".

[Winni]

Bin mir jetzt unsicher, wie du es grundsätzlich gelöst hast, sofern die Eingänge E5 und E6 auch den Output von A5 steuern, ist es das, was ich gerne hätte.

Ist A5 nun komplett ungefiltert, bräuchte ich einen Spalte, welche über den Wert folgendes kennzeichnet:

neu 0
geändert nicht installiert 1
geändert installiert 2
geändert genutzt 3

Danke für deine Mühen
Winni

[jonofe]

Filter von E5 und E6 kommen auch für A5 zur Anwendung, allerdings gibt es auf A5 derzeit nur die Unterscheidung zwischen neu und aktualisiert. Wenn Du also auf E6 eine 1 hast (alle Aktualisierungen) dann hast du auf A5 derzeit keine Unterscheidung zwischen (genutzt, installiert, nicht installiert)

[Winni]

Ok danke, für mich persönlich ausreichend. Auch kein Problem wenn du es mal erweitern solltest. Ist ja kein Baustein den man mehrfach verwendet.

[Winni]

Sehe gerade du hast die Spalte auch in die bestehenden Ausgänge eingefügt, wenn ich den Code richtig interpretiere.... Hätte mir natürlich auch schon gereicht zusammenfügen hätte ich noch hingebracht . Wollte hauptsächlich verhindern, dass ich die beiden Ausgänge einzeln aufdröseln muss und die Info neu/geändert einzuschleusen um danach weiterzumachen....

[vento66]

AScherff Kannst Du bei Gelegenheit noch mal Im Maschinenraum schauen, das nicht jedesmal wenn in einen LBS Code eingestellt wird, die Liste "neuer LBS" getriggert wird? Vielleicht vom Haken "aktiv" abhängig machen. Sonst bekommt der Notifiations Baustein die Meldung neuer LBS, und den gibts in Wirklichkeit noch gar nicht.

[jonofe]

eigentlich hatte Alfred das schon auf bestimmt Felder reduziert, m.W. Version und Modul. Somit sollte eine Änderung der Beschreibung die Liste eigentlich nicht triggern. Ich weiss aber nicht, ob das Aktiv-Flag ausgewertet wird. Alfred kann sicher mehr dazu sagen.

[AScherff]

Ich hatte das schon berücksichtigt. Zur Klarstellung - Trigger zum generieren der Liste ist eine Änderung an:

• "Modul" - wenn sich was am Code geändert hat
• "Freigabe" - wenn der Baustein freigegeben oder gesperrt wurde
• "Version" - wenn sich die Versionsnummer ändert
• "Files" - Wenn optionale Dateien geändert wurden

[vento66]

Ja, wenn ein neues Modul eingefügt wird, der BS aber nicht aktiv ist, kommt über deinen Baustein eine Meldung. In der Downloadliste im DL Bereich taucht er aber nicht auf.

[AScherff]

Das ist erst mal Logisch so korrekt. Es gibt die Info einer Aktualisierung, an der Liste wird sich dann aber nichts ändern.

Wenn es stört, das sich das Datum der Aktualisierung ändert, jedoch nicht an den Inhalten, so kann ich das zunächst nicht unterbinden.

Der Trigger darf halt nur genommen werden um die Liste neu zu parsen. Der Parser muss dann herausfinden, ob und was sich nun definitiv geändert hat.

Gern liefere ich zum Trigger weitere Infos. Ich könnte eine XML oder ein JSON raus geben - Frage nur mit welchen Infos.

Vorschlag: Zusätzlich zu Datum/Zeit, ein MD5 über alle freigegebenen Bausteinnummern.

[vento66]

Hm jetz nochmal für Dich
if (($modul_neu != $modul_alt) && checkbutton id == checked) $liste = $Liste_neu