Hardcoded statuses 72

[cazgp]

No description provided.

[kynan]

Have rebased the branch. This looks like a good start, wondering if we should wait until we know how to deal with fuzziness.

[cazgp]

I think part of the problem is that a lot of the display code depends upon those statuses being named. If we generalise the display code and ensure that statuses are always passed in the order working -> however many in betweens -> completely borked, then we never even have to look at the names of the statuses.

I'm not even sure that fuzziness is needed. If a user can only ever input the statuses (and a pre-parse of data imported from elsewhere handles the fuzziness), the scripts can be quite simple. Or tis there something fundamental I'm missing?

[kynan]

Can you expand on how we could simplify the display code that way?

I agree that fuzziness is a separate issue that needs to be handled elsewhere.

[dgorissen]

1st point: Have not had the chance yet to look into the code & changes in detail so can't really answer that yet. Note it is not inconceivable we move to a hierarchical status model in the future instead of a linear one.

2nd point: yeah, fuzziness really only comes into play on data import or when reporting by sms. So should be another issue really.

[cazgp]

Sure, throughout the graphing stuff is things like:

.group(group, "Functional")
...
.stack(group, "Non-Functional")
.stack(group, "Needs Repair")

However, it could be something like:

graph = graph.group(group, statuses[0].displayName)
for status in statuses.slice(1)
    graph = graph.stack(group, status.displayName)

There's also a lot of stuff like

if something.functional
    do something
else if something["needs repair"]
    do something else

With a guaranteed ordered list that's:

if something[statuses[0]]
    do something
else if something[statuses[-1]]
    do something else

I've yet to see anything between the end points being checked so I could be wrong.

[kynan]

Rebased again, please check carefully, there were lots of tricky merge conflicts.

[cazgp]

This should be plural... $rootScope.waterpointStatuses...

[kynan]

I've renamed the service

[cazgp]

Yeah but this is adding it to scope, so you can define it however you want. There are multiple statuses available so it should be statuses :)

[kynan]

Ah, yes, replace fail.

[cazgp]

This looks good to me :) What do you think about the linear progression so's we can remove all references to statuses?

[kynan]

Not sure, that's the dashboard i.e. @dgorissen's territory.

[kynan]

Have rebased again, but this will need updating w.r.t. status -> cost mapping added in @dgorissen's heatmap pr #128 (i.e. these are still hard coded).

[kynan]

This has been rotting for a while. Do we still want this @dgorissen? If so, should clean up and merge to prevent even further bitrot.

[dgorissen]

Same comment as #130 .. needs time :( Would already be good if we could at least merge what was done so far

[kynan]

Yes, maybe @cazgp can spring into action again and update this pr?

[cazgp]

I'm not sure what else I needed to do on this? I thought it was good to go but then it wasn't. Unfortunately I don't have so much coding time atm.

[kynan]

Don't remember exactly, I think we were waiting on feedback from @dgorissen regarding dashboard-related changes. For starters this would need rebasing. Might get to it at some point, but can't promise.