"Hide completed" should not hide "At most"-type measured habits

[hut]

Description

"Hide completed" should not hide "At most"-type measured habits.

Currently, there are these two confusing behaviors of habits with the target type "at most":

1. If I create a habit that has the target type "At most", it will be immediately hidden when if the "Hide completed" option is on.
2. If I uncheck "Hide completed" and "fail" this habit by entering a number for today that exceeds the maximum target, the habit actually remains visible when I turn "Hide completed" back on.

Both of these don't make sense to me.

1. I would expect the habit to be visible in the beginning of the day so that I can enter any numbers at all.
2. When I have failed the habit by exceeding the maximum target, that should not be the time to show the task but to hide it.

Steps to reproduce

1. Enable "Hide completed"
2. Create a new habit
3. Select "Measurable"
4. Set Name to "foo", Target to "5", "Target Type" to "At most", and save.
5. Note that the habit doesn't show up
6. Disable "Hide completed"
7. Enter the number "10" for today of the new habit "foo"
8. Enable "Hide completed"
9. Note that the habit is now visible

System information

• Phone Operating System: Android
• App version: 2.1.2

[hiqua]

If you go to settings and enable "Show question marks for missing data", does it fit your need, or are there still gaps?

Without this setting (IIRC) there's not real distinction between non-entered and 0, which is what you seem to be missing.

[hut]

Thanks hiqua, with that option turned on it works as expected.

With the option disabled, the behavior still makes no sense though.

It's up to you whether you leave this issue open.

FYI, it seems that there is a distinction between not-entered and 0 after all. You can test it by disabling "Show question marks for missing data", creating a new task with "at most 5 per day", opening the calendar view, and entering "0" on a random day. The color hint changes from "inactive" to "success".

[iSoron]

Thanks for the bug report, @hut. This has been fixed in #2077.