Niklas
~~__BLOCKED__ This needs to be rebased after PR #45 is merged.~~ __BLOCKED__ This needs #47.
Well yes, but this API is not our planned v2. I'm fine with merging this in general, but this broke non-js usage (because the buttons then do GET requests)
Would this require tracking everything a user drinks? This would create a lot of personal data. I don't think this would be good. Alternatively, we could just track the amount...
Since #21, we have the opt-in option to log the consumed drinks. We could use this information to calculate the death count for the personal audits page.
Is this still relevant?
How would this be useful?
So, how would we want to make this configurable? I don't really see this being useful in the web interface. A simple config file perhaps like this could be used:...
Another thing: Do we want to expose this via the API? The API doesn't know anything about amounts, currently. This is currently solely managed by the clients (and seperately, in...
Do we really want this to be user-configurable? I'm perfectly fine with having those endpoints, but I think they should be read-only.
Well, that used to be the case. Since a60450c the API supports buying drinks.