When we have a client that requests a call back, we fill out a web form that automatically populates an excel spreadsheet on a shared drive. Reps will then access the spreadsheet and take appropriate action. A single record can inadveretntly generate three calls from different departments. We're desinging a forms-based callback system, and in the interim, need to use the spreadsheet for tracking.

Let's suppose I move the spreadsheet into a SP library. How does the appliation doing the updates handle SP permissiosn? How do I grant permissions to an application? Does the application do checki-in and check-out like a human user? When a rep goes into the document, they need to be able to add the callback results, so I need to have access to write to the newly created file. In short, how de we ensure that in a SP environment, an external app can write to the file, the leave the file editable to casual users.

I'm not quite sure how to do this...or if it's difficult enough that I make the users live with the cumbersome process for the next 9 months or so... :)

1 Answer
1

I'm assuming the application will be running either under some person's ID, or an ID will be created just for that job. In either case, you'll have some ID that you can ensure has permission to access the file so that the job can access the file.

For check in/check out, it could just be disabled entirely. I know when I have document libraries that are primarily access via batch jobs I tend to just turn it off because they're not really working on files as "drafts" for extended periods of time, and there tends to be few concurrent users. Is that an option for you? Additionally, are the jobs that will be accessing the files already written, or are the going to be modified? If you have code running in the server/client object model there are methods for fairly easily checking documents in/out, but if you're relying on just web services, an http PUT/GET, etc. then it's often harder to deal with checking in/out.

I'll investigate how that application runs ID wise. I'm not really sure how that's configured. Turning off check in/out would be ideal; that would work perfectly for us. Especially if that attribute could be switched off for ONLY the ID running the app. Where's this setting live? I've never run across it. Thanks!
–
dwwilson66Jun 8 '12 at 14:30

@dwwilson66 List settings -> versioning settings should have what you need. At the bottom there's a "Require checkout: yes/no" option. There's no good way (that I know of) to turn it off just for a certain user, no.
–
ServyJun 8 '12 at 14:33

I suppose you could attach an event handler to the ItemUpdated event such that when it was edited, but not checked in, and if it was edited by the ID running the external app, then programmatically check in the file, but that would be a fair bit of work.
–
ServyJun 8 '12 at 14:34

since this a temporary solution until the new procedure and application get developed, "fair bit of work" = "I'll turn off versioning for the app-user" :)
–
dwwilson66Jun 8 '12 at 14:37