das Thema der temporären Freigabe beschäftigt uns schon länger, bisher jedoch ohne stabile Lösung.
Ziel ist eine Freigabe unabhängig vom aktuell angemeldeten Benutzer. Aktuell ermitteln wir die Root-ID (StrFromUserId) und rufen anschließend den Server-Job CreateCollaborationDocuments auf.
Dabei wird jedoch weiterhin der angemeldete Benutzer geprüft, obwohl from_user explizit gesetzt wird. Die Freigabe funktioniert daher nicht wie gewünscht.
Unsere Fragen:
Gibt es eine Möglichkeit, dieses Verhalten zu beeinflussen oder zu umgehen?
Kann bei CreateCollaborationDocuments-Job statt des aktuellen Benutzers auch ein technischer Benutzer als from_user übergeben werden?
Falls ja: Kann diese Logik innerhalb des Server-Jobs dynamisch entschieden werden, zum Beispiel abhängig davon, ob der Aufruf aus einem Workflow stammt?
Da der Job auch im GlobalClientScript genutzt wird, möchten wir keine globale Änderung vornehmen.
Zusätzlich haben wir wegen externem Hosting nur eingeschränkte Analysemöglichkeiten und finden dazu nichts in der Doku.
Hat jemand hierzu Erfahrungen oder kann eine technische Einschätzung geben?
Vielen Dank für eure Unterstützung!
Ich habe es mit dms.CreateCollaborationDocuments nicht ausprobiert, aber ich denke einerseits, dass das es möglich ist, dass der from_user einfach nicht beachtet wird, wenn der nicht zum Kontext des API-Call passt. Der Kontext kann bei der Server-API normalerweise gewechselt werden, indem man einen String-Parameter $$$SwitchContextUserName$$$ mitgibt, also in etwa:
Dim job: set job=oSession.NewJob("dms.CreateCollaborationDocuments")
job.InputParameters.AddNewStringParameter "$$$SwitchContextUserName$$$", "root"
[...]
job.Execute
Dazu benötigt der ausführende Login wiederum die Systemrolle 72/Server: Jobkontext wechseln.
Wie ist das genau gemeint? Wird in GlobalClientScript wiederum ein Server-API-Call gemacht? Leider sieht die API zwischen Client- und Server-Events immer etwas anders aus.
Zumindest im Server-Monitor bzw. in der Jobüberwachung im Enterprise-Manager kann man die unterschiedlichen Aufrufe provozieren und sehen, wie diese sich in den Parametern unterscheiden. Workflow-Events werden allerdings eventuell gar nicht angezeigt.
Ja, dms.CreateCollaborationDocuments ist nicht öffentlich dokumentiert und wird somit je nach Lesart von OS nicht direkt unterstützt. Bezüglich der Analysemöglichkeiten: Stehen denn der Server-Monitor oder Enteprise-Manager grundsätzlich zur Verfügung?