Vielfach im NAB checken ob User Mitglied der Gruppe XY ist

[case]

Hi,

dieser ähnliche Thread hat sich soweit seit heute gewandelt:
http://www.atnotes.de/index.php?board=7;action=display;threadid=9815;start=0

Es besteht seit heute der Request, dass in einer Datenbank-View nur die den jew. User betreffenen Doks angezeigt werden.

Randbedingung:
- In der Maske ("Standard") gibt es ein Feld "Betreffende Abteilung(en)". Hier übernimmt man Werte aus einer anderen View "AbtView" über @DBColumn. Die View 'AbtView' wiederum wird gefüllt über eine andere Maske ("frm_Abt"), die nur das Feld "Abt" enthält.

Möglicher Denkansatz:
Der Maske frm_Abt ein zweites Feld spendieren "Abt_NAB", in welchem eine Gruppe (oder mehrere) aus dem NAB eingetragen wird.

Wenn nun der User die gewünschte View - nennen wir sie 'Meine Abteilung' öffnet, soll Notes
- alle Doks mit der Maske "Standard" durchgehen, über Abt-Feld in der View "AbtView" nachsehen, was die zugehörige NAB-Gruppe ist
- dann im NAB nachsehen, ob User Member der Gruppe ist; falls ja: Dok anzeigen;
- dann weiter mit dem nächsten Dok und dasselbe prüfen.


Selbst wenn das so funktioniert habe ich das Gefühl, es könnte gut und gerne ein paar Minuten dauern, bis sich die View aufbaut, und die Admins freuen sich tierisch, dass endlich mal die Server belastet werden, wenn das mehrere User gleichzeitig machen......

Hat vielleicht wer eine performante Idee von Euch?
Vielleicht denke ich hier auch viel zu kompliziert und es gibt eine simple Formel dafür    (wär ja zu schön...)


Case

[ata]

... was du beschreibst macht man mit Leserfeldern und Gruppen, bzw. Rollen wenn man das mengenmäßig begrenzen kann...

Wer nicht im Leser- oder Autorenfeld steht, bekommt das Dokument schon gar nicht angezeigt. Userrecht ist in diesem Fall "Author"...

fata

[case]

Danke ata,

aber ich hatte leider noch vergessen, dass Leser und Autoren - Felder bereits vergeben sind.

D.h. ich würde eine zusätzliche Filterung benötigen. Lesen soll ja bei den meisten Doks die ganze Company dürfen, aber in der Ansicht "Meine Abteilung" sollen nur die abteilungsrelevanten erscheinen.

cu,
Case

[ata]

... das lässt sich entweder mit einer privaten View realisieren, oder mit einer Embeded View - eine "normale" Ansicht kannst du nicht zum personalisieren verwenden...

ata

[case]

Hi Ata,

danke. schon klar, dass personalisierte Views nur funktionieren, wenn diese embedded sind.....

Aber wie realisiere ich diese embedded View? Ich hab ja als Ansichtskriterium nicht einen Namen, sondern eine Abteilungsbezeichnung (z.B. Abt. Vertrieb).

In einer View wäre dann die erste Spalte "Vertrieb" und die 2. Spalte die Bezeichnung der NAB - Gruppe (z.B. "Aussendienst DE").

Ich schätze das ganze muss ich wohl dem Requester ausreden, ist einfach ein zu großer Akt. Ich werd ihm klarmachen, dass es reichen muss, wenn die einzelnen ABt. kategorisiert erscheinen......

Jedenfalls merci für Eure Hilfen.


Case

[ata]

@Case
... nicht so schnell aufgeben...

... wenn du je Abteilung ein Konfigdokument anlegst, dann nimmst du...

... ein Feld für den Abteilungsnamen
... ein Leser-Feld für den Gruppennamen
... ein Feld mit den Mitgliedern der Gruppe

in der Ansicht sollten dann nur die relevanten Abteilungen erscheinen - Vorraussetzung die rechtliche Situation lässt sich entsprechend einrichten...

... ein periodischer Agent aktualisiert dir die Mitglieder der Gruppe über das PubNames - dann kannst du auch noch nach den Mitgliedern sortieren lassen...

... mal so ins Blaue gedacht...

ata

[case]

Hi Ata,

danke für die Aufmunterung  

Ich habs jetzt soweit realisiert, nun muss ich "nur" noch einen Agenten schreiben, welcher mir regelmäßig die Gruppenmitglieder des Public-NAB rüberschaufelt. Die Daten kann ich gut gebrauchen, um evtl. später mal ein Organigramm in der DB abzubilden :-)

Zur Auswahl des Inhalts der embedded View hab ich folgende Formel verwendet:

_user := @Name([CN] ; @UserName);

@DbLookup ("":""; ""; "MyDept"; _user ; 3 )


Was meinst Du eigentlich mit

Vorraussetzung die rechtliche Situation lässt sich entsprechend einrichten...

?

cu,
Case

[ata]

... funktionierende Leserfelder setzten entsprechende Zugriffsrechte voraus...

ata