...
Beim Portal haben nun weitere Kunden das Bedürfnis, diese zweistufige Struktur abzubilden, so dass wir diese in den Standard übernehmen sollten.
Lösungsideen
# | Problem | Lösungsvorschlag | Entscheid | Hinweis |
---|---|---|---|---|
1 | Anzeige eigene oder der untergeordneten Kunden |
|
|
|
|
| Do | Die Steuerung der Sichtbarkeit des Vertreter-Attributs ist möglich über das Attribut Vertreter-Art. Somit tritt diese Unterscheidung nur bei den Teamleitern und bei Administratoren auf. Bei den ADM selber wäre diese nur verwirrend. | ||
4 | 2-stufig in Standard | Zwei-stufige Struktur in Standard übernehmen | Go | Löst uns das Problem, dass nicht alle mit Admin drauf müssen |
Lösung sollte so möglich sein über zusätzliche Views, anderen Rolleneinschränkungen und Konfiguration des zweiten Scopes
Lösungsweg:
Ist eine Kontext-Einschränkung mit einer Liste von IDs - Lösungsidee für Vertreter-Hierarchie: Ich sehe alle meine Adressen und die meiner n Untervertreter, somit eine IN-Klausel und beim Login wird nicht nur der aktuelle Vertreter in den Context geladen, sondern eine Liste von Vertretern | Erfahrung: ID ich selber oder wo ich der ParentID bin |
Offene Fragen
Wie unterscheide ich beim einem Teamleiter zwischen den eigenen und den Kunden meiner Mitarbeiter? → Suchspalte Vertreter im Scope
Sehe ich einer Adresse an, ob sie auch in anderen Bereichen aktiv ist? → Zusätzliche Spalte Adresse "Bereichsliste"
...