none
deleteExceptions element of recurrenceXML does not work as expected RRS feed

  • Question

  • Steve,
        Thank you for the response.  The information concerning the inability to create multiday recurring events is key information.  Outlook can create multiday recurring events.  I believe I was thinking the problem was related to XMLTZone when in fact it may have been a combination of two or three problems (1.) end date, 2.)  TimeZone and 3.) Duration)  Please correct me if my assumptions below are incorrect:

    1.) End Date of a recurring item must be the calculated/expanded end date, if provided (I have not proved the instances where end datetime does not need to be provided but have noticed in the specification it does not always need to be provided) - if this is true can MS provide a code sample of how to expand what appears to be the most difficult recurrence patterns - monthlybyday and yearlybyday outside of SP?  A bunch of programmers have attempted this on the net and no one that I have found has successfully and correctly accomplished this including myself.

    2.) TimeZone and corresponding XMLTZone need to be set for the series master recurring item but not for exception items and these fields need to match and need to indicate to the Server the timezone of the event being uploaded.  Since I use UTC for all records these all need to indicate appropriate values as you've displayed above

    3.) Duration - also as you've listed above

    If you can in this forum respond to another question:

    1.)    deleteExceptions element of the recurrenceXML does not seem to work for all recurrence items/types in SP, is this true?  I have seen this to work only for allday recurring events.  As a result my protocol client implementation must first delete the recurring item from SP in order to force a delete of all exceptions, whenever I need to update the items key fields start/end, recurrenceData, UID or XMLTZone, then re-add the item and its exceptions.  I do not believe this is as the protocol was intended to be implemented but hey I've been proven wrong before.

    Steve



    Steve Schaff MicroLink, LLC
    • Split by Steve Smegner Monday, November 17, 2008 11:08 PM Forum thread topic has changed.
    Friday, November 7, 2008 1:22 PM

Answers

  • Steve,
    I split the thread because this is a different topic. Hopefully this will not confuse the issue.

    It is not clear what you are using deleteExceptions for.  My understanding of the element is that it is a performance enhancer and not a proper command.  I would have expected deleteExceptions to always cause exceptions to be deleted.  It is intended to be paired with a change to a recurrence.  In section 3.2.4.2.3 there is a list of properties that cause exceptions to be deleted when they are set on an appointment.  When one of those is changed, the others (including RecurrenceData with a deleteExceptions element) is expected, but not strictly required.

     

    1)      If you are using it as a means of clearing exceptions (with no recurrence change) then I would say this isn’t the intended use and I would have to ask the server team if it’s a supported scenario.

    2)      If you are altering a recurrence’s key fields then the expected behavior is that exceptions cease to exist whether deleteExceptions is added or not.  Key fields are those that define when the recurrence takes place and are listed in section 3.2.4.2.3.  The idea is that when the recurrence no longer happens at the same date-time, the exceptions are no longer conceptually valid.  There is no clear way to transfer them from one recurrence type to another.  Think about changing a weekly recurrence to an annual one or vice versa.  Instead of creating a mixed set of delete and no-delete scenarios, the behavior is consistent by deleting always.  In this scenario, I suggest the client upload all the fields listed in 3.2.4.2.3 even if they are unchanged because I don’t know which the server may use to trigger exception deletes.


    3)
         
    You may be talking about a posible third scenario.  I say this because of the sentence about deleting the recurrence and then “re-add the item and its exceptions”.  If you want to implement a model where exceptions are preserved across recurrence changes then replacing the exceptions would be required, but deleting them should not be.


    4)
         
    The last possibility is there is a server bug or limitation of some sort.  Perhaps you are creating a new UID for the recurrence and this change is processed before exception deletes.  For Outlook, the new UID is listed after the other props in 3.2.4.2.3 in the XML.  If we end up here this would have to be investigated internally.

     


    So let me know if we a re zooming in on the actual problem area.


    Steve Smegner
    Application Development Consulting Group

    • Marked as answer by Steve Smegner Friday, December 5, 2008 5:13 AM
    Monday, November 17, 2008 11:16 PM
  • I am going to mark this answered for now. If you wish to continue just let us know.


    Steve Smegner
    Application Developmet Consulting Group
    • Marked as answer by Steve Smegner Friday, December 5, 2008 5:16 AM
    Friday, December 5, 2008 5:16 AM

All replies

  • Steve,
    I split the thread because this is a different topic. Hopefully this will not confuse the issue.

    It is not clear what you are using deleteExceptions for.  My understanding of the element is that it is a performance enhancer and not a proper command.  I would have expected deleteExceptions to always cause exceptions to be deleted.  It is intended to be paired with a change to a recurrence.  In section 3.2.4.2.3 there is a list of properties that cause exceptions to be deleted when they are set on an appointment.  When one of those is changed, the others (including RecurrenceData with a deleteExceptions element) is expected, but not strictly required.

     

    1)      If you are using it as a means of clearing exceptions (with no recurrence change) then I would say this isn’t the intended use and I would have to ask the server team if it’s a supported scenario.

    2)      If you are altering a recurrence’s key fields then the expected behavior is that exceptions cease to exist whether deleteExceptions is added or not.  Key fields are those that define when the recurrence takes place and are listed in section 3.2.4.2.3.  The idea is that when the recurrence no longer happens at the same date-time, the exceptions are no longer conceptually valid.  There is no clear way to transfer them from one recurrence type to another.  Think about changing a weekly recurrence to an annual one or vice versa.  Instead of creating a mixed set of delete and no-delete scenarios, the behavior is consistent by deleting always.  In this scenario, I suggest the client upload all the fields listed in 3.2.4.2.3 even if they are unchanged because I don’t know which the server may use to trigger exception deletes.


    3)
         
    You may be talking about a posible third scenario.  I say this because of the sentence about deleting the recurrence and then “re-add the item and its exceptions”.  If you want to implement a model where exceptions are preserved across recurrence changes then replacing the exceptions would be required, but deleting them should not be.


    4)
         
    The last possibility is there is a server bug or limitation of some sort.  Perhaps you are creating a new UID for the recurrence and this change is processed before exception deletes.  For Outlook, the new UID is listed after the other props in 3.2.4.2.3 in the XML.  If we end up here this would have to be investigated internally.

     


    So let me know if we a re zooming in on the actual problem area.


    Steve Smegner
    Application Development Consulting Group

    • Marked as answer by Steve Smegner Friday, December 5, 2008 5:13 AM
    Monday, November 17, 2008 11:16 PM
  • I am going to mark this answered for now. If you wish to continue just let us know.


    Steve Smegner
    Application Developmet Consulting Group
    • Marked as answer by Steve Smegner Friday, December 5, 2008 5:16 AM
    Friday, December 5, 2008 5:16 AM