How should iCal notifications with no X-MAINTNOTE-STATUS be handled?

[glennmatthews]

Environment

• circuit_maintenance_parser version: 2.0.5

Proposed Functionality

Per the BCOP, X-MAINTNOTE-STATUS can be omitted from an iCal notification (the only example I see of this in the BCOP is for a rescheduled maintenance window), but our Maintenance class defines status as a mandatory field. In general how should we handle iCal notifications that omit this field?

Use Case

I have a real-world example received from a provider for a "completed" notification that omits the X-MAINTNOTE-STATUS, so simply assuming that "no X-MAINTNOTE-STATUS implies "status=re-scheduled"" would not be correct in this case. We could possibly parse the DESCRIPTION or SUMMARY fields -- in this particular case the word "completed" is present in both -- but that's probably not desirable as a general solution? Looking for suggestions here.

[chadell]

Actually, reviewing the BCOP, I have not found where the RE-SCHEDULED is coming from, I don't see it defined. Maybe I took it from another reference and extended... I can't recall right now.
However, it's true that the document explicitly says 0 or 1 for Presence Required. So, my suggestion would be to make this field optional in the Maintenance class, and from the client point of view this should be seen as no status change, so kind of "refresh", but not changes on the previous state that this could have.
Obviously, the rule of thumb would be to capture this information because if possible, because it's relevant to properly handling the notification lifecycle.
How does it sound to you?

[glennmatthews]

Making status into an optional field (and correspondingly updating expectations in nautobot-circuit-maintenance and any other known consumers of this library) sounds to me like the most appropriate fix... though consumers of this library will need to decide what to do in the case where a "no status change" notification is the first seen notification for a given maintenance - what should they do for their own status reporting in that case?

[chadell]

Ok, let's do this small change then, making status optional and documenting it clearly in the library to leave the decision about what to do with it up to the client.
So, one client could decide to take "no status" in the first notification as CONFIRMED and another could discard the maintenance, understanding that is not enough complete to be taken into account.