martin f krafft <ma**@de**.org> reported this on the Debian tracker:

"I found a way to cheat workrave. Arguably, there are plenty ways to
trick this "technical solution to a personal problem", but there is
also no reason why they couldn't be fixed.

I have the skip/postpone buttons disabled. Yet, when I select "Rest
break" from the right-click menu, the dialog has them. What's worse
is that when I click skip, the time goes back to the initial value,
50 minutes in my case.

So either the buttons should never appear, which might be pad if
I accidentally click on the button.

The better solution is that if I click "skip" in an explicit break,
I should be able to skip *that* break, but the timer should not be
reset. Instead, if I skip the explicit break after, say, 1 minute,
the timer can get an additional minute, but it should not be totally
reset.

The point is that by skipping an explicit break, I can reset the 
timer, which is a cheat vector."

(original report slightly edited to clarify some points)

This is so by design. See bug 62 and bug 220 for some discussion. Basically, the idea was that a user should be able to cancel a "self inflicted" restbreak, regardless of their setting for "show skip/postpone" button.

Of course, you have a point that if you choose "skip" in that case, you are able to prolong the time between breaks. However, making the "skip" button not reset the timer, is not the answer, imo, because in that case, the "skip" and "postpone" buttons are behaving the same.

As an alternative approach, I'd propose to only show the "postpone" button on self inflicted restbreaks, but not the "skip" button.

Then again, I am wondering if it is really worth the trouble. From a usability point of view, one could argue that it would be best if the restbreak window always looks the same (this reduces the mental load of having to recognise that stupid window that is interrupting your work, yet again). From this point of view, all these kinds of diversity  (restbreaks yes/no, skip/postpone yes/no, etc..) isn't really helping.

I implemented the alternative approach.

Uh...
I originally intended the "alternative approach" only for people who had skip and postpone disabled.

I have skip and postpone enabled, and I can now no longer skip self-inflicted restbreaks.

I just had an overdue self-inflicted restbreak, and noticed that the "skip" button was removed there also.

I didn't exactly test, but I am assuming that means that if people have skip and postpone disabled, they still get a "postpone" button on a self-inflicted overdue restbreak.

I'm wondering if this makes sense.

The only way in which this could happen, is if the user has configured several preludes before being forced to take a break. If he keeps working at the first prelude, and then self-inflicts a break, then it makes sense to have a "postpone" button, since he otherwise could have worked longer.

Then again, if the user had stopped working at the first prelude, he would have been shown a restbreak window without "postpone" on it (because it was configured that way).

To make things consistent again, all restbreak windows should have a postpone button, except the last one, where the user is forced to take a break. But then the configuration item "Show postpone and skip button" is badly named, because the "postpone" button is shown on numerous other occasions as well.

My head hurts. Any other thoughts?

Ok. For now changed behavior to 

1) Self Inflicted + skip/postpone disabled -> only postpone
2) Self Inflicted + skip/postpone enabled -> both skip/postpone
3) normal break  -> follow skip/postpone enabled/disabled.

Correct me if I'm wrong. You suggest to split 3) into

3a) normal break + buttons disabled + not last warning -> show (both?) buttons.
3b) normal break + buttons disabled + last warning     -> no buttons
3c) normal break + button enabled                      -> show both button

Can we explain this to a normal user? I already get complaints that self-inflicted breaks contain buttons, even though are disabled... 

> Correct me if I'm wrong. You suggest to split 3) into
> 
> 3a) normal break + buttons disabled + not last warning -> show (both?) buttons.

No, in this case only postpone should be shown, not skip. And it is not yet a proposal, merely me trying to structure some random thoughts before dumping them in bugzilla ;-)

[...]

> Can we explain this to a normal user? I already get complaints that
> self-inflicted breaks contain buttons, even though are disabled... 

Explaining this to a user would be difficult. This is exactly the problem I still have. Though one could also wonder whether this much complexity is desirable in the first place.

If we were to change the wording of "Show postpone and skip button" to something like "Show postpone and skip button even on forced breaks", the functionality would be clearer to the user, but probably the string is too long.

I guess I do not have a definitive answer on this one.

Shouldn't the solution be that a self-inflicted break that gets skipped does not reset the timer? This way, all the button-showing behavior can stay as it currently is (1.9.4), while still not allowing one to cheat.

No clue how difficult this would be to implement, though.

(In reply to comment #7)
> Shouldn't the solution be that a self-inflicted break that gets skipped does
> not reset the timer?

Originally, the intent was that clicking "postpone" makes the break window go away, without resetting the timer, while "skip" makes the break window go away and resets the timer.

If you now change the meaning of "skip" to not reset the timer, then postpone and skip are doing the same thing, which might be confusing

Good point. But then, wouldn't it make most sense if the "skip" button is simply not visible on user-invoked breaks, and the postpone button is always? That would mean that the configuration is entirely ignored for those breaks.

Or does Workrave have users who consciously click the "Rest break now" button, but then pathologically can't resist clicking "Postpone" right after, and need it disabled? I can't really imagine that, but hey, people are wired weirdly (I know I am!). 

If this is the case, calling the "Postpone" button "Cancel" for the first, say, 10 seconds (allowing a user to correct a mis-click) might be a solution: after those 10 seconds, the button gets renamed to good old "Postpone", if enabled, or otherwise it simple gets removed. I believe this covers all use cases, but it feels a bit far-fetched.

(In reply to comment #9)
> Good point. But then, wouldn't it make most sense if the "skip" button is
> simply not visible on user-invoked breaks, and the postpone button is
> always? That would mean that the configuration is entirely ignored for those
> breaks.

That makes sense. Except that I think we should still show the skip button on self-inflicted breaks (as we've grown to call them), if the user has enabled "skip".