Designvererbung und Zugriffsschutz durch Rollen bei Views

[_luki]

Guten Tag Forum,
guten Tag Experten...

Ich habe hier eine relative große Datenbank, welche zzt. nur intern verwendet wird. Dies soll sich aendern, denn auch externe Partner sollen hier zugreifen – dafuer sind jedoch einige Aenderungen noetig, bezueglich deren ich noch einige Fragen habe…
Die Datenbank hier besitzt > 200 Views, welche mit verschiedenen Statements gefuettert werden.

zB.:

Code

SELECT ( ((@Contains(Produkt; "Staubsauger")) & (@Contains(Produkt_Art; "Super_Strong"))) | 
((@Contains(Produkt2; " Staubsauger ")) & (@Contains(Produkt_Art2; "Super_Strong"))) | 
((@Contains(Produkt3; " Staubsauger ")) & (@Contains(Produkt_Art3; " Super_Strong "))) )
 & (!@Contains(Art_des_Produkts; "Archiv"))

Noch ein Beispiel:

Code

SELECT ( ((@Contains(Produkt; "Fräse")) & (@Contains(Produkt_Art; "Mittelklasse"))) | 
((@Contains(Produkt2; " Fräse ")) & (@Contains(Produkt_Art2; " Mittelklasse "))) | 
((@Contains(Produkt3; " Fräse ")) & (@Contains(Produkt_Art3; " Mittelklasse "))) ) & 
(!@Contains(Art_des_Produkts; "Archiv")) & (!@Contains(Art_des_Produkts; "Standard") & 
(!@Contains(Produkt_Art; " Luxusklasse ")) & (!@Contains(Produkt_Art2; " Luxusklasse ")) & 
(!@Contains(Produkt_Art3; " Luxusklasse ")))

Weiters gibt es in dieser DB 4 verschiedene Rollen zur Zugriffsbeschränkung:
- Admin
- Architekt
- Partner_A
- PL70plus

Ein Partner kann also entweder „Admin“, „Architekt“, „Partner_A“, oder „PL70plus“ sein. Genau diese Eigenschaften sind momentan auch in der Spalte „Art_des_Produkts“ enthalten (es handelt sich um Bauplaene).
Nun waere es natuerlich wuenschenswert, dass ein Partner, welcher die Rolle „Admin“ hat, alle Baupläne sehen kann; ein „Architekt“ jedoch nur jene, welche in der Spalte „Architekt“, oder „Partner_A“ enthalten… Es soll also eine Hierachie entstehen.

Momentan sieht noch jeder alles – wie kann ich das am besten realisieren?

Ein weiteres Problem ist, dass bei den > 200 Views das Design geändert werden muss. Dies ist natuerlich sehr, sehr mühsam. Deshalb wollte ich fragen, ob es die Möglichkeit gibt, eine „Master-View“ zu entwerfen, welche ihre „Design-Eigenschaften“ an alle anderen vererbt?

Da seitens des Marketings immer wieder Erneuerungen bzgl. Logo/Firmenfarben entstehen wuerde das verstaendlicherweise extrem viel Arbeit ersparen…
Ich habe jetzt schon sehr viel gegoogelt, bzw. die Domino-Hilfe befragt, bin jedoch noch nicht wirklich fündig geworden. Ich waere ueber jeden Tipp sehr dankbar.

Herzliche Grüße,
Luki

[Peter Klett]

Von einer Masterview weiß ich nichts. Ich würde mir aber Gedanken um ein Redesign der Datenbank machen. Wenn ich das richtig verstanden habe, habt ihr deshalb über 200 Ansichten, um in jeder einzelnen Ansicht nur einzelne Produkte in unterschiedlichen Ausprägungen darstellen zu können. Das bedeutet, dass mit jeder Änderung im Produktkatalog das Design der Datenbank angepasst werden muss. Vorsichtig ausgedrückt halte ich das für Wahnsinn.

Wie navigiert Ihr über die vielen Ansichten?

Ich würde die Anzahl der Ansichten drastisch reduzieren und so verallgemeinern, dass sie auch bei neuen/geänderten Produkten ohne Designänderung funktionieren. Hierzu würde ich die Ansichten stark kategorisieren. Falls Ihr aber die vielen einzelnen Ansichten aus optischen Gründen beibehalten wollt, kannst Du in eine Maske mehrere Auswahlfelder einbauen, in der Produkte, Qualität und sonstige Eigenschaften auswählbar sind. In einer eingebetteten Ansicht zeigst Du dann nur die Dokumente, die den Inhalten der Auswahlfeldern entsprechen. Die Auswahllisten können sich aus den vorhandenen Dokumenten errechnen. Die EINE eingebettete Ansicht ist in der ersten Spalte nach allen Auswahlmöglichkeiten kategorisiert.

Dann fügst Du noch ein Leserfeld in die Dokumente ein, so dass die unterschiedlichen Benutzergruppen nur die relevanten Dokumente lesen können. Mit solch einer Struktur wirst Du in Zukunft wesentlich mehr Freude haben.

Falls es Dein einziger Job ist, diese Datenbank anzupassen, lass es lieber, sonst verlierst Du ihn danach

[_luki]

Von einer Masterview weiß ich nichts. Ich würde mir aber Gedanken um ein Redesign der Datenbank machen. Wenn ich das richtig verstanden habe, habt ihr deshalb über 200 Ansichten, um in jeder einzelnen Ansicht nur einzelne Produkte in unterschiedlichen Ausprägungen darstellen zu können. Das bedeutet, dass mit jeder Änderung im Produktkatalog das Design der Datenbank angepasst werden muss. Vorsichtig ausgedrückt halte ich das für Wahnsinn.

Wie navigiert Ihr über die vielen Ansichten?

Es handelt sich um ein sehr, sehr breites Produktsortiment, navigiert wird ueber eine Gliederung - das funktioniert eigentlich ganz gut.
Unsere Produkte werden nicht geändert, es kommen maximal neue hinzu und die alten ins Archiv. Sollte ein neues Produkt hinzukommen wird fuer dieses wieder eine neue View angelegt.

Ich würde die Anzahl der Ansichten drastisch reduzieren und so verallgemeinern, dass sie auch bei neuen/geänderten Produkten ohne Designänderung funktionieren. Hierzu würde ich die Ansichten stark kategorisieren. Falls Ihr aber die vielen einzelnen Ansichten aus optischen Gründen beibehalten wollt, kannst Du in eine Maske mehrere Auswahlfelder einbauen, in der Produkte, Qualität und sonstige Eigenschaften auswählbar sind. In einer eingebetteten Ansicht zeigst Du dann nur die Dokumente, die den Inhalten der Auswahlfeldern entsprechen. Die Auswahllisten können sich aus den vorhandenen Dokumenten errechnen. Die EINE eingebettete Ansicht ist in der ersten Spalte nach allen Auswahlmöglichkeiten kategorisiert.

Dann fügst Du noch ein Leserfeld in die Dokumente ein, so dass die unterschiedlichen Benutzergruppen nur die relevanten Dokumente lesen können. Mit solch einer Struktur wirst Du in Zukunft wesentlich mehr Freude haben.

Gibt es eventuell so etwas wie eine "dynamische View"?
Momentaner Stand ist, dass wir eben > 200 Views haben, je ein SELECT-Statement.

Optimal waere, wenn je nachdem, welchen Gliederungspunkt ich klicke, ein bestimmtes SELECT-Statement erzeugt wird, durch welches widerum die dynamische View die gewuenschten Dokumente darstellt...

Falls es Dein einziger Job ist, diese Datenbank anzupassen, lass es lieber, sonst verlierst Du ihn danach

Wuensch mir Glueck.

[Peter Klett]

Die "dynamische View" kannst Du mit einer eingebetteten Ansicht in einer Maske (oder einer Seite? hab ich noch nicht mit gearbeitet) erreichen. Zwar wird dort nicht ein eigener Select definiert, aber Du kannst die Dokumente anzeigen, die der ersten Kategorie entsprechen. Dort würde ich z.B. Produkt#Qualität#SonstigesMerkmal eintragen, in der Maske wählst Du dann Produkt, Qualität und SonstigesMerkmal aus, und nach einem F9 werden nur die Dokumente in der Ansicht angezeigt, die dazu passen.

[Thomas Schulte]

Designtechnisch ist was ihr macht IRRSINN. Und wenn ihr Zugriffsrechte vergeben wollt dann nehmt doch BITTE LESER UND AUTORENFELDER.

Ein "weiter so" ist in diesem Fall definitiv NICHT der beste Weg.

[_luki]

Designtechnisch ist was ihr macht IRRSINN. Und wenn ihr Zugriffsrechte vergeben wollt dann nehmt doch BITTE LESER UND AUTORENFELDER.

Ein "weiter so" ist in diesem Fall definitiv NICHT der beste Weg.

Das ist mit klar, deshalb ja auch das dringende Anliegen der Aenderung.

Die "dynamische View" kannst Du mit einer eingebetteten Ansicht in einer Maske (oder einer Seite? hab ich noch nicht mit gearbeitet) erreichen. Zwar wird dort nicht ein eigener Select definiert, aber Du kannst die Dokumente anzeigen, die der ersten Kategorie entsprechen. Dort würde ich z.B. Produkt#Qualität#SonstigesMerkmal eintragen, in der Maske wählst Du dann Produkt, Qualität und SonstigesMerkmal aus, und nach einem F9 werden nur die Dokumente in der Ansicht angezeigt, die dazu passen.

Ich habe mir den Vorschlag jetzt eingehend durch den Kopf gehen lassen; fuer eine Einteilung in Kategorien sind die Produkte leider zu verschieden. Es beduerfe 15+ verschiedener "Kategorien", bzw. Kriterien zur konkreten unterscheidung der Produkte...

Langsam aber sicher bin ich kurz vorm Schlaganfall

Eine eventuelle Idee waere gewesen, den Gliederungseintraegen links je eine ID zu vergeben. Anhand dieser IDs koennte ein Agent den jeweiligen SELECT-Command (welcher eben einer bestimmten ID zugeordnet ist) ausfuehren und somit zur Laufzeit eine View befuellen... (wenn das technische ueberhaupt moeglich ist)
Begeistert bin ich jedenfalls nicht von dieser Loesung...

Momentan beschaeftige ich mich mit XPages, welche voelliges Neuland fuer mich sind. Die Tutorials hauen natuerlich groszteils nicht hin, weil den Views nicht unmittelbar Werte, bzw. Felder hinterlegt sind (wie in den Tuts vorgegeben) - sondern das ganze ueber diese SELECT-Statements funktioniert...

Mir mangelt es zzt. leider an einem vernuenftigen Loesungsansatz :/

[Peter Klett]

Du solltest Dich von der Idee lösen, je Produkt, Merkmal usw. eigene Selects, Gliederungseinträge usw. zu bauen. Solange Du an dieser Struktur festhältst, wirst Du mit keinem technischen Mittel der Welt eine vernünftige Lösung produzieren, auch wenn XPages richtig toll und modern klingt, das logische Grundgerüst muss stimmen.

[atbits]

@Peter: Der Nachteil von den eingebetteten Ansichten ist, dass man in den Spaltenheadern nicht mehr sortieren kann.
Ich versuche das auch oft wie von Dir beschrieben, das Problem ist, wenn man den Usern einmal die sortierten Header gezeigt hat, wollen die die nicht mehr hergeben (weil dann haben Sie ja weniger Funktionalität als vorher ... - die Diskussionen sind meistens fruchtlos und rationale Argumente ziehen da auch nicht), naja

Wie wäre es denn wenn Du an Hand einer "Vorlagen-Ansicht" ncächtlich von einem Agent je Produkt einen Gliederungseintrag und eine View machen läßt?

200 Views sind aber zu viel, die App ist doch sicher unerträglich lahm.

Andere Variante eine Filter-Maske, die eine Search macht und die Suchergebnisse in einen Folder pusht.

Ach es gibt zig Ansätze, es hängt wirklich von der Applikation ab, die müßte man mal sehen und dann redesignen...

Kannst Du ein paar Screenshots posten, damit man ein gefühl kriegt um was es geht?

Grüße David

[_luki]

200 Views sind aber zu viel, die App ist doch sicher unerträglich lahm.

Bzgl. der Geschwindigkeit kann ich mich ueberhaupt nicht beschweren.

Kannst Du ein paar Screenshots posten, damit man ein gefühl kriegt um was es geht?

Hab' mal einen angefuegt.
Die Gliederung links ist erstmal in Produktgruppen unterteilt, welche dann die verschiedenen Produkte preisgibt.
Diese Produkte sind in weitere Teilprodukte unterteilt.

Wenn man jetzt ein Teilprodukt auswaehlt wird die dazugehoerige View mit einem SELECT-Statement aufgerufen.
Nun habe ich im mittleren View eine Auflistung saemtlicher Bauplaene, saemtlicher Komponenten/Ansichten des Teilproduktes.

Nun kann ich hier den gewuenschten Bauplan auswaehlen, dieser wird dann in der rechten View angezeigt.

Dort habe ich nun ein Bild, mit einem Thumb des Bauplanes und den Bauplan als Dateien zum Download bereitgestellt.

Ich hoffe, ich konnte das ganze etwas verdeutlichen...

Gruesze & herzlichen Dank,
Luki

[atbits]

Das ist ja eine Webanwendung, davon stand ja noch gar nix im Post.

Da haben wir doch gleich viel mehr Möglichkeiten ;-)

Baue statt den ganzen Views einen Web-Agent der Dir quasi die View-Tabelle aufbaut.
Du übergibst dem blos das SELECT, dann macht der ein Search und printed die HTML raus und fertisch is die Laube.

Grüße David

[Peter Klett]

Das ganze sollte sich aber dynamisch aus den vorhandenen Dokumenten errechnen, einschließlich der Gliederung. Es kann nicht sein, dass bei Produktkatalogänderungen eine Designänderung notwendig ist. Und vergiss nicht die Leserfelder, falls Du effektiv den Zugriff auf Dokumente schützen willst.

[atbits]

Peter Du hast recht, aber das läßt sich eben alles durch Agents prima lösen.
Statt einer Gliederung läßt man sowohl das Linke Menü, als auch die "View" durch Agents erzeugen.

Grüße David

[Peter Klett]

Dass Du, David, das weißt, ist mir absolut klar. Der Hinweis galt Luki. Ich wollte nur vermeiden, dass er sich jetzt hinsetzt und die 200 Views durch 200 Agenten ersetzt, dann macht er nämlich strukturell genauso weiter, wie bisher.

[atbits]

 
Hatte ich schon auc so verstanden - ich wollte nur nochmal den Tipp geben, dass man natürlich auch die "Navigation" per Agent bauen kann.

Aber Peter ich glaube wir 2 sind eh noch die einzigen die der Thread ier interessiert ...

Grüße David

[_luki]

Herzlichen Dank fuer die Antworten!

Darf ich mal' versuchen eure Vorschlaege zu interpretieren?

Ihr meint also (so etwas aehnliches hab' ich oben schon mal' erwaehnt....:

Eine eventuelle Idee waere gewesen, den Gliederungseintraegen links je eine ID zu vergeben. Anhand dieser IDs koennte ein Agent den jeweiligen SELECT-Command (welcher eben einer bestimmten ID zugeordnet ist) ausfuehren und somit zur Laufzeit eine View befuellen... (wenn das technische ueberhaupt moeglich ist)

----

Ist jetzt eurer Ansicht nach die bessere Loesung einfach eine View zu erstellen, welche dann durch einen Agenten befuellt wird, oder?
Meine Idee waere ja gewesen, den Agenten ueber die Gliederung mit Infos zu fuettern - ihr meint jedoch, ich koenne die Gliederung durch einen Agenten ersetzen? (Das verstehe ich jetzt ehrlichgesagt nicht ganz...)

Das Leserfeld der Zugangsbeschraenkung muesste ich dann auch einfach dem Agenten in dem Search-Aufruf mitgeben um eben nur die erlaubten Datein abzurufen?

Lg

[Peter Klett]

Zum Leserfeld: Das Leserfeld muss in die Maske, damit wird jedes Dokument davor geschützt, von Unbefugten gelesen werden zu können (verwende z.B. Deine Rollen dazu).

Zur Gliederung und den Ansichten per Agent: Wenn die Anwendung nur im Web betrieben wird, kannst du doch das dazu notwendige HTML per Agent erstellen lassen. Kein Browser kann Notes lesen, sondern die lesen alle nur HTML (und JavaScript usw.), und der Notesserver generiert das.