We are using SharePoint 365.
In a Document Library, when we change the metadata (Properties), the date-modified in Windows Explorer (OneDrive-connected to SharePoint) will change.
In my mind, metadata is a layer on top of the document, and hence changes in metadata should NOT change the modified data of the file.
Is my logic totally wrong ??
Best regards
It is normal.
“Metadata” is the term used to describe additional data that gives information about your files. Metadata that you may already be familiar with includes “Created Date”, “Modified By”, “File Size”, “File Type”, etc. Also "Date modified" (called "Modified" in a SharePoint library) is metadata, which will be changed automatically when other metadata is changed.
Related
I am trying to insert the version number stored in SharePoint Online into my Word document - I've done the following thus far:
Activated the Library and Folder Based Retention Site Collection feature
Checked "Enable Labels" in the Information Management Policy Settings for the Document Content Type, and entered "{Version}" into the Label format field
Created a Word document in my library
Opened the document in Word, and inserted a Quick Part (Document Property > Label)
What shows up on the document is {_UIVersionString}, not the actual version number. Not sure what's going on - it seems so close.
In my test, I cannot reproduce your problem.
I can display the correct version number in the document. Below is a screenshot of my test:
This may be caused by the cache, I suggest you to clean up the cache of the SharePoint page and Office first.
You can provide your detailed screenshots, which can help us solve the problem better.
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
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.
Is there a programmatic way to differentiate between an addition of a New document and the Upload of a document in a Document Library? (Moss 2007)
I want to make a document upload raise an ItemAdded event only after some required fields have been filled, by default it is raised as soon as the upload itself is done by browsing to the file and clicking OK...
Thanks
You may be able to check the before and after properties of the ItemAdded event, but I doubt there will be a reliable difference.
I am afraid this is very hard to do programmatically because
When a document is uploaded using New, there is only a create event
When a document is uploaded using Upload, there is a create event when the file is uploaded and an update when (and if) the properties are updated. But the properties are updated with a system update so the update event does not fire.
After the document is added I agree with Nat that there will be no reliable difference.
But Jon Powell wrote an article how to separate between New and Upload with help from a workflow in the following article. You could do the same by adding your required logic in that workflow.
Hope this helps,
Henrico
Assuming that Major Versioning is enabled for the Document Library,
Doc Lib Settings > Versioning Settings > Major Versioning
The follwing values can be used to find out if it is the first version in the ItemCheckedIn event,
properties.ListItem.Versions[0].VersionID
(512 is the value for the first
Version )
properties.ListItem.Versions[0].VersionLabel
("1.0" is the value for the first
Version)
Note-Verions[0] stands for the current version.
This way one may do the ItemAdded functionality in ItemCheckedIn event receiver.
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.