search

codeforamerica / srtracker

Open311 Service Request Status Site
BSD 3-Clause "New" or "Revised" License
20 stars 23 forks source link

Overall status is wrong when there are follow-ons #50

Closed Mr0grog closed 11 years ago

Mr0grog commented 11 years ago

If all the follow-ons are not closed, the request may still be shown as closed. It should be shown as "open". See http://servicetracker.cityofchicago.org/requests/12-01468027

Related to #47

Mr0grog commented 11 years ago

Ah! The idea behind putting the "follow-ons" in the notes list was that the extended_attributes section for each follow-on actually contains all the data the city can reasonably make public about each request. i.e. there's no reason to try and hit the API again to get information about the follow-on. The situation where the follow-on is a non-public type is a big part of why this was devised (and also so that you don't have to hit the API multiple times to begin with) :grin:

In terms of the open/closed status, you'll encounter one of the two following situations with follow-ons:

  1. A follow-on note will have type: "follow_on_created" or type: "follow_on_closed"
  2. The note will have type: "follow_on". In this case, the summary field is guaranteed to end in either "Created" or "Closed".

In either case, if a follow-on has been completed, you'll see at least two notes relating to it (one for opened and one for closed), which you can match up by looking at the service_request_id field in extended_attributes. This logic is used in lines 145-161 of app.py to annotate each follow-on with whether it's been completed.

The final piece of the puzzle is that a service request should only ever be marked closed if all its follow-ons are completed or if it has no follow-ons and its status field is already marked as closed.

FYI, this issue is actually about working around a bug in Chicago's API implementation. The status field is supposed to meet the above conditions (so we shouldn't need to do any of this checking), but it's currently buggy :(

Mr0grog commented 11 years ago

Also, I realize the above situation with having two ways to check whether the follow-on is open or closed is crazypants, but, like the fact that we have to do any of this in the first place, is the result of issues in the city's underlying implementation.

tacaswell commented 11 years ago

(sorry, I yanked my original comment when I discovered that follow_on_closed exists.)

should we have to worry about 3+ deep follow-ons?

Mr0grog commented 11 years ago

Yep—I believe the deepest known case at current is 9 follow-ons, but I'm not 100% on that.

tacaswell commented 11 years ago

Do you know the number of one of those cases?

Mr0grog commented 11 years ago

Hmmm, I don't have it handy; you'd have to do some long queries to find it. It might also be one that's not public yet.

In any case, you can't really depend on there being no more than N number of follow-ons; you just have to run through them all.

tacaswell commented 11 years ago

My real question is if the nested follow-ons show up in the note list (that is will there be N follow_on_opened entries). If so, then this can be done by counting the number of follow_on_open/follow_on_close notes.

Mr0grog commented 11 years ago

Oh, sorry. Yes. Nested follow-ons are flattened in the notes list, so counting the opened vs. the closed entries should tell you whether they've all been completed.

tacaswell commented 11 years ago

one last (hopefully) silly question, do you know the number of another follow-on and still open SR, it seems that they have really closed 12-00724508

Mr0grog commented 11 years ago

Looks like 12-01468027 still has open follow-ons.

Mr0grog commented 11 years ago

Closed in bb591653a33fa008f74bb3c1feb0608e8e6692ab