Und das:ralf.wenzel hat geschrieben:Das Problem ist: Egal, wo man es ändert, man wird es nie idiotensicher hinbekommen, dass sich das andere parallel mitändert. Man könnte (!) eine Methode in so eine Festwerteklasse bauen, die eben die Domänenfestwerte pflegt (und einen Transportauftrag dafür anlegt bzw. sich in denselben reinschreibt wie die Klassenänderung), aber es gibt keine Garantie, dass der Entwickler das Starten der Methode nicht vergisst.
funktioniert aber leider auch nur, wenn ihr Transportaufträge direkt im Entwicklungssystem anlegen könnte ohne ChaRM ( vom SolMan ). Bzw. muss der Entwickler dann dran denken, dass er das ganze über den SolMan noch transportieren muss. Und dafür gibt es dann wieder keine Garantie. Bei uns wäre das so gar nicht möglich, weil wir immer den SolMan dazwischen haben ( leider! ). Und standardmäßig sperrt der SolMan den Aufruf von FuBas die transportieren können von außen. - Heißt, wenn wir unsere Audits nicht versauen wollen, wäre das auch nicht möglich... oder übersehe ich hier etwas?black_adept hat geschrieben:Idiotensicher machen:
Habt ihr den Codeinspector bei der Transport/Aufgabenfreigabe aktiviert? Dann könnte dort ein Konsistenzcheck durchgeführt werden, der die Freigabe ablehnt, wenn Abweichungen gefunden werden.
P.S. Muss nicht mal der Codeinspector sein. Einfach den BADI bei der Transport/Auftragsfreigabe das machen lassen.
Man wird immer irgendwelche manuellen Schritte brauchen.zzcpak hat geschrieben:ich sehe im Moment nicht, wie man das im Rahmen von Charm ohne manuelle Schritte zwischendurch bewerkstelligen sollte, es sei denn, du willst dann auch den Change im Charme automatisiert anlegen und in Bearbeitung setzen.