I have to programmatically move (archive) a document from document library of a site collection to a document library of another site collection in SharePoint 2010, when a specific value is set for a column in the doc lib.
Would it be possible to write code for this scenario in an event receiver? Is there any other way?
If anybody has any relevant piece of code or links, please share.
Thanks in advance!
You could perhaps do a copy operation, then delete the original file.
Have a look at the following link, which discusses copying a file from one site to another:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfilecollection.aspx
The example uses one site collection. However, if you convert the source document to a byte array you can always instantiate the target site collection and add the binary data to a document library within that site collection.
Certainly the copy operation should would work within the event receiver. However, I'm not certain what will happen if you try to delete the file within the receiver (there may be concurrency issues). If the delete does not work, consider firing a one-time timer job to delete the file (which would occur in a different process).
You can try SPExport Class of SharePoint, as per this Article Copy or Move SharePoint items looks like few of the Operations that we do in SharePoint UI uses this API internally to acheive the task. Also this Approach depends if you are trying to do it one time or its going to be a repeatative process.
Related
To preface: I believe this may be impossible with OOTB solutions and if it is I have a plan B, but this plan would be much easier to implement if it is indeed possible.
Is there any way to create a SharePoint workflow that moves a file from a separate document library to another separate library?
The workflow is launched when a new item is created in a list. The item contains the information needed to find the document that it's referencing (ID, path, folder path, name etc...). Is it possible to take this information and then move the file being referenced to another library using a SharePoint workflow?
The document can't be simply copied because version history must stay with the document. I'm also unable to run the workflow in the library that contains the document because it's deciding on what documents to move based on the last modified date and as soon as the document is touched by the workflow it's been modified.
If you only want to copy files with metadata, we can use the OOTB workflow to achieve it.
If you want to copy files with version history, please check the Nintex workflow.
Nintex Workflow Move Document and Preserve Version History
Or we can create event receiver with custom code to achieve it.
Copy files between libraries by keeping versions
I have a problem with SharePoint 2013. I'm currently setting up a basic collaboration sceanario with SharePoint. I therefore created a basic document Library whith an additional folder derived content type to be used at the top level of the document library. This content type has some additional metadata. Inside of these specialized folders I want to use standard files and (sub)folders.
At first, I had no problem of creating elements and subfolders inside of my top level folders using the standard buttons (Upload File, New Folder) in the ribbon. However, now without knowing what caused this behaviour, when I try to create elements inside of existing folders, SharePoint always creates new elements at the top level of the document library.
Does somebody have an idea what might have caused this beaviour and how to fix it (without code)? I did not find any solution searching the web. Any Help is greatly appreciated. Many thanks in advance.
P.S. I know that using folders in SharePoint is not recommended in general but I would really like to understand what could have caused the described problem.
I need to migrate Work Items from one TFS server to another TFS server. I tried migrating them using the TFSMigration tool available in CodePlex.
The problem I am encountering is the schema for the work item on the source TFS is different from the schema of the work item type on destination. I don't want the destination TFS server schema for the work item to be modified. The change in schema is one new column only, but still don't want to take that change.
In one blog it was said that we can do that using Excel but not much details were available. I am not sure we can even use Excel to migrate the entire history related to Excel.
Have a look at the TFS Integration Tools on VS gallery. This supports custom field mappings as part of a migration, documentation here (direct download).
I did this a while back and, not finding an appropriate tool, resorted to copying the title and description etc across manually, as we only had a few active work items at the time, so it only took about an hour.
however, if I need to do it again, I'll use the TFS API to read fields of interest and write them to the new database. that way any schema differences don't matter, and the process is automated but under your control. Search for studying work items with the TFS API for details - it's really very easy.
Of course with both of these approaches (and all the migration tools AFAIK) you will only get a snapshot of the data - all history will be lost (or at best you can query using AsOf to get historical data, but all the entries you make will be timestamped at the moment you write them, not with the historical time that the event originally occurred.)
You can use the Excel editor to edit the source query All Items "Open Query in Microsoft Excel". Then open the destination query All Items "Open Query in Microsoft Excel". Copy and paste the contents from one excel window to the other. Certain fields like attachments will not transfer.
This is primarily a question of possibilities more than instructions. I'm a programming consultant working on a WSS project site system for my client. We have a document library in which files are uploaded to go through a complex approval process. With multiple stages in this process, we have an extra field which dictates what the current status of the document is.
Now, my client has become enamored with the idea of PDF watermarking. He wants the document (which is already a PDF) to be affixed with a watermark corresponding to the current status, such that with each stage of the approval process the watermark will change.
One method, the traditional method for PDF watermarking, of accomplishing this is to have one "clean" copy of the document somewhere hidden on the site, and create a new PDF from it that has the watermark at each stage of the approval process. Since the filename will never change, this new PDF can be uploaded continually to a public library, always overwriting the old version and simulating a "dynamically changing watermark". However, in the various stages there will also be people uploading clean copies with corrections and suggestions, nevermind the complex nature of juggling around two libraries and the fact we double the number of files stored. My client and I agree that this is not a practical path to choose.
What we would like to do is be able to "modify" the watermark in a PDF, so that we only have to keep one copy of the file. Unfortunately, from what I've seen, in most cases when you make something like a watermark, which in its nature is supposed to be "unmodifyable", you won't be able to edit it later. So, is it possible to have a part of a PDF which cannot be changed by anyone who downloads the file, but can be changed as part of a workflow or other object model process?
PDF Watermarking in SharePoint is a common request. I have written extensively on this topic. See:
Adding a dynamic watermark to a PDF file from a SharePoint Workflow
Adding a (static) watermark to a PDF file from a SharePoint Workflow
Use SharePoint Workflows to inject JavaScript into PDFs and print the ‘open date’
You could use Event Handlers such that code was run every time a document was checked in. In that code you could perform the fixup/check that made the watermark be what you wanted it to be. This assumes you can write code that manipulates a PDF's internal structure such that it has the watermark that you desire.
It sounds to me like you want to allow people to modify the PDF they download, but not modify its watermark. This is probably going to be nigh on impossible if the watermark is embedded in the PDF (afaict) but what if the watermark image is external to the PDF; is it possible to embed a watermark in a PDF that is sourced via HTTP? Then you could embed:
<watermark image="http://sharepoint/site/_vti_bin/docstatus.asmx?id=5">
Of course, I have no idea about PDFs, so this might not be possible but you get the concept.
-Oisin
It is possible to do so if you use third party tool. Then you can put dynamically binded value from your SharePoint metadata, conditions, rules etc: http://www.pdfsharepoint.com
One of our customers has a problem that we cannot reproduce. We programmatically copy a document's properties to a destination file using SPFile.Properties. However, for some reason the file's properties do not match the meta data specified on the list the file is stored in.
Now, we can probably solve this by copying SPFile.Item.Properties (not tested yet), but I am just wondering under what circumstances SPFile.Properties is unequal to SPFile.Item.Properties.
Update: We have just received an update from our customer. Using SPFile.Item.Properties always returns the up to date information. However, we still would like to understand the original question.
There is a slight difference between SPFile.Properties and SPFile.Item fields and the first one is much, much slower to call.
You have most probably seen Microsoft Office document's "properties" window (this one - http://dradisframework.org/images/tutorial/custom_document_properties.png). These are the properties that are read when you access SPFile.Properties. Reading them is slow since there is some code infrastructure that parses the binary DOC file and finds the properties. (takes up to 30 or something milliseconds for every property access) See more here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx
In SharePoint, every item is an SPListItem and its field values (and I don't use the word "properties" on purpose here) are stored in Sharepoint's content database. So, when you access SPFile.Item.Properties, you actually look at the SPListItem to which the file is attached and look at its properties from SharePoint's content database.
What happens behind the scene, when you upload a file having some "Office properties" set, is that SharePoint copies them to same-named fields in SPListItem. (Some information about it here: http://weblogs.asp.net/bsimser/archive/2004/11/22/267846.aspx)
This is why these properties typically have the same value, BUT it only happens if SharePoint knows how to read metadata from your file and write them back. So, in case you put a .txt file in your SharePoint store, you will not get any SPFile.Properties back.
The user will always see the ListItem Properties and not the SPFile properties in a document library. So using the ListItem properties in the copy is the way to go.
I believe this issue is related to the Sharepoint property promotion/demotion feature which enables document properties to be embedded in the physical MSOffice file and travel with it to the client etc. This however is only supported currently for Office file types (to my knowledge).
Jonathan
Trying to find the "official documented" anything for sharepoint is pretty much undoable. :-D. The online docs suck, you are better of using blog entries etc.
P.S. I agree with Alex here. Although an SPFile never exists in a list without an accompanying SPListItem, the connection between the 2 can get corrupted (i.e. being able to edit the list item but the file is not openable). This to me indicates information about the 2 is stored in different locations in the content db. I have had this happen before.