CreateRemoteDocument with using "File Upload" datasource

Question

Hi there,
I would like to upload new documents to the Knowledge Directory through PRC API. There is an IDocumentManager object which has a createRemoteDocument() method. It needs datasource ID as a parameter (besides folderID and URL of the document). I tried to use ID of the "File Upload" service which works correctly when I would like to upload to KD through Simple Submit, but in this situation (PRC API) it fails... Is there any way to upload documents chosen by using a file input field to the KD through PRC API ?
Thanks in advance,
Zsolt

Answer 1

LOL. Ross. :-) I'd never be passive aggressive. Overstressed and getting snowed/rained on, yes, but I love working with you guys. :) I honestly meant that as a question - our business needs doing a lot of extranet type of client facing interchange/communication really lends itself to a document upload process. For the more intranet type deployment where you can integrate portal::authsource::data source security and crawl upload is definitely less relevant. Let me just come out and say officially so there's no debate: Working with all of you (when I get the chance) really is a highlight of my day. The fact that I know so many of you by name when I generally can't remember what I had for lunch should tell you something. ;)
"Can you explain how you want to edit the doc? Are you thinking fetch, modify, and reupload? Editing the properties as you would for any knowledge directory doc or something else altogether?"
You should be careful asking a question like that... People have been asking for:* provide the ability to upload content in portlet xyz that does business function xyz. (in our case we have a legacy workflow portlet that allows a user to submit a document with specific meta-data [not stored in properties...yet] and an established routing list. The document is uploaded to the portal, a card created, and the workflow process continues on its merry way. If the workflow is cancelled or a specific step rejected the process concludes and the requestor can elect to submit another copy of the document for review in another workflow instance)* Uploaded content should be presented in the knowledge directory (we actually upload it to the knowledge directory then dynamically add/remove security to allow access as the document moves through workflow)
...we have multiple outstanding requests to provide this kind of functionality in many portlets.
The way I'm seeing things is this...* The knowledge directory is an aggregate presentation of multiple data sources / content stores* The knowledge directory can present content stored in the document repository data source* The document repository handles naming collissions, object storage, and retrieval* Short term I'd just like to have an API that would upload a piece of content into the document repository. Editing would be huge, but I understand that's a much bigger deal (I will say I'm really impressed by Collab's ability to do this, btw)* I would assume property editing/management would stay as is - I see no issue with modifying properties either from the UI or from code...with one exception. I still don't understand why I can create a list property (call it "month"), append it to a document, and then when I go to edit the document properties it actually shows up as a free-entry text box. Shows up as a list (the one I created) on every other object type but document. Means it's hard to use the built-in portal UI to consistently tag information...ick.* Long-term I'd like to be able to modify knowledge directory items from the document repository data source ala what Collab 4.x does - editing in place. I understand this is likely a much nastier issue and also needs to be thought through completely, but our users do not seem to grasp the reasoning behind why you can edit community documents in place, but not edit knowledge directory uploads. I can't honestly envision myself streaming data into the object from code in this context (although that would be interesting) - I would really just like the portal UI to let end-users "edit" a document in place as Collab does.* Even longer-term ... I know the next logical feature users will ask for is content Versioning. Bigger ticket item, I know. Knowing our users this would probably be a burning request the moment you let them edit in place, but honestly - just editing in place and knowing you don't get to version the content would be a huge in.
That help at all? What more can I do to assist?
Thanks,Eric