Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
DiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWord
DirectoryUser Groups
Related Topics
Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ...

MS Office Forum / General MS InfoPath Questions / January 2007

Tip: Looking for answers? Try searching our database.

Problems with SPListItem.moveTo() method

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
christoph.hanser@googlemail.com - 25 Jan 2007 14:35 GMT
Hi!

We're having problems with the method SPListItem.moveTo().
A InfoPath document and stored inside the a SharePoint library.
Afterwards, it is modified using a workflow that runs inside the
Workflow Foundation. This workflow makes some changes inside the
document and stores it in another SharePoint library. There, special
permissions are set to enable different users access to the document.
In the end, the document is moved back into the original library. The
document is not stored immidiatelly inside the original library in
order to set the permissions. The code looks like this:

               Dim mst As New MemoryStream
               Dim sFilename_1 As String = it.ParentList.Title &
"_Temp/" & sGuid & ".xml"
               Dim sFilename_2 As String = it.ParentList.Title & "/" &
sGuid & ".xml"
               xmlout.Save(mst)

               Dim file As SPFile =
it.ParentList.ParentWeb.Files.Add(sFilename_1, mst, True)

               ' Berechtigungen initialisieren
               Berechtigungen_Initialisieren(file.Item)
               ' Berechtigung für Rollenmitglieder setzen
               Berechtigung_Setzen(file.Item, ds)

               file.MoveTo(file.ParentFolder.ParentWeb.Url & "/" &
sFilename_2)

It works really good as long as the administrator of the machine runs
the script. However, when other users run the process, an exception is
thrown when performing the MoveTo() method:

bei Microsoft.SharePoint.Library.SPRequest.MoveUrl(String bstrUrl,
String bstrWebRelOldUrl, String bstrWebRelNewUrl, Int32 grf)
  bei Microsoft.SharePoint.SPFile.MoveCopyInternal(String strNewUrl,
Int32 grf)
  bei Microsoft.SharePoint.SPFile.MoveTo(String newUrl,
SPMoveOperations flags)
  bei Microsoft.SharePoint.SPFile.MoveTo(String newUrl, Boolean
bOverWrite)
  bei
eav_workflow_functions.WorkflowFunctions.Einzelantrag_Speichern(SPListItem
it, XmlDocument xml, String guid)

It seems that they do not have the right to overwrite the document.

How can we give all users theses rights?
It does not help to grant them "full access" (Vollzugriff) in
SharePoint.

Also, the idea to run the Update() Methode came to our mind... However,
this works only for list libraries and not for form libraries.
Bruce Sandeman - 25 Jan 2007 14:48 GMT
Hi Christoph,
I had some issues around a similar sort of thing and ended up writing some
code that worked around this kinda issue.  It's in C# but hopefully not to
hard for you to convert to VB.
Please see my blog entry at http://blogs.officezealot.com/bsandeman/archive/2006/12/04/15453.aspx

hope this is of some help
cheers
Bruce
christoph.hanser@googlemail.com - 25 Jan 2007 15:59 GMT
Hi Bruce,

thanks for you help. The difference seems to be that you are using
Encoding.ASCII.GetBytes() instead of the MemoryStream, that we are
using....

My colleague will change his codings and afterwards I will tell you
whether it helped.

Thanks a lot!

Chris

On Jan 25, 3:48 pm, Bruce Sandeman <b...@deltaschemenospam.comnospam>
wrote:
> Hi Christoph,
> I had some issues around a similar sort of thing and ended up writing some
[quoted text clipped - 5 lines]
> cheers
> Bruce
christoph.hanser@googlemail.com - 26 Jan 2007 11:12 GMT
Hi Bruce,

unfortunately, the GebtBytes() "trick" did not solve the problem.
However, we could find out in more detail what the problem is: The
workflow fails to change the InfoPath document after it has been
changed in InfoPath by another person.

The workflow is like this:

First, the InfoPath document is written by a user and published in
SharePoint.
Second, this document is taken by the workflow and new forms are
created and stored in SharePoint.
Third, a person (the user's chief) approves these new forms. His
decision is stored in the form.
Fourth, the workflow takes these forms.

Now, the workflow can read the form, but it can't make any changes to
it.

We granted the document's access rights so that the user, that runs IIS
(and, thus, the Workflow Foundation, we assume), always gets full
access to each document.

However, the problem is still there, and documents which have been
changed by some other user in InfoPath can't be overwritten by the
Workflow Foundation.

Does anyone have a clue about this?
Or knows how the rights have to be granted exactly?

Thanks!
Christoph

On Jan 25, 4:59 pm, "christoph.han...@googlemail.com"
<christoph.han...@googlemail.com> wrote:
> Hi Bruce,
>
[quoted text clipped - 21 lines]
> > cheers
> > Bruce
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.