In Regeln auf Projekt-ID oder Projektname prüfen
Hallo zusammen,
wir nutzen unsere Vorlagen im Rahmen eines Multi-Projekt-Setups in mehreren Projekten. Die Vorlagen werden mit dem Template Transport Feature in die Projekte verteilt.
Wir haben jetzt die Anforderung bestimmte Felder nur in bestimmten Projekten anzuzeigen, ohne direkt eine eigene Vorlage anlegen zu müssen.
Ist es möglich in den Regel auf die Projekt-ID oder den Projektnamen zu prüfen? Evtl. über das #global - Objekt?
Danke und viele Grüße
Fabian
-
Hi Fabian,
in den Regeln selbst gibt es keine passende <PROPERTY> für den Projektnamen oder die ID. Wichtig: das #global in den Regeln hat ja nichts mit dem #global z.B: im Ausgabekanal zu tun, insbesondere ist es ja kein "Objekt".
Aber deine Anforderung sollte über einen "ValueService" lösbar sein. Den kann man entweder im Rahmen eines Moduls implementieren oder seit einiger Zeit auch über ein Script (das dann über den inzwischen mitgelieferten ScriptValueService" genutzt wird).
Entsprechende Doku-Seiten hierzu:
- Allgemeiner Mechanismus (SCHEDULE)
- Konkrete Infos auf der Unterseite (dort die Teile zum "ScriptValueService)
Hier gab es mal eine "ähnliche" Frage in einem anderen Zusammenhang - da ging es um Absatz-Namen. Wobei ich denke dass dein Fall eher noch einfacher wäre.
Wobei es dann für deinen Fall im Detail natürlich diverse Varianten gäbe, an welcher Stelle man dann "tatsächlich" die Info hinterlegen wollen würde (worauf dieses Script oder auch der "echte" ValueService dann zugreift):
- Direkte Angabe als Parameter (z.B. kommagetrennte Liste von Projekten) in der jeweiligen Regel - also als Parameter wie "visibleForProjects". Ließe sich dann natürlich extrem feingranular kontrollieren, aber potenziell entsprechender Aufwand (insb. bei Änderungen). Und ich bin persönlich kein Fan davon, Dinge an Projektnamen oder Projekt-IDs zu hängen.
- Wenn es bei euch eher nur sagen wir mal 2-3 "Typen" von Projekten gibt, wo sich das "pro Typ" immer "gleich verhält", fände ich eine Art "Einstellung" in den Projekteinstellungen sinnvoller (auf die das Script / ValueService dann zugreift). Also z.B. diesen "Projekttyp". Dann würde man in der Regel (=im Parameter) nur sagen für welche dieser "Typen" ein Feld sichtbar sein soll.
- ... oder irgendwie anders :-)
Welche Variante davon für euch sinnvoll ist, "kommt drauf an"...
Zum Thema ScriptValueService vs. "richtiger" ValueService (damit meine ich die Implementierung eines ValueService als PUBLIC-Komponente im Rahmen eines eigenen Moduls): Generell würde ich sagen: Je "komplexer" das wird, desto eher die Tendenz, das nicht über den ScriptValueService (und damit über ein Beanshell-Script) zu machen, sondern über einen eigenen "richtigen" ValueService.
Viele Grüße
Michael0
Please sign in to leave a comment.
Comments
1 comment