Forum Discussion
OneNote Interop API UpdatePageContent changes lastModifiedTime of unmodified child elements
Using the Interop API, IApplication.UpdatePageContent(xml, lastModTime, XMLSchema.xs2013, true)
Given a page with one Outline and two OE paragraphs where each OE paragraph was contributed by different authors on different dates.
If any change is made to the Outline, such as appending a new OE, without modifying the existing OEs, then when the page is saved using UpdatePageContent, the lastModifiedTime attribute of all descendants of that Outline are updated to the current time. This results in losing information regarding when a particular author applied their changes.
The expectation is that the EditedByAttributes (per 0336.OneNoteApplication_2013.xsd) of an OE should be preserved unless that OE's content has changed.
Users who share notebooks often rely on the EditedByAttributes (who and when) for individual parts of a page to track independent changes. The current behavior loses that auditing capability.
Note that this usage is based on https://learn.microsoft.com/en-us/office/client-developer/onenote/application-interface-onenote#updatepagecontent-method which explains:
- You must include page-level objects in the UpdatePageContent call
- The dateExpectedLastModified is nothing more than a pessimistic locking type of safe-guard and is not considered in any regard in relation to the lastModifiedTime attribute
2 Replies
You are changing an Outline by adding an OE, but UpdatePageContent refreshes lastModifiedTime on the Outline’s child OEs, erasing the per-author timing you expected to preserve. Microsoft documents the page-level object as the update unit: only changed outlines, images, or ink must be submitted, but it does not guarantee that EditedByAttributes on descendants remain unchanged when their parent Outline is rewritten. The expected-last-modified parameter prevents overwriting a page changed since it was read; it does not preserve child timestamps. force=true controls handling of unknown data, not auditing metadata. The workaround is to avoid round-tripping an Outline containing audited siblings. Add new content as a separate page-level Outline where layout permits, or store author/time data in your own metadata. Reproduce the issue with minimal XML on a OneNote build and report the before/after XML, schema version, and build to Microsoft. There is no documented API switch that preserves those child timestamps
OK, understood. You're explaining how it works. This ticket is asking for an enhancement to make it work the same way the user sees when changing content in the UI. If they change one of many paragraphs in an Outline, only that paragraph's EditedByAttributes are changed; all other paragraphs in the Outline are left unchanged. Why can't the Interop API provide similar capabilities?
There's no way, using the API as it is today, to delete the single paragraph AND inject a new paragraph without disrupting the entire Outline, thereby blowing away the attributes on all sibling OEs too.
