Termine

TODO

- rm#24264 POEMA: Customer Modify of Collab Values on UI doesn't generate a E-Mail Notification to supplier
- JRebel einrichten
- Chrome einrichten (https://developers.google.com/web/tools/setup/setup-workflow)
- rm#24452 POEMA: Wrong E-Mail notification in case of adding a PO SL in in parallel change of Header Incoterm
- AIRS-27 PO history display: date format
Impact of SCRUM on the DEV process

Ursache für “zu viele Felder” in der Mail ist, dass beim Upload die PO SL aus der DB gezogen wird und mit der wird es dann verglichen. Wobei CSV (oder DB) nicht alle Felder enthält. Deswegen wird beim Vergleich eine Änderung festgestellt.
Lösungsvorschlag: da in der History nur die “richtigen” Felder sind, machen wir das genauso wie dort. Nämlich in POChangeVerifier.createChangeTopic() wird beim Hinzufügen der History-Einträge geschaut, ob sie in der Konfiguration drinnen sind. Die OSPTracking-Einträge werden momentan aber immer hinzugefügt. Um den Bug zu Fixen sollte man beim Hinzufügen von OSPTracking-Einträgen auch in die Konfig schauen.
- Hr. Schwarzfischer berichten ob:
  - diese Konfiguration ein Flag “OSP relevant” enthält (die Tabelle soll angeblich tAirVerifyConfig heißen)
    - wenn ja, ob man dieses Flag verwenden kann
  - dieser Fix dann Mehraufwand beim Testen bedeutet: OSP muss neu getestet werden (XML-Import/UI-Change/CSV-Upload)
In der Tabelle TAIRCHGVERIFYCONFIG sind folgende Flags verfügbar:
- CCHANGELOGENABLED → History
- CNONCOLLABENABLED → ist Non-Collab Feld?
- COSPNOTIFY → ist OSP Non-Collab(!) Feld?
- CCUSTOMCOLLAB → ist Custom Collab Feld
- CSUPPLIERACTIONENABLED → ist Accept/Reject möglich in der History?

+ Klären an welcher Stelle was zu tun ist
- POOSPVelocityForSupplier.determineTypeOfMail() → … → static … getMailType()
- POImportProcessor.getSiblingFromDB() lädt this.dbData und dann setzt es wieder auf null (Zeile 1304). Danach wird aber in getChangeVerifier() folgendes gemacht: this.dbData == null || !this.importData.isHeaderInitiallyOnDB(), was dann natürlich true ist.
  - Vorschlag von Burkhard: this.dbData bei den OSP-Einträgen auf null nicht setzen.
    - Testen, ob es das Problem löst.
    - Schauen, ob nichts anderes dadurch kaputt geht.
- Ein POHistoryModel wird defaultmäßig mit dem OSP_NOTIFICATION_TYPE.NEWOSP erstellt ( s. POChangeVerifier.addOSPNewLineTopic():1802 )
+ Spec und die Stelle in der Spec finden, wo definiert ist welche Email wann verschickt wird
- 5.3.7.4.1 E-mail notifications to supplier
- 5.3.7.4.1.5 Case 3: Update on important fields
- 5.3.7.4.1.7 Case 5: PO update with mixed changes
- Eine Stelle ist im CR: https://cust-projects.seeburger.de/redmine/issues/22208 . Die ist aber nicht eindeutig. → andere Stelle suchen oder Hr. Schwarzfischer fragen
- Code ändern
- Testen

Hr. Schwarzfischer fragen:
- Wo ist definiert, welche Mail höher priorisiert ist

~~Eigentlich sollten 2 Mails rausgehen, da Import positionsbasiert erfolgt. Richtig?~~
- S. POImportXMLHandler.processPositionsElement()
  - → importOSPHandler.finalizeImport(itemInfos.values());
    - …
    - → POOSPVelocityForSupplier.generateMail()

In der PO History bei folgenden Feldern Datumsformat so anpassen, dass die Uhrzeit nicht drin ist:

Testen mit Benutzern:

Serverseite:
- POChangeLogScreen → ChangeLogScreen → SuiTableScreen → SimpleAjaxScreen
  - siehe ChangeLogScreen.getJsonResponse()
Clientseite
- /js/cfg/base/changelog/changelogCfg.js.inc
- /js/cfg/po/changelogCfg.js.jsp (unwichtig?)

Fragen an Burkhard:

- Angular для профессионалов
- - 4. Краткий курс HTML и CSS
  - - Bootstrap
- Prüfen, ob die App nicht zu viel zieht
- - Jobs / Fragebögen nur für die entsprechende Organisation (bzw. Mitarbeiter) holen