SharePoint 2013 wiki timeout

2013-07-09 Thread Ivan Wilson
The SharePoint 2013 wiki page won't save any changes after 30 minutes.

Steps to reproduce:

1.   Switch to edit mode on a web part/wiki page in the browser

2.   Type some content

3.   Wait 31 minutes

4.   Click Save

No error, but your text changes are not saved.

Change the security timeout setting in Central Admin - Web Application - 
General Settings from the default 30 minutes and you can affect the duration of 
this issue.

Has anyone else experienced clients losing all of their work on a wiki page 
because of this issue?
Any specific issues with setting the timeout to never?

Ivan

___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


Re: SharePoint 2013 wiki timeout

2013-07-09 Thread Web Admin
I saw it as a training issue and instructed users to save often, which in
my books is good practice anyway.

But I agree that some kind of warning could be provided.

Regards,

Paul


On 10 July 2013 11:16, Chris Grist chris.gr...@beachenergy.com.au wrote:

  Yes we have that issue, but its not 30 mins will have to see what its
 set to.

 ** **

 *From:* ozmoss-boun...@ozmoss.com [mailto:ozmoss-boun...@ozmoss.com] *On
 Behalf Of *Ivan Wilson
 *Sent:* Wednesday, 10 July 2013 9:25 AM
 *To:* 'ozMOSS'
 *Subject:* SharePoint 2013 wiki timeout

 ** **

 The SharePoint 2013 wiki page won’t save any changes after 30 minutes.

 ** **

 Steps to reproduce:

 **1.   **Switch to edit mode on a web part/wiki page in the browser **
 **

 **2.   **Type some content

 **3.   **Wait 31 minutes

 **4.   **Click Save

 ** **

 No error, but your text changes are not saved.

 ** **

 Change the security timeout setting in Central Admin – Web Application –
 General Settings from the default 30 minutes and you can affect the
 duration of this issue.

 ** **

 Has anyone else experienced clients losing all of their work on a wiki
 page because of this issue? 

 Any specific issues with setting the timeout to “never”?

 ** **

 Ivan 

 ** **

 ___
 This message is intended only for the use of the addressee.
 This email and any attachments are confidential and may
 contain legally privileged information or copyright material.

 If you are not the intended recipient, you are hereby notified that any
 use or
 dissemination of this communication is strictly prohibited. If you received
 this e-mail in error, please notify us immediately by telephone on +61 8
 8338
 2833 or by return email and delete the original message. It is important
 to
 check for viruses and defects before opening or using attachments. Beach
 Energy
 Limited accepts no liability for any damage caused by this email or its
 attachments due to viruses, interference, interception, corruption or
 unauthorised access. Thank you.

 Please consider the environment before printing this email.

 ___
 ozmoss mailing list
 ozmoss@ozmoss.com
 http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


Re: Migration issue

2013-07-09 Thread Web Admin
Version and absolute URL are not available as Quick Parts.

I'd create a content type and add a Version (numeric) field so people can
decide when this should change, rather than SharePoint.

For the file path you're going to have trouble though. Only way I can think
is to set a field's value via a workflow.

Both could then be added to a template footer as Quick Parts.

As for legacy documents...there's no way I know to update these easily. I
did see a batch XML converter around but I don't think it could handle
these kind of changes.

On 10 July 2013 06:49, Nigel Witherdin nigel_wither...@hotmail.com wrote:


 Hey guys,

 We are currently migrating content from from legacy doc mgmt systems into
 SP2010, and I have come across a sticky requirement.

 The doc mgmt system we are migrating from had a plugin to office that
 allowed the users to click a button and insert the file location and
 version number into the footer of the document. They like this
 functionality and see it as essential to exist in the new system.

 For docs created within sharepoint, no problem. I can have a doc template
 that uses quick parts in the footer to display the items URL and version
 number (I assume), but that doesn't help for existing docs that are
 migrated into SP.

 The other possible solution is to write a macro or customize word to
 provide a button that injects the required info into the footer (from the
 document's properties?), but I haven't really done anything like this
 before, so not sure how viable this is.

 What do you think, any suggestions on how I could solve this?

 Many thanks,

 nigel
 ___
 ozmoss mailing list
 ozmoss@ozmoss.com
 http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss

___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


RE: Migration issue

2013-07-09 Thread Nigel Witherdin
Would creating an Office plugin (a button) that injects the values into the 
footer from the document's properties be feasible?
I think I have gotten version number in a footer in the document template by 
creating it as a label in the Info Mgmt Policy for the doc's content type 
before (so it can then be used in the template), but this doesn't really help 
me for the existing documents.
My other solution is shudder an event receiver that embeds the info into the 
footer.
Oh - this has to work for DOCs and DOCXs.
Again, would appreciate your thoughts - thanks guys!

Date: Wed, 10 Jul 2013 11:41:00 +1000
Subject: Re: Migration issue
From: web.ad...@syd.catholic.edu.au
To: ozmoss@ozmoss.com

Version and absolute URL are not available as Quick Parts.
I'd create a content type and add a Version (numeric) field so people can 
decide when this should change, rather than SharePoint.

For the file path you're going to have trouble though. Only way I can think is 
to set a field's value via a workflow.

Both could then be added to a template footer as Quick Parts.
As for legacy documents...there's no way I know to update these easily. I did 
see a batch XML converter around but I don't think it could handle these kind 
of changes.


On 10 July 2013 06:49, Nigel Witherdin nigel_wither...@hotmail.com wrote:



Hey guys,



We are currently migrating content from from legacy doc mgmt systems into 
SP2010, and I have come across a sticky requirement.



The doc mgmt system we are migrating from had a plugin to office that allowed 
the users to click a button and insert the file location and version number 
into the footer of the document. They like this functionality and see it as 
essential to exist in the new system.




For docs created within sharepoint, no problem. I can have a doc template that 
uses quick parts in the footer to display the items URL and version number (I 
assume), but that doesn't help for existing docs that are migrated into SP.




The other possible solution is to write a macro or customize word to provide a 
button that injects the required info into the footer (from the document's 
properties?), but I haven't really done anything like this before, so not sure 
how viable this is.




What do you think, any suggestions on how I could solve this?



Many thanks,



nigel

___

ozmoss mailing list

ozmoss@ozmoss.com

http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss




___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss   
  ___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


RE: Migration issue

2013-07-09 Thread Ishai Sagi
Nigel - you are sending conflicting messages as to what you want to do. Lets 
put aside new documents and focus on documents in the system:

1.   An event handler will not help, since there are no events running on 
the documents - you will need to edit the document properties or the documents 
to trigger the event handler - requiring you to edit each and every document

2.   A button will not help, since it still requires you to open each 
document, press the button and save

3.   A template will not help, since existing documents are not using the 
template

It seems to me that your best choice is to write an application that edits the 
documents. You will need a way to differentiate between new ones and migrated 
ones, and you will need code that runs on the server that can update the 
document content.


[Description: Description: C:\Users\Brian\Pictures\EXD Logos\Extelligent logo 
no text.jpg]Ishai Sagi | Solutions Architect
0488 789 786 | is...@exd.com.aumailto:is...@exd.com.au | 
www.sharepoint-tips.comhttp://www.sharepoint-tips.com/ | 
@ishaisagihttp://twitter.com/ishaisagi | MVP 
Profilehttps://mvp.support.microsoft.com/profile/Ishai

From: ozmoss-boun...@ozmoss.com [mailto:ozmoss-boun...@ozmoss.com] On Behalf Of 
Nigel Witherdin
Sent: Wednesday, 10 July 2013 12:15 PM
To: OzMoss; Conrad Grobler
Subject: RE: Migration issue

Would creating an Office plugin (a button) that injects the values into the 
footer from the document's properties be feasible?

I think I have gotten version number in a footer in the document template by 
creating it as a label in the Info Mgmt Policy for the doc's content type 
before (so it can then be used in the template), but this doesn't really help 
me for the existing documents.

My other solution is shudder an event receiver that embeds the info into the 
footer.

Oh - this has to work for DOCs and DOCXs.

Again, would appreciate your thoughts - thanks guys!

Date: Wed, 10 Jul 2013 11:41:00 +1000
Subject: Re: Migration issue
From: web.ad...@syd.catholic.edu.aumailto:web.ad...@syd.catholic.edu.au
To: ozmoss@ozmoss.commailto:ozmoss@ozmoss.com
Version and absolute URL are not available as Quick Parts.

I'd create a content type and add a Version (numeric) field so people can 
decide when this should change, rather than SharePoint.

For the file path you're going to have trouble though. Only way I can think is 
to set a field's value via a workflow.

Both could then be added to a template footer as Quick Parts.

As for legacy documents...there's no way I know to update these easily. I did 
see a batch XML converter around but I don't think it could handle these kind 
of changes.
On 10 July 2013 06:49, Nigel Witherdin 
nigel_wither...@hotmail.commailto:nigel_wither...@hotmail.com wrote:

Hey guys,

We are currently migrating content from from legacy doc mgmt systems into 
SP2010, and I have come across a sticky requirement.

The doc mgmt system we are migrating from had a plugin to office that allowed 
the users to click a button and insert the file location and version number 
into the footer of the document. They like this functionality and see it as 
essential to exist in the new system.

For docs created within sharepoint, no problem. I can have a doc template that 
uses quick parts in the footer to display the items URL and version number (I 
assume), but that doesn't help for existing docs that are migrated into SP.

The other possible solution is to write a macro or customize word to provide a 
button that injects the required info into the footer (from the document's 
properties?), but I haven't really done anything like this before, so not sure 
how viable this is.

What do you think, any suggestions on how I could solve this?

Many thanks,

nigel
___
ozmoss mailing list
ozmoss@ozmoss.commailto:ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


___ ozmoss mailing list 
ozmoss@ozmoss.commailto:ozmoss@ozmoss.com 
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
inline: image001.jpginline: image002.jpg___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


Re: Migration issue

2013-07-09 Thread Web Admin
A whole world of pain basically.

New docs aren't the problem really. It's the existing ones you'll have
 problems with. Deal with them first.

The simplest solution is for them to accept that this is a new system and
use content types and DispForm.aspx to display the metadata.

Not your fault they have multiple Office version docs.

I'd ignore the document path info for now cos it's going to change anyway.
But if the Version info exists in the legacy system, u might want to query
that and export to a spreadsheet. You could then use PowerShell to automate
the field update against the filename after you upload them.

On 10 July 2013 14:49, Ishai Sagi is...@exd.com.au wrote:

  Nigel – you are sending conflicting messages as to what you want to do.
 Lets put aside new documents and focus on documents in the system:

 **1.   **An event handler will not help, since there are no events
 running on the documents – you will need to edit the document properties or
 the documents to trigger the event handler – requiring you to edit each and
 every document

 **2.   **A button will not help, since it still requires you to open
 each document, press the button and save

 **3.   **A template will not help, since existing documents are not
 using the template

 ** **

 It seems to me that your best choice is to write an application that edits
 the documents. You will need a way to differentiate between new ones and
 migrated ones, and you will need code that runs on the server that can
 update the document content.

 ** **

 ** **

 **[image: Description: Description: C:\Users\Brian\Pictures\EXD
 Logos\Extelligent logo no text.jpg]***Ishai Sagi* | Solutions Architect
 0488 789 786 | is...@exd.com.au | www.sharepoint-tips.com | 
 @ishaisagihttp://twitter.com/ishaisagi
 | MVP Profile https://mvp.support.microsoft.com/profile/Ishai  

  ** **

 *From:* ozmoss-boun...@ozmoss.com [mailto:ozmoss-boun...@ozmoss.com] *On
 Behalf Of *Nigel Witherdin
 *Sent:* Wednesday, 10 July 2013 12:15 PM
 *To:* OzMoss; Conrad Grobler
 *Subject:* RE: Migration issue

 ** **

 Would creating an Office plugin (a button) that injects the values into
 the footer from the document's properties be feasible?

 ** **

 I think I have gotten version number in a footer in the document template
 by creating it as a label in the Info Mgmt Policy for the doc's content
 type before (so it can then be used in the template), but this doesn't
 really help me for the existing documents.

 ** **

 My other solution is shudder an event receiver that embeds the info into
 the footer.

 ** **

 Oh - this has to work for DOCs and DOCXs.

 ** **

 Again, would appreciate your thoughts - thanks guys!
  --

 Date: Wed, 10 Jul 2013 11:41:00 +1000
 Subject: Re: Migration issue
 From: web.ad...@syd.catholic.edu.au
 To: ozmoss@ozmoss.com

 Version and absolute URL are not available as Quick Parts.

 ** **

 I'd create a content type and add a Version (numeric) field so people can
 decide when this should change, rather than SharePoint.

 ** **

 For the file path you're going to have trouble though. Only way I can
 think is to set a field's value via a workflow.

 ** **

 Both could then be added to a template footer as Quick Parts.

 ** **

 As for legacy documents...there's no way I know to update these easily. I
 did see a batch XML converter around but I don't think it could handle
 these kind of changes.

 On 10 July 2013 06:49, Nigel Witherdin nigel_wither...@hotmail.com
 wrote:


 Hey guys,

 We are currently migrating content from from legacy doc mgmt systems into
 SP2010, and I have come across a sticky requirement.

 The doc mgmt system we are migrating from had a plugin to office that
 allowed the users to click a button and insert the file location and
 version number into the footer of the document. They like this
 functionality and see it as essential to exist in the new system.

 For docs created within sharepoint, no problem. I can have a doc template
 that uses quick parts in the footer to display the items URL and version
 number (I assume), but that doesn't help for existing docs that are
 migrated into SP.

 The other possible solution is to write a macro or customize word to
 provide a button that injects the required info into the footer (from the
 document's properties?), but I haven't really done anything like this
 before, so not sure how viable this is.

 What do you think, any suggestions on how I could solve this?

 Many thanks,

 nigel
 ___
 ozmoss mailing list
 ozmoss@ozmoss.com
 http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss

  ** **


 ___ ozmoss mailing list
 ozmoss@ozmoss.com http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss***
 *

 ___
 ozmoss mailing list
 ozmoss@ozmoss.com