request: API XML result is rather inconsistent and poorly structured

[jberry-suse]

Having written extensive processing of requests for generating detailed metrics and re-creating project level staging state based on multiple requests I have run into quite some issues with the structure of the data and a few clear bugs.

• request: API does not always include who on review entries #3857 request: API does not always include who on review entries
• request: state when date is incorrect #3858 request: state when date is incorrect
• request: 446602 does not include <history> element for <priority> change #3897 request: 446602 does not include <history> element for <priority> change

Based on the structure I am going to assume this organically grew into this structure as it makes little sense to design it like this. The disconnect between <history> and <review> or <priority> is rather painful and repeating data rather than providing the other value that would be useful is also silly and frustrating.

One would expect when passing withfullhistory=1 that it would be clear to re-create simple things like when and who added a review and when and who changed its state, but it really is not.

When a review is first added it will look something like:

  <review state="new" when="2017-09-22T19:25:18" who="jberry" by_user="jberry_factory">
    <comment>staging review</comment>
  </review>

Note that jberry added a review for jberry_factory. After jberry_factory accepts the review the results looks like the following.

  <review state="accepted" when="2017-09-22T19:23:56" who="jberry_factory" by_user="jberry_factory">
    <comment>psh</comment>
    <history who="jberry_factory" when="2017-09-22T19:24:37">
      <description>Review got accepted</description>
      <comment>psh</comment>
    </history>
  </review>

Not only is <history> used to denote something in the future of the parent <review> element, but for only the current state and person who last changed can be seen. It is no longer possible to see that the review was added by jberry. This is rather useless and utterly confusing when one considers that all the values on the <review> tag represent the current state except the when which represents the original state. What!?

If one looks at the <history> elements, one can find the relevant data, but there is no clear data that indicates this was for the jberry_factory review.

  <history who="jberry" when="2017-09-22T19:23:56">
    <description>Request got a new review request</description>
    <comment>staging review</comment>
  </history>

Unfortunately, short of guessing the when field is the only one that may match. Depending on how long OBS took to process the data may not be identical and I have found can vary by a fair bit. Obviously, multiple reviews could have been added simultaneously or close enough to mess this up. One would expect that withhistory, much less withfullhistory would actually contain a real history instead of a sub element that contains duplicate information that is already contained on the parent element in a very wacky mix.

Multiple state changes where a request is reviewed multiple times is even less trivial to walk since any comments are no longer unique enough to parse. This really does not need to be this way.

Walking <priority> changes is just as bad, since one has to parse the <history> description text to see the state changes.

One can only imagine the level of absurd workarounds that I have implemented to extract something reasonable from this data. This should really be fixed.