In a MOSS 2007 / Office 2007 environment I am having spotty results with SharePoint properties updating in a Word document. Using an Information Management Policy, I define a Label Format:
Version: {Version}\n Effective Date: {MyModifiedDate}
I add a label to the footer of the Content Type template.
When I create a document based on my configured Content Type, check it in and then look at the document, the footer doesn’t always update. This is especially true the first time I check the document in.
If I just use Version the label updates as expected, but when I use other properties the results are inconsistent.
Everything I read makes it sound simple, but in our case it is unreliable, therefore not production ready. Do you have any experience with this would share or could you point me in the right direction?
Related
I have one template from which I'm trying to refresh the design in my database.
However when I run "load design -f database.nsf" or select "Refresh design..." in the context menu in the Domino Designer it always skips the same design elements when updating.
There doesn't seem to be anything wrong with the settings on database level since some elements are updated properly. But I don't know of any other setting on element level than "Prohibit design refresh" that would result in this behavior. If I delete all forms in the database and refresh design again, only those elements that aren't skipped are added to the database.
I have tried creating new copies of database and template, compact, fixup, updall.
Ideas anyone?
UPDATE 1
Checked my elements (forms) access settings like Knut Herrman suggested, but this doesn't seem to be the issue either. The settings on the access tab is "All readers and above" and "All authors and above". (Would have posted picture, but sadly I don't have enough reputation)
UPDATE 2
Tried deleting all elements in the main database and refreshing after with the result that it skips the same elements as mentioned above.
UPDATE 3
I have uploaded a small example with a one template and one database, and only two forms for design elements, if someone wants to check it out. One of the forms is updated on Refresh, the other is not.
If I use Replace instead it works fine btw.
There is an issue with a Language setting that was applied to FormOne in your example database. I think the refresh is ignoring elements in the template that it does not think match your current language.
When I looked at the fields tab in the FormOne design properties, I saw an item called $BabelInfo. This item does not exist in FormTwo. My hunch was that this has something to do with Language settings, so I went looking for the Language settings in Domino Designer. I couldn't find them in the regular dialogs and editing panes! But when I looked at both forms in DXL¹ there was a Language property set to EN-gb for FormOne, and there was no Language setting for FormTwo.
Using the DXL editor, I removed the Language setting from FormOne. On first attempt, this had no effect, but then deleted FormOne from the database - which I presumed had inherited the Language setting, though I'm not sure I checked that. I did a refresh and it added FormOne to the database. Then I made another change to FormOne in the template and refreshed again, and FormOne in the database was correctly updated.
¹ I had to search around before I figured out how to get at the form data in DXL. A right click in the forms list in navigation pane brings up "Edit in DXL". That option is not available in the list of forms in the main pane.
Most likely, your missing design elements need a certain role.
Define those roles in your destination database's ACL and set the roles for you, your servers and relevant users.
It could also be the dates in the main and the template database, that somehow the element in the main db is newer.
Quick solution: delete the element in the main database and refresh it from the template.
This might seem rather obvious, but double-check that the "Prohibit design refresh or replace to modify" property is not selected in your design element properties, i.e. there should be no ticks in the column highlighted in the image below if you want all elements to refresh.
I suspect this may not be the solution, as you said Replace is working, but I thought I'd mention it.
I am having a page with documents loaded in SharePoint 2010. I have three buttons below each documents in the page and they are 'Like','Unlike' and 'Comment'. So whenever people go there and see the documents they can click on any buttons of their wish.
My question is how to take the hit count of these buttons seperately and display it for each document. Is it possible to create a list with having these three columns and handle it using Client-Side scripting. Any suggestions or help is much appreciated.
Each item in SharePoint has a property bag that can contain ad-hoc data like this. You could certainly add additional columns to store this data and update those columns but that does mean that users could easily manipulate the values via the UI. Since the property bag is only accessible via the various API's, you wouldn't have this issue.
For an example of accessing the property bag via CSOM (which would be your best option since I'm assuming you want your users to be able to like, unlike and comment without refreshing the page each time), see this post reading and writing property bag values using CSOM
Another thing to consider for comments is the existing notes functionality that exists in SharePoint 2010 and SharePoint 2013. These comments are ties into the social functionality and may give you a bit more bang for your buck. To show the comments page for a particular list item see this post SharePoint Social Data using Javascript
I have a SharePoint document library I am working on. It has a list of document sets. Each document set has a few fields that are marked as "Shared" so that they can be inherited by the documents inside.
When I upload a document inside a form opens and all the fields on the form are pre-filled with the shared values of the corresponding columns. But when I use create document from template, it opens the template in the corresponding Office application but the document property fields are empty and not read-only which is against the requirements of this project. I require them to be synced and filled exactly like when a document is uploaded.
There is one thing though. The user can fill any value he wants in those fields and they will still be saved a synced copy from parent in the library discarding what the user filled in, which is good, but why not show those values up in the document in the first place?
Anyone has experience in handling this please help. I have searched a lot on the internet but either my keywords are wrong or no one has had this problem before.
SharePoint version: 2010 Server
Office version: 2010 Professional
It sounds like you need a simple event reciever, which fire on itemadded. It would then go back up the tree to find the document set. Capture which properties are marked as shared. Adjust the item that is being added to force the values.
Probably 8 lines of code
I'm trying to work out a way to display the contents of the version column from SharePoint (i.e. the value that changes every time a file is checked in) as a field (or something similar) inside of a Word document.
Ideally, I'd like to know how to configure SharePoint so I could click something like "Insert > Quick Parts > Document Property > Version", and it would include the version in the document. The goal is to make it easier for someone to correlate a printed version of a document with the version history of SharePoint.
I have been able to add editable text columns to the Document content-type and have them show up as document property quick parts. I've also been able to add a calculated column which gets the version as a text string... however this calculated column isn't showing up in Word as a document property. (Perhaps I'm missing a setting on the calculated column)
This is one way to get the version in your document, it's a bit painful to get it working...
Enable versioning and content types on your document library.
Go into document library settings and select the content types you want the version to appear in.
Select Information management policies settings from the content type menu.
Select define a policy and click .
Click on the 'Enable Label' Check box
Do not Check the other two boxes in the Labels section.
In the Label Format field, enter the metadata fields in the following format:
Version : {Version} \n
Set the label appearance and click on preview.
Click at the bottom of the page.
Go back to the library and create a new document using the content type you have modified.
Save the file as a Word 2007 format.
Select the insert tab
Select Quick Parts from the Ribbon menu and hover over document property
Select Label from the properties list
This should display the metadata defined in your label as a field in your word document. The field will update automatically when you next open the document.
Save.
This requires configuring both SharePoint and your Word document.
TO CONFIGURE SHAREPOINT'S DOCUMENT LIBRARY:
Go to the document library where you plan to store your version-controlled documents.
Click on Settings > Document Library Settings
Click on "Versioning settings" and make sure that you're either having it "create major versions" or "create major and minor (draft) versions".
Click OK.
Click on "Information management policy settings"
If your library can handle multiple content types, you'll see a list of them. Click on "Document". If it can only handle one content type, skip this step.
Select "Define a policy..." and click OK.
Check the "Enable Labels" box, but don't check either of the other two boxes in that section.
Type {Version} into the "Label format" box.
(Optional) You can format the version label.
Click on the "Refresh" button to see a preview of your version label. It will say something like {_UIVersionString}
When you're satisfied with the label's appearance, click OK.
To get back to your document library, click on the document library's name in the breadcrumb trail at the top of the page.
TO CONFIGURE YOUR WORD DOCUMENT:
Either create a new document in the library or upload one.
Open the document and edit it.
Put the cursor wherever you want the version label to appear.
Go to Insert > Quick Parts > Document Property > Label
The version label "{_UIVersionString}" will show up in the document.
Save the document (and choose what the next version should be). You're all set!
If you want to test it, close the document and reopen it. The updated version will automatically appear where you put the version label.
These instructions were based on Erwin's answer.
I followed Rachel's instructions and they worked great. However, capturing this version update in the document does create a problem if you want to do electronic signatures. For instance, if your version is 1.6 and you decide this is the one for people to sign; you'll find that when they sign it, the document will be saved as version 1.7. When you open the document again, the version 1.7 will not match the authorized version of 1.6 and you'll be informed that all the signatures are invalid.
IMPORTANT:
In SP2010 you cannot save as a site template when Labels are enabled within a document library under Information management policy settings. The document library will get corrupted and even if we disable the policy, the save as site template function is still broken. The only option seems to be to permanently delete and rebuild the list.
The RevNum field that I think jaloplo is referring to is not the same as the SharePoint document version number. It updates every time you save the document, but seems to keep its own revision numbering system, correlated to (but independent of) the SharePoint version numbering system.
Try creating a calculated field in a custom content type. The field can be equal to the Version. That will give you the ability to add it as a property in the document. This only works well with Office 2007 docs.
Once a custom content type is created, you create a new document based on the content type.
After creating the document, you can extract the document information panel and save it. It is an info path form, so you can customise it if necessary and upload the customised panel to the content type.
Erwin's answer is spot on, but I wanted to leave this in case someone runs into the same issue I did. If you attempt to set the label for version on the site collection content type rather than at the document library level, you will get the error "The label reference, Version, could not be found." when previewing or saving the Information Policy. Also, you will be unable to save a policy at the document library level if you have previously defined one at the site collection content type level. It must be set to "None" on the site collection content type. Probably should have been obvious to me from the start, but it wasn't, and maybe this will help someone else down the line.
All columns of a document library are document properties for a word document. To take the version of the document you have to show document properties and then select "advanced properties". In thit moment, you'll see the classic document properties window and you can see the "Version" property in the last tab.
So, you can add the value of this property to your document in the place you want, for example, the footer.
Is there some definition around the attributes that are returned from the Lists.GetListItems? I am able to view the attributes retuned just fine but I am wondering if they would ever change?
Here are some examples of what I am seeing... #ows_Author, #ows_FileDirRef, #ows_PermMask
I would like to build some classes around these values and my concern is that if they are not published somewhere Microsoft may up and change them or some setting in Sharepoint may.
It is possible that they change as sharepoint (major) version changes. Every change is possible then.
Don't think it would happen in minor version.
However they may also change depending on what list you query. But fields your mentioned and many other fields are basic fields that every list will contain.
If you want to view field data yourself (for example, what Type they are), download Sharepoint Manager - it's invaluable tool for a developer.
These are internal field names for default SharePoint fields. Unless you explicitly change them, they will remain the same.
Micheal Yeager's blog has a table which describes these fields and their data types:
http://blogs.msdn.com/michael_yeager/archive/2008/11/03/reference-list-for-internal-field-names.aspx