Choose duration for tomato

[matheussilvasantos]

Idea naively implemented to choose the duration of tomato

TODO

• Update API documentation to include the new duration param
• Update Api::Presenter::Tomato to include duration
• Update Tomato#must_not_overlap validation method to use instance's duration
• Use Tomato::DURATION as the default duration value
• Update projects counters to take tomatoes duration into account
• Update timer's duration output element to include a label, "Duration", and a unit of measurement, "minutes"

[potomak]

See #77

[potomak]

Can you include screenshots for this feature?

[potomak]

Default value should be 25.

[potomak]

Why not Integer?

[matheussilvasantos]

Yes, I've seen it after do the pull request, should be Integer

[potomak]

There's a Tomato model validation and a lot of counters that rely on the default duration.

[matheussilvasantos]

Yes, there is the Workable module too, that I can't figure out how to adapt.

[potomak]

@matheussilvasantos cool, thanks uploading some screenshots and the updates.

I will update the description to include all the things that I still think need to be done.

[potomak]

It would be more clear if we add a label, duration, and a unit of measurement, minutes.

[potomak]

must_not_overlap won't work without storing tomatoes on timer start.

[potomak]

There's one big blocker: if we don't store a new tomato as soon as a user starts the timer, the must_not_overlap validation won't work in conjunction with a custom tomato duration.

must_not_overlap validation relies on the fact that all tomatoes last 25 minutes. This information makes it possible to validate tomatoes even if the current tomato has not been saves yet. With a custom tomato duration this requirement is missing.

A possible solution, that would make also resuming timers (#219) possible, would be to store a new tomato when the timer starts, and to update it when it ends.

[matheussilvasantos]

I don't know if I figured out what must_not_overlap does, but I think that it is working with the last changes.

Storing a new tomato when the time starts is a big deal to implement here, I think this should be implemented with other pull request.

[potomak]

Thanks so much @matheussilvasantos for your contribution, but I don't think I have the time right now to work towards the goal of making this PR mergeable in master. If @dalpo, or someone else, has some time to spent to think about a migration strategy for this PR let's keep this open, otherwise I will close it.

I'm really sorry to "waste" the time you spent working on this, but I think this was a task too bit to be addressed without a clear migration strategy in place. If you'd still like to get involved in the project, while we find a solution to make this work, take a look at the other issues in the repo.

[potomak]

Closing due to inactivity.