Berechtigung Incomming Email

Christian Groß Als Antwort am 6 Dez. 2011 12:05

Im Standard gibt es leider so eine beschriebene Funktion nicht. Eine deaktivierung auf einer einzelnen SiteCollection ist mir auch nicht bekannt.

Eine mögliche Lösung wäre die Programmierung eines Features, dass mit einer HideAction das Konfigurationsmenü aus dem Listekonfigurationsdialog ausblendet. So sieht der normale Anwender diesen Link nicht mehr. So könnten Sie durch die Aktivierung des Features alle Incoming E-Mail Options Buttons in der SiteCollection ausblenden, bei deaktivierung könnten Sie dann für die Bibliothek die E-Mails für die Bibliothek einrichten.

Gruß
Christian Groß

Jürg Schenk Als Antwort am 16 Dez. 2011 10:51

Herzlichen dank für die Antwort. Ich werde mich mal umhören was eine Entwicklung eines solchen Features kostet.

Sigi Weber Als Antwort am 16 Dez. 2011 11:25

Hab vor kurzem genau so ein Feature gebaut mit dem man auf SharePoint Website (nicht jedoch Listen) Ebene die E-Mail Funktion nicht nur ausblendet sondern auch den direkten Aufruf der Einstellungsseite verhindert (sonst kopiert sich ein Schlauberger die Url von einer anderen Stelle).

Das erforderte etwas mehr Aufwand als nur per SharePoint "CustomAction" den Link auszublenden, ist aber effektiver. Gedauert hat der Spass ein paar Stunden und ist sogar (weil mit Code implementiert) in der Lage für bestimmte SharePoint User/Gruppen den Link freizugeben (über einen Eintrag in der web.config).

Bei Interesse helfe ich hier gerne solch ein Feature zu erstellen.

Jürg Schenk Als Antwort am 23 Dez. 2011 09:24

Das klingt super, nehmen Sie doch mit mir Kontakt auf um die einzelheiten dieses Feature zu besprechen.

Hier mein Daten:

Name: Jürg Schenk
Email: juerg.schenk@bechtle.ch
Tel: 041 783 88 16

Christian Groß Als Antwort am 23 Dez. 2011 18:45

Hallo Jürgen,

ich denke die Kombination aus beiden Lösungen wäre die optimale Lösung. Eine Hide Custom Action in das bestehende Feature zu implementieren dauert geschätzte 10 Minuten.

Gruß

Christian Groß

Sigi Weber Als Antwort am 23 Dez. 2011 19:07

[quote user="Christian Groß"]

ich denke die Kombination aus beiden Lösungen wäre die optimale Lösung. Eine Hide Custom Action in das bestehende Feature zu implementieren dauert geschätzte 10 Minuten.

[/quote]

Auch wenn es schnell geht, bin ich davon abgekommen mit Hide Custom Actions zu arbeiten weil sie einige Einschränkungen mit sich bringen. So verstecken sie z.B. nur den Link im GUI, lassen aber den direkten Aufruf der dahinter liegenden Url zu, so dass schlaue User sich diese auf anderen Wegen besorgen und benutzen können.

Ausserdem kann mit einer Hide Custom Action keine zielgruppenorientierte Steuerung vorgenommen werden, der Link ist dann halt fuer alle weg auch z.B. den User der Mitglied einer Autorengruppe ist die ihn evtl. sehen soll.

Nebenbei bemerkt funktionieren Hide Custom Actions nur eingeschränkt auf dem "Site Actions" (ich sag nur Publishing Features) und "Welcome" Menü.

Daher implementiere ich solche Funktionen mittlerweile nur noch per Code.

Ich will hier niemanden über den Tisch ziehen, sondern nur mal auf all die Probleme und Limitationen mit Hide Custom Actions hinweisen.

Just my $.02 US

Christian Groß Als Antwort am 24 Dez. 2011 22:52

Deine Aussage zu den HideCustom Actions ist richtig. Wenn man mit einem Http Handler beim Aufruf der Seite Code ausführt, so dass nur berechtigte Personen diese Seite aufrufen dürfen, dann ist das wahrscheinlich die beste Lösung.

Natürlich muss diese Lösung dann auch so programmiert sein, das andere User keine Fehlermeldung oder eine Access-Denied Meldung bekommen. Das erfordert dann natürlich wieder etwas mehr Aufwand, als nur eine Hide Custom Action.

Und da kommt dann wieder das gute alte Geld ins Spiel.

Wie gesagt, ich denke wir haben zwei Lösungen gefunden und die Vor- und Nachteile erläutert. Nun kann man sich eine aussuchen.

Gruß

Christian Groß