(actually using eM Client 6.0, but I can’t select that version)
Can I filter or group tasks on their status, for example “deferred”?
Hi, this is possible but it will be shown in groups.
Jan
I’m fine with that, but there are no groups for “deferred” or “waiting”.
yes, deferred and waiting does mean not completed so sorting about completed and not completed works like designed.
Jan
I am not going to argue that it doesn’t work as designed, but I’ll happily argue that the design is then flawed 
The option in the details pane is “status”, not “completed”, so I could then argue that the list shows a field missing from the details pane, and omits a field present in the details pane.
Hi, I don!t understand your point. If it acts like designed why it should be flawed? Majority of our users like it this way so it says that it is good design.
Jan
To be clear, I am not stating that I have some kind of authority that says you must change your design, I am answering your question “I don’t understand your point…”.
I think it is flawed conceptually, even if pragmatically you haven’t received feedback from users that it must change. I am somewhat surprised that the majority of users *like* the behavior, but I certainly believe it is too small a thing for your users to complain over.
I think it is conceptually flawed because the details screen has a field called “status”. The list field *also* has a field that is *called* status but which is *in fact* “completed (y/n)”. This is inconsistent. If a field existed “assignee” where I could register who bears responsibility for completing a task, and this would show up in other places merely as “assigned to you” even though it still bears the name “assignee”, I would find it similarly inconsistent. Plus lossy. There is an assumption that I only care about tasks that are not completed; perhaps I care about tasks that I should act upon (which I do), so a lossy translation to a yes/no field for me would, I feel legitimately, mean “completed, deferred, waiting” = n, “open” = y.
That is not to say that this mapping works for everyone - but then, neither does yours.
Again, I’m not looking to convince you to change em client based on this argument, and I don’t expect it will. But I do legitimately feel that this design choice is both flawed and easily corrected. We can disagree on this, but much as my argument most likely won’t sway you, your argument doesn’t sway me.