### Desiderata
- [ ] Stop BeemiOS from overwriting the #DERAIL datapoint
- [ ] TBD
Background discussion:
CLIVE: One of our more active users suggested adding the last few datapoints to the legit-check email. Seems like an interesting idea, and probably quite cheap! It might go like:
* Number of datapoints: 152
* Days beeminding: 147
* OLD pledge: $5
* NEW pledge: $5
Last three datapoints:
2024-03-02 1 "via beedroid at 02:26:42 CET"
2024-03-01 0 #DERAIL ON THE 1st
2024-02-29 0.5
It would have the advantage of capturing the state of the data at derail, which oftentimes we have to go to the trlog to see if there's some dispute, or if (commonly) Apple Health has overwritten it.
I've tagged their email for feedback, but it seemed like a straightforward and helpful idea for both users and Support. Any thoughts?
THEO:
or if (commonly) Apple Health has overwritten it.
I think you are saying "they derailed because Apple Health data was missing. By the time support goes to look the data has been added, but too late as the derail already happened".
Is that correct?
NICKY: Yes, that's what has happened, but also unlike other integrations, Apple Health overwrites the #derail data point, removing it (and thus part of the evidence of what happened).
THEO: Would it be better if it didn't do that? (the deleting of #derail points) (edited)
DREEV: automatically deleting the #DERAIL datapoint does seem wrong to me. at least for consistency reasons.
CLIVE: Yes, it would be better for me if it didn't do that, mostly for consistency - in reality actually we're so used to it we ignore it, and I suppose it saves manually having to delete it! But still, it's a bit "magic"...
I can't think if any of the other autodata integrations do the deletion, but again if they do, for consistency they probably shouldn't.
NICKY: Rescuetime does too. Users also would like them to be persistent, quite apart from support.
CLIVE: Then definitely they shouldn't do it. It also suggests different underlying code paths - maybe a chance to refactor those down and reduce complexity!
THEO: could you file a ticket about this against beemios at some point? Shouldn't be too hard to fix.
Verbata: meta datapoints, autodata, apple health overwriting datapoints,
Background discussion:
CLIVE: One of our more active users suggested adding the last few datapoints to the legit-check email. Seems like an interesting idea, and probably quite cheap! It might go like:
It would have the advantage of capturing the state of the data at derail, which oftentimes we have to go to the trlog to see if there's some dispute, or if (commonly) Apple Health has overwritten it. I've tagged their email for feedback, but it seemed like a straightforward and helpful idea for both users and Support. Any thoughts?
THEO:
NICKY: Yes, that's what has happened, but also unlike other integrations, Apple Health overwrites the #derail data point, removing it (and thus part of the evidence of what happened).
THEO: Would it be better if it didn't do that? (the deleting of #derail points) (edited)
DREEV: automatically deleting the #DERAIL datapoint does seem wrong to me. at least for consistency reasons.
CLIVE: Yes, it would be better for me if it didn't do that, mostly for consistency - in reality actually we're so used to it we ignore it, and I suppose it saves manually having to delete it! But still, it's a bit "magic"... I can't think if any of the other autodata integrations do the deletion, but again if they do, for consistency they probably shouldn't.
NICKY: Rescuetime does too. Users also would like them to be persistent, quite apart from support.
CLIVE: Then definitely they shouldn't do it. It also suggests different underlying code paths - maybe a chance to refactor those down and reduce complexity!
THEO: could you file a ticket about this against beemios at some point? Shouldn't be too hard to fix.
Verbata: meta datapoints, autodata, apple health overwriting datapoints,