Danke für die Ideen. Ich hatte mir eh schon überlegt, wie ich das ohne OCL anders angehen kann, wollte einfach nur sicher sein, dass es mit einem simplen .replace(...) nicht getan ist.
Unterdessen habe ich es so gelöst, dass ich mir die Liste mit OCL hole, und dann die Suche ob drin vorhanden in Python mache.
GIbt es eine Möglichkeit, mittels einer Escapesequenz einen Apostroph in OCL zu schreiben?
Beispiel: ich habe in Python eine Abfrage, die unter den Phasen eines Projekts danach sucht, ob diese den Namen eines bestimmten Kunden als Code hat. Also etwa:
defaultPhase=proj.evalocl("phasen->select(aktiv)->select(code='{}')->first.boldid".format(kundenname))Wenn der Kundenname nun einen Apostroph enthält (was bei irischen Namen mit O'... häufig ist), dann gibt das einen Fehler.
Die üblichen Escapesequenzen, etwa ' durch \' oder durch '' ersetzen funktioniert leider nicht.
Danke.
Danke für die Hinweise. Gerade bei den neuen Custom Renderern sehe ich viele interessante Möglichkeiten. Allerdings konnte ich mich damit bisher nur theoretisch befassen, da wir noch am Planen eines geeigneten Updatefensters auf 6.6 sind.
zu 1 (mehrere Word-Vorlagen auf Office-Berichten):
Der naheliegende Workaround ist sicher, verschiedene (Sprach-/ Mandanten-/ Versions- usw.) Varianten als grösstenteils identische separate Berichte anzulegen. Die Möglichkeit, den Code zu zentralisieren, kann das sicher etwas vereinfachen, jedoch bleibt immer noch Redundanz, und die Steuerung der Variante wäre dann immer noch mehrfach über die OCL-Anzeigebedingung vorzunehmen.
Je länger ich drüber nachdenke, desto mehr habe ich den Eindruck, pro Bericht wieder verschiedene Vorlagen, und die Steuerung welche genommen wird aus dem Berichtscode vorzunehmen, wäre flexibler und könnte sehr mächtige Möglichkeiten bieten.
zu 3 (Anzeigebedingung auf Listenscripts):
Ich kann mir ebenso kaum sinnvolle Anzeigebedigungen vorstellen, die auf die einzelnen Einträge der Liste zugriefen und diese auswerten (was wohl performancemässig sehr problematisch wäre). Hingegen sehe ich zwei häufige Anwendungsfälle, wo mir diese Möglichkeit fehlt:
Wenn die Auswertungsmöglichkeit der Anzeigebedingungen so eingeschränkt wird, dass nur solche globalen Abfragen (zumindest eingeloggter User und aktueller Container im Baum), aber kein Zugriff auf die Einträge möglich sind, dann liesse sich das wohl ohne Performancerisiko umsetzen.
Pünktlich zu Weihnachten meine Wunschliste, was ich gerne in vertec noch an Features hätte. Alles eher kleinere Ergänzungen aus der Welt der Berichte/Scripts/Customizing. Ich würde mich freuen, wenn vertec etwas davon implementieren könnte. Danke.
Möglichkeit, auf einem (erweiterten) Office-Bericht wieder mehrere Word-Vorlagen als (Sprach-)Varianten zu hinterlegen
In den Legacy Office-Berichten konnten mehrere Sprachversionen der Vorlagen hinterlegt werden. In den neuen Office-Berichten gibt es stattdessen den Übersetzungsmechanismus, der ganz gut funktioniert, wenn in einer eher zahlenlastigen Auswertung einzelne Wörter oder Begriffe übersetzt werden sollen. Wir haben jedoch einige Dokumente (z.B. Vollmachten, Auftragsbestätigungen, Vollständigkeitserklärungen), die oft nur die Adresse und den Kundennamen aus vertec holen, aber aus umfangreichen Legal-Textblöcken bestehen, die teilweise statisch sind, teilweise über ein Flag aus vertec ein- oder ausgeblendet werden. Für diese ist der Übersetzungsmechanismus nicht gut geeignet, und eine Alternative wie früher wäre wünschenswert. Der aktuelle Workaround besteht darin, entweder im selben Bericht alle Sprachen hintereinander mit verschiedenen Bands zu haben, oder separate Office-Berichte zu führen und mit Anzeigebedingungen nur die zutreffende Sprache anzuzeigen, was aber beides auch schwerfällig ist.
Mein Vorschlag könnte sogar verallgemeinert werden, indem auf einem Office-Bericht unabhängig von der Sprache (bei gleichem Code für alle) mehrere Word-Vorlagen als Varianten hinterlegt werden, und dann im Code über eine Context-Variable gesteuert wird welche verwendet wird. Damit könnten neben verschiedenen Sprachen auch z.B. verschiedene zeitpunktabhängige Versionen eines Dokuments, oder je Projekttyp verschiedene Rechnungslayouts (für verschiedene Mandanten in der Unternehmensgruppe) einfach und ohne Redundanz implementiert werden.
Im Hinblick auf das absehbare Ende der Legacy Office Berichte wird eine solche Möglichkeit noch wichtiger und würde den Umstieg deutlich erleichtern - ich merke wie mich beim Ersatz einiger Legacy-Berichte vor allem das Problem der Mehrsprachigkeit noch etwas ratlos zurücklässt.
Bei (erweiterten) Office-Berichten aus dem Code auf die angelegte Aktivität zugreifen
Bei einigen unserer Berichte würde ich gerne nach der Berichtserstellung eine Zusammenfassung in die Aktivität schreiben (Bsp. vor der Berichterstellung wird via Dialog abgefragt, welche Elemente/Textblöcke angedruckt werden, oder eine optionale Adresse ausgewählt, oder es ergibt sich aus der Berichterstellung der Gesamtpreis einer Offerte, usw.)
Bei den Legacy-Berichten gab es dafür eine spezielle Funktion AfterReport, die bei den Office-Berichten fehlt. Und aus dem Berichtscode komme ich zwar an allfällige Aktivitäten des Objekts heran, aber nicht an die mit dem Bericht, da diese offenbar erst nach dem Durchlauf des Scripts angelegt wird.
Auch bei Listenscripts die Möglichkeit, eine Anzeigebedingung anzugeben
Bei Scripts auf einem Einzelobjekt lassen sich Berechtigungen am einfachsten über eine Anzeigebedingung, die den eingeloggten User abfragt, umsetzen (mir ist klar dass das alternativ auch über Benutzergruppen geht, ist aber dort komplexer und erfahrungsgemäss fehleranfälliger). Bei Scripts auf Listen wird die Anzeigebedingung aktuell ignoriert. Heute gar nicht umsetzbar ist, ein Listenscript nur auf einer bestimmten Listenauswertung anzubieten (sondern es erscheint immer auf allen Listen, die die entsprechende Klasse enthalten).
Falls eine Auswertung beliebiger Bedingungen auf Listenscripts zu Performanceproblemen führt, könnte das ev. eingeschränkt werden, dass nur auf globale Objekte (v.a. eingeloggter User) oder den Listencontainer selbst, aber nicht auf dessen Einträge abgefragt werden kann.
Bei Änderungs-Eventscripts auf den vorherigen Zustand des geänderten Felds zugreifen
Denkbar wäre zusätzlich zu den bestehenden Variablen args.eventmember und args.eventtype noch eine weitere Variable z.B. args.previousvalue einzuführen, die den Zustand des Felds vor der gemachten Änderung übergibt.
Damit könnten einfach Sicherheitsabfragen oder Eingabeprüfungen gemacht, und eine Feldänderung wenn nötig rückgängig gemacht werden.
Bei XML-Grids auf Seiten die Möglichkeit, Schrift- und Hintergrundfarbe dynamisch als OCL Expression anzugeben
Aktuell können im Seiten-Customizing in den Grid-Tabellen nur fixe Farben pro Spalte angelegt werden. Wünschenswert wäre, hier zumindest die Farben, ev. auch noch weitere Eigenschaften analog den Listeneinstellungen, dynamisch aus dem Zeileninhalt zu berechnen.
Bei Scriptbuttons die Möglichkeit, das argobject oder einen zusätzlichen Parameter als Expression festzulegen
Damit würde es möglich, in einer Seite mehrere Buttons zu platzieren, die dasselbe Script aufrufen, aber leicht verschiedene Dinge tun (z.B. verschiedene Vorgaben eintragen, verschiedene verlinkte Objekte aufrufen etc.). Im Moment geht das nur, indem mehrere sehr ähnliche Scripts parallel registriert werden, oder in einem Script mittels Dialog unterschieden wird was zu tun ist.
Ich würde gerne einen Customdialog mit Radio Buttons programmieren. Bisher schaffe ich es nicht, dass sich die Radio Buttons gegenseitig auslösen und immer nur einer aktiviert ist. Stattdessen bleiben die einmal aktivierten Buttons einfach alle aktiv. Laut Knowledgebase sollte das offenbar über das Tag GroupName gesteuert werden, das definiert welche Buttons zusammenhängen. Leider komme ich damit nicht weiter. Beispielcode:
dlgDefinition="""
<Dialog Title="Testdialog Radiobuttons" Width="450">
<Group Orientation="Vertical" Name="Auswahl">
<RadioButton Name="A" GroupName="Test" Text="Erste Option" IsChecked="True" />
<RadioButton Name="B" GroupName="Test" Text="Zweite Option" />
<RadioButton Name="C" GroupName="Test" Text="Dritte Option" />
</Group>
<Dialog.Buttons>
<Button Text="OK" IsAccept="True" Command="{Binding OkCommand}" />
<Button Text="Cancel" IsCancel="True" Command="{Binding CancelCommand}" />
</Dialog.Buttons>
</Dialog>
"""
print(vtcapp.showcustomdialog(dlgDefinition, {}))Hat jemand eine Idee was da anders sein müsste? Danke.