Is it possible to manually add and modify the versions of a document using the object model?
As example I want to be able to get the SPListItemVersion object of a document and modify its properties. It seems to me that all properties are read-only, so it is not possible to modify anything.
Is there any workaround for this availalbe? I need this functionality for importing multiple document versions.
When I implemented an option to move documents between sites, a similar problem came up. What you can is push versions into the item.Versions array, and I found an online sample at http://www.k2distillery.com/2009/10/copy-splistitemversion.html
Look for the //loop over the soureitem, restore it comment.
Related
I am creating a blog site but i would like to add the feature to have history for a blog what changes are been done in previous version and latest version. Creating a separate history collection will be one approach but what about the document do i need to just copy the document of old revision in history collection or the just the json diff . If we just store the diff of field what will be the base object to construct the upto date document till that revision if we wish to query document with specific revision suppose (__version: 15) and current version will be somewhere 25.
I'd go with your first option, using a history collection, since it would be easier to fetch an entire document than keeping lot of diffs and then having to sync them all together. Also, having a different collectiont would be a faster solution, since you wouldn't need to fetch for different versions, assemble them and display it.
But on the other side, if you just want to show minor changes, like on facebook when you edit a comment, I think the diff approach would be the best option, altough you'd have to keep references on where and what has changed
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.
I have a method which downloads sharepoint documents to the local disk. I use SPFile.OpenBinary() method to get physical file, but it contains all fields of a parent DocumentLibrary. Does anybody know how to clear file (doc file) from these fields? I found only way to do it using Word interop library (method described here http://maxim-dikhtyaruk.blogspot.com/2009/05/trim-sharepoints-documents.html), but it doesn't fit my requirements cause it works only when Microsoft Office is installed on the machine...
You may want to read this to understand whats going on.
I do not know if this can be turned off or not, but it happens only with Word 2007 documents (docx).
You could do any of the following to turn this off:
Create a new content type and associate it with a document library. Use this document library from now on.
Look into some Open XML library or the Open XML SDK published by Microsoft.
This isn't a bug, it's supposed to be a feature! :-) Seriously though, you need to edit the Word document programmatically to remove these additional fields completely (I think even a content type will leave some behind).
For documents prior to Word 2007, you could use a toolkit like Aspose. I almost needed to do a similar thing once and would have used this product to do it. I'm sure there are other options out there.
For Word 2007 and higher, as SharePoint Newbie says, you should be able to use the Office Open XML formats to edit the document. Here's an MSDN intro article.
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.
In Sharepoint document library, when we create a new document library, the default view is 'All Document'. This one:
We can make a custom view from View > Create View (at the upper right corner of document library view). I created a new standard view and named it 'Chromed View'. I edited it, then I saw that this view only applied on current document library:
The other document libraries cannot use this view.
I develop a system that triggers document library creation from CRM (the document library's view from CRM Iframe is using that chromed view). The creation itself went well, I can create document library using Sharepoint web services. But I still cannot apply a custom view automatically for that newly created doc lib.
My question is, can we make a view that is global (not in one document library only) so that we can use that global view for any document library.
Thanks b4 for any opinion :)
You could also create a new custom document library type, with the view embedded in it. Whenever a new library is created from the new doc lib type, it will get the new view.
This is still a not truly "global" view, and you may have the same problems if the view gets changed (the view won't be updated on document libraries that have been created with previous versions of the view).
One way to do this is to create a feature with an event receiver. When a user creates a list, you can check if the list is of the proper type (101), and then add new views to it. The feature could also add this view to existing document libraries on activation. Shouldn't be too much of an effort.
The view is not truly global. As list definitions are duplicated for each instance, there are no such thing as a global view (afaik) in WSS. We could all hope that views are a part of content type in the next version.
To globally change all document libraries and to change all existing libraries you need to edit the XSLT file that is in the XSL folder in layours/templates
There are a couple of them in there but these are how all the libraries are generated with this u can basically specify how a default"" library would look. Make sure to make a backup for these files though. Also creating a new content type and copying these xlts to a different file name and then linking your content type to these instead could also be a solution so when a user creates a new library using ur content type you can make sure that they are created in a way that you want.