• AIRS-639
  • AIRS-711 Reuse PO Change Verifier to detect changes on attachments
  • AIRS-712 New config entry in tAirChgVerifierConfig for attachments
  • AIRS-713 Generate Non-Collab-Change alert
  • AIRS-736 Adapt PO History SQL

• AIRS-632 PO attachments E-Mail Access user handling
  • AIRS-709 Detect changes on attachments (via M2M or UI deletion)
  • AIRS-710 Adapt Email-Templates with added/deleted attachments

• - AIRS-711 Reuse PO Change Verifier to detect changes on attachments
  • + Reuse for history
  • - Reuse for alert writing
• + AIRS-712 New config entry in tAirChgVerifierConfig for attachments
• - AIRS-713 Generate Non-Collab-Change alert
• + AIRS-736 Adapt PO History SQL

• - AIRS-709 Detect changes on attachments (via M2M or UI deletion)
• - AIRS-710 Adapt Email-Templates with added/deleted attachments

Die ursprüngliche Idee war den POChangeVerifier wiederzuverwenden. Leider geht das nicht ohne weiteres. Die Konstruktoren der Klasse sind so ausgelegt, dass sie eine Schedule Line als Parameter erwarten, die nicht leer sein darf. Genauer gesagt, wenn sie leer ist, dann wird kein ChangeLog geschrieben. Und es ist nicht so, dass wir einfach die Konstruktoren umgestalten können, da die Werte aus dem Schedule Line Parameter in der Klasse oft verwendet werden. D.h. man kann nicht auf Schedule Line irgendwie verzichten. Was uns betrifft, so haben wir zwei Fälle. In einem Fall sind die Attachments auf dem Level einer Schedule Line. Da passt es und wir können sehr wohl POScheduleLine wiederverwenden. Aber in dem anderen Fall sind die Attachments auf der Header-Ebene. D.h. wir können gar keine dazu passende Schedule Line haben. Deshalb muss die Idee transformiert werden. Dazu gibt es folgende Ideen:

1. Da bei den Attachments auf der Schedule Line Ebene die Klasse POChangeVerifier sehr wohl verwendet werden kann, macht es Sinn den POChangeVerifier so umzuschreiben, dass beides möglich wird. Evtl. muss die Funktionalität zum Schreiben des Changelogs aus dem POChangeVerifier noch weiter abstrahiert werden.
2. Man erstellt eine neue sehr einfache Helper-Klasse, die Changelog-Einträge anhand von HeaderId, PosId und FileNames schreibt.

Ich habe die Variante 1 gewählt: es wird POChangeVerifier verwendet, und das Model der POScheduleLine wird bei den Änderungen auf der Header-Ebene “gefaked”.

Beim Import der Attachments soll auf jeder Ebene ein Satz in die History geschrieben werden. Und zwar auf folgende Weise. Wenn die Datei auf der Headerebene ist, kommt ins Feld “Field” der Wert “Header Attachment” rein. Wenn die Datei auf Positionsebene ist, kommt dort einfach “Attachment” rein. Ins Feld “Old value” wird null geschrieben. Ins Feld “New value” kommt die Liste der Dateinamen rein. Wenn sie länger als 1024 Zeichen lang sind, dann wird sie mit “…” abgeschlossen.

So wurde es mit Stefan Schwarzfischer besprochen.

Die Methode POChangeVerifier.createChangeTopic() ist so aufgebaut, dass nur dann ein Satz in die Alerts-Tabelle geschrieben wird, wenn die Operation keine ADD-Operation ist (!bAddoperation), die PO nicht in einem bestimmten Status ist und der CP so konfiguriert ist, dass es erlaubt ist in diesem Status Sätze in die Alerts-Tabelle zu schreiben. Das wird bei den Attachments nicht funktionieren, da wir mal eine ADD-Operation haben, mal eine DELETE-Operation. D.h. egal wie es konfiguriert ist mal wird der Satz geschrieben, mal nicht. Um das zu umgehen, hab ich vorgeschlagen, die bei den Attachment-Sätzen immer zu schreiben (vorausgesetzt auf dem CP-Level ist schreiben erlaubt). D.h. der Code sieht jetzt so aus:

if(enforceVisibilityForAdd || !bAddOperation) {
  //do not track nonCollabChanges if in status NOP, CCOR, CANREQ (CR075)
  // BUT(!)
  // disable CR075 if disablePONCCExceptionForNOPandCCORandCANREQ is true (CR164)
 
  if(isTrackingRequired(curConfig, this.parentModel, isDisablePONCCExceptionForNOPandCCORandCANREQ())) {
    addNonCollabTracking(getUserContext(true), curConfig, sFieldName, oldValue, newValue);
  }
}

So wurde es mit Stefan Schwarzfischer am 08.08.2018 besprochen. Er wollte es aber noch mit Kollegen besprechen, und mir dann Bescheid sagen, ob das in Ordnung ist.
Upd. 09.08.2018: Stefan meinte, dass die Config-Prüfung gemacht werden soll. D.h. die oben beschriebene Lösung müsste passen.

• getTrackFieldsConfig()
  • fetches configs from DB (using customer CPId from this.parentModel)
• verify(String fieldName, Class<?> fieldType, Object oldValue, Object newValue,…)
  • 2 methods, which compares old and new values and initiates a change if they are different
• createInitialTopic()
• createChangeTopic(…)
• finish(…)
• reportNonCollabTracking()
• finishCommentOnNonCollabChanges()
  • Spezialfunktion für NonCollab Changes auf dem Comment-Feld
• verifyChangeByFieldType()
  • compares new and old values
• getOSPTracking() / addOSPTracking()
• createOSPMinorChangeTopic(…)
• createOSPMajorChangeTopic(…)
• logCollabChange(…)
• addOSPNewLineTopic(…)

History anschauen (cObjectReference ändern!):

SELECT
tAirChangeLog.*,tAirPartnerRelation.*,tAirOrderingOfficer.*,tAirMaterial.*
FROM tAirChangeLog,tAirPartnerRelation,tAirOrderingOfficer,tAirMaterial
WHERE tAirChangeLog.cRelationId_CL=tAirPartnerRelation.cRelationId
AND tAirChangeLog.cMaterialId_CL=tAirMaterial.cMaterialId
AND tAirChangeLog.cOrderingOfficerId_CL=tAirOrderingOfficer.cOrderingOfficerId
AND ROWNUM <= 5000
--AND (cCustomerPortalGroup IN (1))
--AND (   cCustomerCPId IN   (      -1000002,10006106,10006107   )   OR cSupplierCPId IN   (      -1000002,10006106,10006107   )   OR cConsigneeCPId IN (-1000002,10006106,10006107))
--AND(   cCustomerCGId = 100027 OR cSupplierCGId = 100027 OR cConsigneeCGId = 100027)
--AND CISUNREGSUPPLIER = 0
--AND cInternalUseOnly = 0
--AND (CPENDINGENTRY IS NULL OR CPENDINGENTRY=0)
-- AND cProcessId = 2
AND cObjectReference = 545639
--AND cSubObjectReference = 5003843
AND cActionTime>=1501624800000
AND cActionTime<1533247200000
ORDER BY cActionTime DESC,cField ASC

• Momentan ist es so implementiert, dass für Attachments ein eigener POChangeVerifier verwendet wird. Das führt dazu, dass in der History für einen Import zwei (oder mehr bei Attachments an Header-und Position-Level, oder bei mehreren Positionen?) Transactions auftauchen. Eine Transaction für Änderungen an Attachments und eine Transaction für Änderungen an allen anderen Feldern. Man kann theoretisch auch denselben POChangeVerifier verwenden (ich nehme an, irgendwo im POmanagerEJB), das würde aber die Verwendung von der Action “Added” unmöglich machen, da ein POChangeVerfier nur eine Action haben darf.