Design-Repository

[ChatMe]

Hallo,
während der Entwicklungstätigkeit unter R4.5 haben wir immer wieder genutzte Designelemente in einer Schablone gesammelt, auf welche nur wenige Personen Manager waren und die restlichen Entwickler Author. Somit war sichergestellt, daß Designelemente aus der Schablone kopiert (vererbt) werden konnten, jedoch die Masse der Personen nicht änderungsberechtigt waren (ist ja ein defiziles Thema, gerade bei Vererbung von Designelementen).
Unter R5 und dem Designer, kann leider nur noch jmd. die Schablone öffnen, wenn er die Entwickler-Berechtigung hat. Damit kann er auch leider die Elemente verändern.  
Hat jemd. von euch eine Idee, wie man globale Designelemente allen Entwicklern zur Verfügung stellen kann, ohne dass diese (aus Versehen) Änderungen vornehmen können ? Und das alles ohne Third-Party-Produkte, only pure Notes ?

Viele Grüße, Oliver

[eknori]

Das wird wohl nicht gehen.

[ata]

... ich weiß nicht ob ich das richtig verstanden habe. Einzelne Designelemente sollen aus dieser Schablone verwendet werden können, ohne daß die Originale überschrieben werden können...

Es gibt doch die Möglichkeit einzelne Designelemente aus verschiedenen Schablonen aktualisieren zu lassen (=> Design übernehmen). Wenn ich als Entwickler in meine Datenbank ein Designelemente (z.B. Maske) mit demselben Namen in meine DB aufnehme (der Inhalt kann leer sein), diesem Designelement dann sage "Design übernehmen aus..." der bestimmten Vorlage, dann müßte dieses Element aus der anderen DB übernommen werden, wenn das Design aktualisiert wird...

ata

[Glombi]

Folgendes ginge: Die DB hat keine konsistente ACL. Die User ziehen sich dann eine lokale Replik der Datenbank und haben dort Managerrechte. Dann können die Designelemente Kopieren und auch ändern- das wird dann aber nicht zurückrepliziert, da die User kein Entwicklerrecht auf der Server Datenbank haben.

Gruß
Andreas

[eknori]

Ich denke, es geht darum, daß die Entwickler jeweils nur ihre eigenen design ändern sollen. An den Designelementen anderer Entwickler haben die nix zu suchen.

Wenn aber jeder Entwickler notwndigerweise in R5 auch Entwicklerrechte hat, kann er ja logischerweise auch auf die designs anderer zugreifen.

Es müsste also so etwas wie eine Author berechtigung für Entwickler geben.

Und das geht IMHO nicht

eknori

[ata]

... ich möchte die Möglichkeit nochmals aufdrösseln...

Es gibt eine Master-Design-Vorlage, ich nenne das Template "Master". In dieser Datenbank befinden sich alle möglichen Designelemente. Die normalen Entwickler haben auf diese Datenabnk nur Leserechte - sie sind also nicht Entwicklerberechtigt in dieser Datenbank. Die konsitente ACL ist aktiviert. In dieser Datenbank befindet sich eine Maske namens "Kontakt", die verschiedene Felder etc. enthält.

Du erstellst eine neue Datenbank, in der du die Managerrechte hast. In dieser Datenbank erstellst du eine leere Maske, die den Namen "Kontakt" hat. In den Eigenschaften dieses Design-Elementes gibst du unter "Inhertit design..." das Template "Master" ein. Anschließend machst du einen Design-Refresh auf deine neue Datenbank - und du hast das Design der Maske aus der Master-Schablone übernommen, ohne daß du Entwicklerrechte auf der Masterschablone hattest - du hast eine Kopie des Design-Elementes, ohne daß du in der Lage bist das Original zu verändern. Nimmst du abschließend bei deinem neuen Design-Element wieder den Bezug auf das Template "Master" heraus gehört die Maske dir...

ata

[ata]

... Sorry, ich war zu schnell am lesen. Um so was wie Autorenzugriff herzustellen, müßte der Bezug in die Masterschablone genauso rückwärtig gemacht werden. Der Manager der Datenbank muß dazu immer wieder mal des Design aktualisieren. Die Bezugs-DBs müssen dann eben erreichbar sein, und können nicht lokal liegen - deine neue DB mit deinem modifizierten "Kontakt" muß auf dem Server liegen. In der Masterschablone bezieht diese Maske ihr Design aus deiner Schablone...

ata

[ChatMe]

Hallo eknori & ata,
vielen Dank für eure Bemühungen. Ich habe den Weg von ata nachvollzogen und er scheint mir der beste zu sein, wenn man den auf API-Programmierunf verzichten will, es klappt absolut wunderbar. Jetzt barucht nur noch ein lesbares Dok in der Repository-DB erstellt und gepflegt werden, welche Elemente es mit welchem Namen gibt (evtl. welche Elemente man für eine bestimmte Funktionaltät benötigt) und der Entwickler muss diese nur mit richtigem Namen und  Inherited-Eintrag anlegen => Klasse.
 
Idealerweise wäre es natürlich, würden diese Elemente direkt erstellt werden (inkl. des Namens und des Inherited-Namens), aber dann sind wir wahrscheinlich wieder bei API-Programmierung.
Euch beiden: Vielen Dank, Oliver