Hiya, I am a fan of wrapper modules like yours. I am also a huge fan of the bubbletimer.com -style timetracking (we have a similar drupal module with the same name)

1 Question: is there a way to support a tracking widget with 15 min checkboxes (BTimer-style) in addition to the traditional start/stop widgets.

PS. I've heard that one can write a bridge/integration with the Harvest API for example using this module - so this would mean that anything is possible?

Please shed some light for me onto the best workflow for my goals. Cheers.

Comments

allie micka’s picture

allie micka
she/her
commented

This module wants to store your time data and make it trackable via Views. It tries not to make too many decisions beyond that, because there are many, many different uses for that type of information.

For example, I think it's silly to attempt to build an entire invoicing system in Drupal. Rather, I would like to ensure that my time tracking data is portable between Drupal and something like Quickbooks, which has access to my bank information, taxes, payroll, and all other types of financial reporting. That's why I wrote the QB Time module, which extends the base class from time.module with the capacity to create relationships between employees/projects/time data, and synchronizes updates via the Quickbooks API. Looking at that module might be a good way to get started.

Similarly, there's nothing particularly "built-in" about the way that Time collects its time entry data. What's there right now? A very basic text field and activity selector. It would be possible to provide a different interface simply by using a form_alter, but I think in the long run it would be better if you could choose from available "Widgets" (Bubbletimer, simple, javascript counter, etc.) that deliver time data to the storage mechanism.

One of the key features of the Time module is the concept of time tracking "profiles". Each time entry is associated with a configuration. For example, some of your projects might be billable and thus transfer data to Quickbooks, while other projects are internal, and are simply storing non-billable time for reference. It seems that having each profile be able to use a different "Widget" would respect the idea that some time entry mechanisms are more appropriate for different tasks.

Ultimately, I would really like to see these two modules playing well together. It appears that you have put a lot of time into a really solid front-end, and I have put time into something that can be more extensible and interoperable